一般情况下，跟业务架构打交道的没少听过CDN服务销售人员吹嘘他们的CDN多么好（是很好，就是用户经常访问异常），技术多么先进（真心没看出来，计费的技术貌似很先进），系统多么完善（相当烂，很多业务场景都无法满足），客服多么热情（事实上只会打太极），如果你真头脑发热听信了销售人员的各种忽悠，把宝压在某家第三方CDN服务商身上，那后面的苦恼肯定是源源不断的。


  不知道其他公司在使用第三方CDN服务方面有没有痛点，在近三年的业务运维工作中，个人经历了多次由CDN故障引起的业务不可用事件，这也促使我们不断改进自己的系统架构以及使用多家的CDN服务做容灾，但是至今第三方CDN服务的异常还是或多或少会对我们自身的业务造成影响。


  目前，我们使用了两个第三方的CDN服务做静态文件（页面样式文件以及图片）的加速，计划即将引入第三家CDN服务商，等业务发展到一定阶段后也会考虑自建CDN服务。

  最初使用的是一家CDN的服务，由于第一家CDN服务出现过异常导致我们的业务受到影响所以就又上了一家第三方CDN的服务。很多知名的CDN服务商都会强调自己的数据是如何容灾的，但是很少有哪家CDN服务商提说过服务容灾的概念。大部分业务场景下，很有可能CDN服务的节点上是有数据的，但是由于CDN服务的其他资源异常或被攻击导致其无法正常提供服务。目前我们能做的就是再找一家CDN服务商来做服务的容灾。

  当第一家CDN服务有问题的时候我们就会通过切换域名解析的方式将静态资源的请求切换到第二家CDN服务商，用户访问页面上的静态文件元素会回源一次，业务受影响的时间完全取决于域名切换时生效的时间。当静态文件内容没有热点，回源带宽占用比较小的时候，还可以通过切换域名的方式切换CDN服务，等流量增长到一定程度，切换CDN服务商域名还是有很大风险的，同时域名切换后DNS解析时间也会让业务不可用时间无端增加从而影响到用户访问业务的体验。

  



实线表示平时用户访问时静态资源域名是解析到第一家cdn服务的，当用户请求的文件没在CDN缓存时就会回源取一次文件返回给用户，同时保存下来。

虚线表示平时用户的请求不会到第二家CDN服务，只有第一家CDN出现异常或者被攻击的时候，才会将用户的请求切换到第二家CDN服务商。当然，切换后用户的请求第一次落到这家CDN服务商的时候，CDN是要回源的。

  这种方式在后期的运维过程中发现有不少问题，其实现在看来整个系统架构本身就存在着不小的问题，比如无法实时验证第二家CDN服务商的可用性，当第一家CDN服务商出现异常准备切换的时候有可能很不巧第二家CDN服务商也有问题，这就达不到备份容灾的要求。


后期对于之前的方案做了改进，由于经济和系统改进成本的考虑，我们会将用户对于静态文件的请求分发到多家CDN服务商做预热，当其中某家服务商出现异常的时候就会将静态资源的域名切换到正常提供服务的CDN服务商上，由于之前用户访问过相关静态资源做过预热也就不存在所有静态资源需要回源的问题。



由于经常会有后台编辑人员推送一些运营信息，其中会包含一些图片信息，最好是在这里只允许运营人员推送url部分，域名部分由配置中心来处理，这样也可以避免运营编辑导致的单点问题。



一般CDN出现异常的时候，CDN服务商基本上很少有负责任地主动通知相关问题，真正等到我们自身监控发现CDN异常的时候，业务可能已经收到影响了。


主动监控CDN的可用性也就是不得不提上议程的事情了，当我们可以很好的监控CDN服务的可用性，第一时间发现异常的时候，可以通过配置中心来将有异常的线路的资源域名下线，或者完全可以自动来处理，这样对业务可用性的影响就可以降到最低了。




如果有能力自建CDN服务的时候，完全可以使用一个静态资源域名，对后端CDN服务进行可用性检测，发现异常可以自动将后端CDN服务从服务结点下线，整个过程对业务的影响完全为0.





目前我们实现了部分的CDN服务容灾，不过很多工作目前也只是计划中。

很多上了规模的互联网公司，尤其是有自建CDN服务的公司，对于CDN服务容灾已经有了自己比较成熟的架构了。

希望能有机会与更多公司的小伙伴们进行交流。