一场免费国内CDN加速引发的＂血案＂

那次“事故”实际上已经过去很久了，但至今记忆犹新。当时作为一个刚入职新人，作为一个此前没太接触过 CDN 的小白，遇到了那场“血案”，着实慌得一批，一度准备卷铺盖走人哈哈。:) 所以本篇不会涉及太多技术细节，只记录些当时弥留至今引发感想和经过吧。

CDN 是什么

CDN（Content Delivery Network）：内容分发网络，它是指一组分布在各个地方的服务器（集群）。这些服务器会存储源数据的副本（缓存），一旦用户访问，则会判断哪个服务器离用户最近，即从这个服务器中取出数据缓存发送给用户。如此一来，既缩短了用户访问资源物理上的空间距离，又将可能全部涌向源服务器的巨大流量洪峰分摊到了全国/世界各地，从而提升了用户体验，也降低了源服务器的负载成本。现如今，各个成熟的云服务厂商都提供了比较可靠的 CDN 服务，国内如阿里云、腾讯云等，国外如亚马逊等。

以一个浏览器中访问的页面为例，假设页面中有一个外链 JS 脚本文件：

•若浏览器检测本地没有这个 js 缓存，即对其域名进行 DNS 查询，经过一系列复杂操作，终于拿到了一个离用户最近的 ip 节点•浏览器拿着这个 ip 向服务器发起 http 请求，请求数据很快到达了这个服务器，结果服务器一看，我这里没有你要的这个 JS 文件啊•于是这个服务器只能向整个免费CDN系统的中心服务器（集群）发起求助，有个浏览器问我要一个 JS 脚本，我这里还没存，快给我一份•结果中心服务器一看，我这里也没有啊，赶紧对照域名找出对应的数据源服务器（源站）的真是地址，将这个 JS 脚本取回自己的本地，缓存一份（回源），并一级一级向下分发•最终这份 JS 脚本被各级中间服务缓存，并交到了最初发起 http 请求的浏览器手里。

上述只是一个简化的过程描述，或有不妥之处，实际上中间经历的流程要复杂得多。最终，当再有该节点附近的用户访问这个 JS 脚本，CDN 系统分配的就近节点服务器就可以很快将资源交付到客户端了。

CDN 存在的一些弊端

但也正是因为其中间的过程如此复杂，从而带来了一些问题。还是以这个 JS 脚本为例。

首先，最直接的影响，由于客户端到源站之间存在多级缓存，注定了这个已经被“分发”了很久的 JS 脚本藏匿在了整个系统的各个节点之中，开发者无法有效将可能存在的缓存清除掉。当有一天这个 JS 脚本迎来了某次重要更新，但开发者只能将数据源站的这个 JS 脚本覆盖掉，远在世界各地的用户们却依然使用着来自链路中某一节点提供的旧版本缓存。

虽然CDN搭建服务商一般都提供了清除 CDN 缓存的接口，但这并不总是有效。为了解决这一问题，前端工程化的道路上也演化出了非覆盖更新的解决方案，即不再简单地对源站资源进行覆盖，而是提供当前版本重新命名的资源文件，比如主流的，为文件生成当前版本的唯一 hash 并加入到文件名中。

然后，也正是因为从客户端到源站之间如此复杂不可预知，这中间不论对于开发者还是用户而言，都是一个不可知的黑盒，一旦中间某一个环节出现问题，比如就近节点网络运营商故障，某一级节点服务器故障或遭受攻击等，都可能给最终用户对服务的可访问性带来变数。

而那次“血案”，也正是由此而来。

话说那次“血案”

话说我们一直用着阿里云的 OSS 和 CDN 服务，这里 OSS 就充当了源站的角色，一切都是那般岁月静好，相安无事，直到某年某月……

就在这一月，我们位于祖国 G 省的用户开始出现零星反馈：我们的主业务页面无法进行微信分享了，但是别的页面可以分享。于是大家赶紧掏出自己的手机打开分享，结果并没有问题，于是猜想，可能是用户手机有问题或者当时的网络环境不稳定吧。而后续对问题的追踪也确实“印证”了猜想，不久之后用户反馈已经没问题了。就这样，大家也都没当回事，一切还是那般“岁月静好”。就这样，又过了一个月，噩梦开始了，我也入职了（泪目。。。）……

新的一月开始，客服群开始三天两头反馈 G 省用户页面不能分享，渐渐变成每天两三个甚至更多，问题也不再局限于页面不能分享，什么按钮点不动、某个功能不好使了、页面一直在 loading 等等五花八门，而我们内心则开始七上八下焦头烂额。毫无疑问，问题的严重程度已经开始影响当地的业务开展了，然而位于公司本部的我们却是两眼一抹黑，根本无法复现问题。当时对一句话体会很深，未知的才是最令人恐惧的。一想到这个问题可能蔓延至全国，就不禁一阵头皮发麻，好在问题一直局限在一省之内。

虽然未知令人恐惧，但是也不得不硬着头皮对反馈的各个案例进行归并总结。

