CDN现已成为互联网重要的基建之一，越来越多的网络服务离不开CDN，它的稳定性也直接影响到事务的可用性。CDN的容灾一直由美团的SRE团队在担任，在端侧鲜有计划和实践。

本文结合美团外卖事务中的具体实践，介绍了一种在端侧感知CDN可用性状况并进行自动容灾切换的计划，通过该计划可有用下降事务对CDN反常的灵敏，进步事务的可用性，一起下降CDN运维压力。期望本计划能够对被CDN问题所困扰的同学有所帮助或许启发。

1. 前语
   
2. 背景
   
3. 方针与场景
   

3.1 中心方针

3.2 适用场景

1. Phoenix 计划

4.1 总体规划

4.2 容灾流程规划

4.3 完成原理

1. 总结与展望
   
2. 前语
   作为事务研制，你是否遇到过因为 CDN 问题导致的事务图片加载失利，页面翻开缓慢，页面布局紊乱或许页面白屏？你是否又遇到过某些区域 CDN 域名反常导致事务停摆，客诉不断，此刻的你一脸茫然，手足无措？作为 CDN 运维，你是否常常被事务方反馈的各种 CDN 问题搞得焦头烂额，一边顶着各种催促和压力寻求处理计划，一边诉苦着服务商的不靠谱？今天，咱们首要介绍一下美团外卖技能团队端侧 CDN 的容灾计划，通过实践，咱们发现该产品能有用削减运维及事务开发同学的焦虑，期望咱们的这些经验也能够帮助到更多的技能团队。
   
3. 背景
   CDN 因能够有用处理因散布、带宽、服务器功用带来的网络访问推迟等问题，现已成为互联网不行或缺的一部分，也是前端事务严峻依赖的服务之一。在实践事务生产中，咱们通常会将许多的静态资源如 JS 脚本、CSS 资源、图片、视频、音频等托管至 CDN 服务，以享用其边际节点缓存对静态资源的加速。但是在享用 CDN 服务带来更好体会的一起，也常常会被 CDN 毛病所影响。比方因 CDN 边际节点反常，CDN 域名封禁等导致页面白屏、排版紊乱、图片加载失利。
   每一次的 CDN 毛病，事务方往往束手无策，只能寄期望于 CDN 团队。而 CDN 的监控与问题排查，对 SRE 也是巨大的难题和挑战。一方面，因为 CDN 节点的散布广泛，边际节点的监控就反常困难。另一方面，各事务会聚得到的 CDN 监控大盘，极大程度上隐匿了细节。小流量事务、定点区域的 CDN 反常往往会被淹没。SRE 团队也做了许多尽力，规划了多种计划来下降 CDN 反常对事务的影响，也取得了必定的效果，但一直有几个问题无法很好处理：
   时效性：当 CDN 出现问题时，SRE 会手动进行 CDN 切换，因为需要人为操作，响应时长就很难确保。别的，切换后毛病恢复时间也无法准确确保。
   有用性：切换至备份 CDN 后，备份 CDN 的可用性无法验证，别的因为 Local DNS 缓存，无法处理域名绑架和跨网访问等问题。
   精准性：CDN 的切换都是大范围的变更，无法针对某一区域或许某一项目独自进行。
   危险性：切换至备份 CDN 之后可能会导致回源，流量剧增拖垮源站，然后引发更大的危险。
   当时，美团外卖事务每天服务上亿人次，即便再小的问题在巨大的流量面前，也会被扩大成大问题。外卖的动态化架构，70%的事务资源都依赖于 CDN，所以 CDN 的可用性严峻影响着外卖事务。怎么更有用的进行 CDN 容灾，下降 CDN 反常对事务的影响，是咱们不断思考的问题。
   既然以上问题 SRE 侧无法完美地处理，端侧是不是能够进行一些测验呢？比方将 CDN 容灾前置到终端侧。不死鸟（Phoenix） 便是在这样的想象下，通过前端才能建造，不断实践和完善的一套端侧 CDN 容灾计划。该计划不仅能够有用下降 CDN 反常对事务的影响，还能进步 CDN 资源加载成功率，现已服务整个美团多个事务和 App。
   