根据反馈，页面的样式没有问题，问题都出在了一些功能点上，并且问题也不再局限在单一页面上，所以最初的结论是某个 js 脚本出了问题，并且这个脚本是多个页面公用的。于是开始检查公共方法，修改一些不太合理的地方，甚至资源重命名，然后覆盖源站对应的文件，找远在千里之外存在问题的用户配合验证，就这样结果时好时坏，而每天来自客服的问题反馈也从未间断，最后我们甚至一度怀疑，是不是微信的 sdk 有问题了，是不是我们用的某个 jQuery 版本是有问题的等等。但现实总是无情打脸，现在回想，当时仿佛没头苍蝇一般的瞎猜瞎试有些令人啼笑皆非，但在当时，每一次尝试都仿佛救命稻草。

就这样一周多的时间过去了，这个问题的重心也“诡异地”慢慢转移到我的身上，心想这是入职考验吗，每天只感觉身心俱疲压力山大。每天都要尝试与当地用户沟通，面临地域差异带来的语言和沟通障碍，与当地市场负责人沟通，面对对方的质疑、吐槽和抱怨。但每个愿意配合的用户都是异常珍贵的，虽然沟通成本巨大，但也没办法。什么叫举步维艰，彼时体会深刻，心知这样下去真的要卷铺盖走人了，必须要寻求破局之路。

基于此前的尝试，不论是客观上还是主观上，我都清楚的认识到，第三方 JS 库是不可能出现这么严重的问题的，毕竟它们早已久经市场的考验，而我们自己的业务脚本也不可能有问题，否则为何国内其他省份都没有问题，但问题一定还是出在 JS 脚本身上。于是努力让自己沉下心来做问题分析，并持续与当地工作人员和用户沟通，但他们仅能提供简单的黑盒测试，当时内心是宝宝心里苦啊这样的:)，但好在并非没有收获。

•问题出在 JS 脚本身上•问题局限于 G 省•问题局限于使用中国移动网络的用户•问题在同一用户下时有时无，有的趋势增大

根据这几点分析，心中大概有所猜测了，可能是出在这个对我来说还很陌生的 CDN 身上了，于是进行验证。找了一个曾经有问题的相对简单的页面做了一个副本，并把其中大部分的 JS 脚本用原生 JS 替换，直接写在页面内，然后找曾经反馈问题的用户测试。

结果令人欣喜，测试页面的功能看起来没有问题了，但是依然有无法微信分享的反馈。于是尝试将 jssdk 的资源链接由我们的 cdn 链接换成了微信自己的，并把分享配置脚本迁移至页面内，所幸分享功能也看起来恢复了正常。之所以说“看起来”，是因为此时依然无法确定这个“正常”是否还是像之前那样的偶然事件。所以虽然问题已经迫在眉睫，但依然需要时间进行观察，至少这个时候已经心里有谱了。

于是，接下来的几天，继续找用户黑盒验证这个猜测的同时，开始恶补关于 CDN 的知识，并翻看关于阿里云 CDN 的接口文档。

正所谓手里有粮心中不慌，有了一定的知识储备，关于 G 省当地中国移动相关的 CDN 节点有问题的猜测也顺理成章。于是开始有意识地进一步收集遇到问题的用户访问具体资源的 ip 地址、手机型号等信息，这里主要用到了 腾讯云诊断、阿里昆仑诊断工具、Ping 等几个小工具，教用户使用的过程真是一言难尽，好在中间有同事去当地出差帮了很大的忙。而我自己则通过一个网站（https://www.17ce.com/）查看 CDN 域名对应的当地移动的节点 IP，两相对照互相印证之下，此时答案已经呼之欲出了。

通过以上两点，筛选出了几个可能有异常的 ip，然后在本地环境 ping ip，果然大部分 ip 发现了很严重的丢包情况。期间又联系同事找用户对特定 ip 进行测试，结果是有的 ip 直接无法 ping 通。所以，这也正是问题时好时坏的症结所在，因为不是所有的节点都有问题，所以用户被分配的节点有可能刚好是正常的，问题便看似消失了。

就这样又过了两三天，中间持续地 ping ip、mtr 链路测试观察并整理数据，心想这都是“血淋淋”的铁证啊:)，同时也把这八九不离十的结果反馈给我们技术老大定夺。中间又是提工单又是扯皮交涉磨洋工又是直接联系 G 省当地移动运营商各种心累。最终确定确实是节点 ip 存在问题则是一次偶然发现。

那段时间，拿到了几个疑似问题 ip 后，我开始在本地 host 文件中将 CDN 域名强制指向一个具体的 ip，然后打开浏览器 network 面板或者 fiddler 开始漫无目的刷网页抓包，就这样隔一会就换一个 ip，但也没见有什么异常。直到一天的中午，忽然发现 network 面板列表中一个资源文件变红了，不禁内心一阵激动。细看之下，竟是 jQuery，打开 preview 选项看内容，却见里面的代码变成了四五行其他的莫名奇妙的代码（现在已经记不清具体是什么了，当时也没把截个图保存起来，可惜～）。

最终，由于阿里方面迟迟未将问题解决，而且我们已经掌握了“铁证”，症结了然，于是不久就换了另一家 CDN 服务商，这场风波也如预想中那样过去了，从此“岁月静好”～比较可惜的是，至今也不知道造成那个诡异问题的根本原因是什么，偏偏只有 js 文件遭遇问题，别的类型的资源却相安无事，只有阿里单方面的“当地移动运营商问题”的说辞。