4. 方针与场景
   3.1 中心方针
   为下降 CDN 反常对事务的影响，进步事务可用性，一起下降 SRE 同学在 CDN 运维方面的压力，在计划规划之初，咱们确定了以下方针：
   端侧 CDN 域名自动切换：在 CDN 反常时，端侧第一时间感知并自动切换 CDN 域名进行加载重试，削减对人为操作的依赖。
   CDN 域名阻隔：CDN 域名与服务厂商在区域维度完成服务阻隔且服务等效，确保 CDN 切换重试的有用性。
   更精准有用的 CDN 监控：建造更细粒度的 CDN 监控，能够依照项目维度实时监控 CDN 可用性，处理 SRE CDN 监控粒度不足，告警滞后等问题。并依据容灾监控对 CDN 容灾战略实施动态调整，削减 SRE 切换 CDN 的频率。
   域名持续热备：确保每个 CDN 域名的持续预热，防止流量切换时导致回源。
   3.2 适用场景
   适用一切依赖 CDN ，期望下降 CDN 反常对事务影响的端侧场景，包括 Web、SSR Web、Native 等技能场景。
   
5. Phoenix 计划
   一直以来，CDN 的稳定性是由 SRE 来确保，容灾办法也一直在 SRE 侧进行，但只是依靠链路层面上的确保，很难处理局部问题和完成快速止损。用户终端作为事务的终究投放载体，对资源加载有着天然的独立性和灵敏性。假如将 CDN 容灾前置到终端侧，无论从时效性，精准性，都是 SRE 侧无法比拟的。在端侧进行容灾，就需要感知 CDN 的可用性，然后完成端侧自动切换的才能。咱们调研整个前端范畴，并未发现业内在端侧 CDN 容灾方面有所实践和输出，所以整个计划的完成是从无到有的一个进程。
   4.1 总体规划
   
   

图 1

Phoenix 端侧 CDN 容灾计划首要由五部分组成：

端侧容灾 SDK：担任端侧资源加载感知，CDN 切换重试，监控上报。

动态核算服务：依据端侧 SDK 上报数据，对多组等效域名依照城市、项目、时段等维度守时轮询核算域名可用性，动态调整流量至最优 CDN。一起也是对 CDN 可用性的日常巡检。

容灾监控渠道：从项目维度和大盘维度供给 CDN 可用性监控和告警，为问题排查供给具体信息。

CDN 服务：供给完善的 CDN 链路服务，在架构上完成域名阻隔，并为事务方供给等效域名服务，确保端侧容灾的有用性。等效域名，便是能够通过相同路径访问到同一资源的域名，比方：cdn1.meituan.net/src/js/test.js 和 cdn2.meituan.net/src/js/test.js 能够回来相同内容，则 cdn1.meituan.net 和 cdn2.meituan.net 互为等效域名。

容灾装备渠道：对项目容灾域名进行装备管理，监控上报战略管理，并供给 CDN 流量人工干预等办法。

4.2 容灾流程规划

为确保各个端侧容灾效果和监控方针的一致性，咱们规划了一致的容灾流程，全体流程如下：

图 2

4.3 完成原理

4.3.1 端侧容灾 SDK

Web 端完成

Web 端的 CDN 资源首要是 JS、CSS 和图片，所以咱们的容灾方针也聚集于这些。在 Web 侧的容灾，咱们首要完成了对静态资源，异步资源和图片资源的容灾。

完成思路

要完成资源的容灾，最首要的问题是感知资源加载成果。通常咱们是在资源标签上面增加过错回调来捕获，图片容灾能够这样完成，但这并不合适 JS，因为它有严格的执行顺序。为了处理这一问题，咱们将传统的标签加载资源的方法，换成XHR来完成。通过Webpack在工程构建阶段把同步资源进行抽离，然后通过PhoenixLoader来加载资源。这样就能通过网络恳求回来的状况码，来感知资源加载成果。

在计划的完成上，咱们将 SDK 规划成了 Webpack Plugin，首要根据以下四点考虑：

通用性：美团前端技能栈相对较多，要确保容灾 SDK 能够掩盖大部分的技能结构。

易用性：过高的接入本钱会增加开发人员的工作量，不能做到对事务的有用掩盖，计划价值也就无从谈起。

稳定性：计划要保持稳定牢靠，不受 CDN 可用性搅扰。

侵入性：不能侵入到正常事务，要做到即插即用，确保事务的稳定性。

通过调研制现，前端有 70%的工程构建都离不开 Webpack，而 Webpack Plugin 独立装备，即插即用的特性，是完成计划的最好挑选。全体计划规划如下：

图 3

当然，许多团队在做功用优化时，会采纳代码分割，按需引入的方法。这部分资源在同步资源生成的进程中无法感知，但这部分资源的加载成果，也关系到事务的可用性。在对异步资源的容灾方面，咱们首要是通过对 Webpack 的异步资源处理方法进行重写，运用Phoenix Loader接管资源加载，然后完成异步资源的容灾。全体分析进程如下图所示：

图 4

CSS 资源的处理与 JS 有所不同，但原理类似，只需要重写 mini-css-extract-plugin 的异步加载完成即可。

Web 端计划资源加载示意：

图 5

容灾效果

图6 容灾大盘

图7 容灾事例

Native 端容灾

客户端的 CDN 资源首要是图片，音视频以及各种动态化计划的 bundle 资源。Native 端的容灾建造也首要围绕上述资源展开。

完成思路

从头恳求是 Native 端 CDN 容灾计划的根本原理，依据互备 CDN 域名，由 Native 容灾基建容灾域名从头进行恳求资源，整个进程发生在原始恳求失利后。Native 容灾基建不会在原始恳求进程中进行任何操作，防止对原始恳求发生影响。原始恳求失利后，Native 容灾基建代理处理失利回来，事务方仍处于等候成果状况，重请新求完毕后向事务方回来终究成果。整个进程中从事务方角度来看仍只宣布一次恳求，收到一次成果，然后到达事务方不感知的目的。为将从头恳求效率提升至最佳，有必要尽可能的确保从头恳求次数趋向于最小。

调研事务的重视点和技能层面运用的网络结构，结合 Phoenix 容灾计划的根本流程，在计划规划方面，咱们首要考虑以下几点：

快捷性：接入的快捷性是 SDK 规划时首要考虑的内容，即事务方能够用最简略的方法接入，完成资源容灾，一起也能够简略无残留撤除 SDK。

兼容性：Android 侧的特殊性在于多样的网络结构，集团内包括 Retrofit 结构，okHttp 结构，okHttp3 结构及现已很少运用的 URLConnection 结构。供给的 SDK 应当与各种网络结构兼容，一起事务方在即便变更网络结构也能够以最小的本钱完成容灾功用。而 iOS 侧则考虑复用一个 NSURLProtocol 去完成对恳求的阻拦，下降代码的冗余度，一起完成对初始化项进行一致适配。

扩展性：需要在基础功用之上供给可选的高级装备来满足特殊需求，包括监控方面也要供给特殊的监控数据上报才能。

根据以上规划关键，咱们将 Phoenix 划分为以下结构图，图中将全体的容灾 SDK 拆分为两部分 Phoenix-Adaptor 部分与 Phoenix-Base 部分。

图 8

Phoenix-Base

Phoenix-Base 是整个 Phoenix 容灾的中心部分，其包括容灾数据缓存，域名替换组件，容灾恳求执行器（差异于原始恳求执行器），监控器四个对外不行见的内部功用模块，并包括外部接入模块，供给外部接入功用。

容灾数据缓存：定期获取及更新容灾数据，其发生的数据只会被域名替换组件运用。

域名替换组件：衔接容灾数据缓存，容灾恳求执行器，监控器的中心节点，担任匹配原始失利 Host，过滤过错码，并向容灾恳求执行器供给容灾域名，向监控器供给整个容灾进程的具体数据副本。

容灾执行器：容灾恳求的真实恳求者，目前选用内部 OkHttp3Client，事务方也能够自主切换至本身的执行器。

监控器：分发容灾进程的具体数据，内置数据大盘的上报，若有外部自定义的监控器，也会向自定义监控器分发数据。

Phoenix-Adaptor

Phoenix-Adaptor 是 Phoenix 容灾的扩展适配部分，用于兼容各种网络结构。

绑定器：生成合适各个网络结构的阻拦器并绑定至原始恳求执行者。

解析器：将网络结构的 Request 转换为 Phoenix 内部执行器的 Request，并将 Phoenix 内部执行器的 Response 解析为外部网络结构 Response，以此到达适配目的。

容灾效果

① 事务成功率

以外卖图片事务为例，Android 事务成功率比照（同版别 7512，2021.01.17 未敞开 Phoenix 容灾，2021.01.19 晚敞开 Phoenix 容灾）。

图 9

iOS 事务成功率比照（同版别 7511，2021.01.17 未敞开 Phoenix 容灾，2021.01.19 晚敞开 Phoenix 容灾）。

图 10

② 危险应对

以外卖与美团图片做为比照 ，在 CDN 服务出现反常时，接入 Phoenix 的外卖 App 和未接入的美团 App 在图片成功率方面的比照。

图 11

4.3.2 动态核算服务

端侧的域名重试，会在某一域名加载资源失利后，依据容灾列表顺次进行重试，直至成功或许失利。如下图所示：

图 12

假如域名 A 大范围反常，端侧依然会首要进行域名 A 的重试加载，这样就导致不必要的重试本钱。怎么让资源的初次加载愈加稳定有用，怎么为不同事务和区域动态供给最优的 CDN 域名列表，这便是动态核算服务的要处理的问题。

核算原理

动态核算服务通过域名池和项目的 Appkey 进行关联，依照不同省份、不同地级市、不同项目、不同资源等维度进行战略管理。通过获取 5 分钟内对应项目上报的资源加载成果进行守时轮询核算，对域名池中的域名依照区域（城市&&省份）的可用性监控。核算服务会依据域名可用性动态调整域名顺序并对成果进行输出。下图是一次完整的核算进程：

图 13

假设有 A、B、C 三个域名，成功率别离是 99%、98%、97.8%，流量占比别离是 90%、6%、4%。根据搬运基准，进行流量搬运，比方，A 和 B 成功率差值是 1，B 需要把自己 1/2 的流量搬运给 A，一起 A 和 C 的成功率差值大于 1，C 也需要把自己 1/2 的流量搬运给 A，一起 B 和 C 的差值是 0.2，所以 C 还需要把自己 1/4 的流量搬运给 B。终究，通过核算，A 的流量占比是 95%，B 是 3.5%，C 是 1.5%。最后，通过排序和随机核算后将终究成果输出。

因为 A 的占比最大，所以 A 优先被挑选；通过随机，B 和 C 也会有必定的流量；根据搬运基准，能够完成流量的平稳切换。

反常引发

当某个 CDN 无法正常访问的时候，该 CDN 访问流量会由核算进程切换至等效的 CDN B。假如 SRE 发现切换过慢能够进行手动干预分配流量。当少量的 A 域名成功率上升后，会重复核算进程将 A 的流量加大。直至恢复初始态。

图 14

服务效果

动态核算服务使得资源的初次加载成功率由原来的99.7%提升至99.9%。下图为接入动态核算后资源加载成功率与未接入加载成功率比照。

图 15

4.3.3 容灾监控

在监控层面，SRE 团队往往只重视域名、大区域、运营商等复合维度的监控方针，监控流量巨大，对于小流量事务或许小范围区域的 CDN 动摇，可能就无法被监控分析识别，进而也就无法感知 CDN 边际节点反常。容灾监控建造，首要是为了处理 SRE 团队的 CDN 监控告警滞后和监控粒度问题。监控全体规划如下：

图 16

流程规划

端侧容灾数据的上报，别离依照项目、App、资源、域名等维度树立监控方针，将 CDN 可用性变成项目可用性的一部分。通过核算渠道对数据进行分析聚合，形成 CDN 可用性大盘，依照域名、区域、项目、时间等维度进行输出，与天网监控互通，树立分钟级别的监控告警机制，大大提升了 CDN 反常感知的灵敏性。一起，SRE 侧的天网监控，也会对动态核算服务成果发生干预。监控全体流程如下：

图 17

监控效果

CDN 监控不仅从项目维度愈加细粒度的监测 CDN 可用性，还为 CDN 反常排查供给了区域、运营商、网络状况、回来码等更丰厚的信息。在监控告警方面，完成了分钟级反常告警，灵敏度也高于美团内部的监控系统。

图 18

4.3.4 CDN 服务

端侧域名切换的有用性，离不开 CDN 服务的支持。在 CDN 服务方面，在原有 SRE 侧容灾的基础上，对 CDN 服务全体做了升级，完成域名阻隔，处理了单域名对应多 CDN 和多域名对应单 CDN 重试无效的坏处。

图 19

5. 总结与展望

通过一年的建造与发展，Phoenix CDN 容灾计划日趋老练，现已成为美团在 CDN 容灾方面仅有的公共服务，在屡次 CDN 反常中发挥了巨大的效果。在端侧，当时该计划日均容灾资源3000万+，挽回用户35万+，掩盖外卖，酒旅，餐饮，优选，买菜等事务部门，服务200+个工程，外卖 App、美团 App、大众点评 App均已接入。

在 SRE 侧，完成了项目维度的分钟级精准告警，一起丰厚了反常信息，大大进步了 SRE 问题排查效率。自从计划大规模落地以来，CDN 反常时鲜有手动切换操作，极大减轻了 SRE 同学的运维压力。

因为前端技能的多样性和复杂性，咱们的 SDK 无法掩盖一切的技能计划，所以在接下来的建造中，咱们会积极推行咱们的容灾原理，揭露动态核算服务，期望更多的结构和服务在咱们的容灾思想上，贴合本身事务完成端侧的 CDN 容灾。