共计 6997 个字符，预计需要花费 18 分钟才能阅读完成。
CDN 曾经成为互联网重要的基建之一，越来越多的网络服务离不开 CDN，它的稳定性也间接影响到业务的可用性。CDN 的容灾始终由美团的 SRE 团队在负责，在端侧鲜有计划和实际。本文联合美团外卖业务中的具体实际，介绍了一种在端侧感知 CDN 可用性情况并进行主动容灾切换的计划，通过该计划可无效升高业务对 CDN 异样的敏感，进步业务的可用性，同时升高 CDN 运维压力。心愿本计划可能对被 CDN 问题所困扰的同学有所帮忙或者启发。
1. 前言
作为业务研发，你是否遇到过因为 CDN 问题导致的业务图片加载失败，页面关上迟缓，页面布局错乱或者页面白屏？你是否又遇到过某些区域 CDN 域名异样导致业务停摆，客诉一直，此时的你一脸茫然，手足无措？作为 CDN 运维，你是否经常被业务方反馈的各种 CDN 问题搞得焦头烂额，一边顶着各种督促和压力寻求解决方案，一边埋怨着服务商的不靠谱？明天，咱们次要介绍一下美团外卖技术团队端侧 CDN 的容灾计划，通过实际，咱们发现该产品能无效缩小运维及业务开发同学的焦虑，心愿咱们的这些教训也可能帮忙到更多的技术团队。
2. 背景
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。
3. 指标与场景
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 等技术场景。
4. Phoenix 计划
始终以来，CDN 的稳定性是由 SRE 来保障，容灾措施也始终在 SRE 侧进行，但仅仅依附链路层面上的保障，很难解决部分问题和实现疾速止损。用户终端作为业务的最终投放载体，对资源加载有着人造的独立性和敏感性。如果将 CDN 容灾前置到终端侧，无论从时效性，精准性，都是 SRE 侧无法比拟的。在端侧进行容灾，就须要感知 CDN 的可用性，而后实现端侧主动切换的能力。咱们调研整个前端畛域，并未发现业内在端侧 CDN 容灾方面有所实际和输入，所以整个计划的实现是从无到有的一个过程。
4.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 容灾流程设计
为保障各个端侧容灾成果和监控指标的一致性，咱们设计了对立的容灾流程，整体流程如下：
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 独立配置，即插即用的个性，是实现计划的最好抉择。整体方案设计如下：
当然，很多团队在做性能优化时，会采取代码宰割，按需引入的形式。这部分资源在同步资源生成的过程中无奈感知，但这部分资源的加载后果，也关系到业务的可用性。在对异步资源的容灾方面，咱们次要是通过对 Webpack 的异步资源解决形式进行重写，应用 Phoenix Loader 接管资源加载，从而实现异步资源的容灾。整体剖析过程如下图所示：
CSS 资源的解决与 JS 有所差异，但原理类似，只须要重写 mini-css-extract-plugin 的异步加载实现即可。
Web 端计划资源加载示意：
容灾成果
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 局部。
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 容灾）。
iOS 业务成功率比照（同版本 7511，2021.01.17 未开启 Phoenix 容灾，2021.01.19 晚开启 Phoenix 容灾）。
② 危险应答
以外卖与美团图片做为比照，在 CDN 服务出现异常时，接入 Phoenix 的外卖 App 和未接入的美团 App 在图片成功率方面的比照。
4.3.2 动静计算服务
端侧的域名重试，会在某一域名加载资源失败后，依据容灾列表顺次进行重试，直至胜利或者失败。如下图所示：
如果域名 A 大范畴异样，端侧仍然会首先进行域名 A 的重试加载，这样就导致不必要的重试老本。如何让资源的首次加载更加稳固无效，如何为不同业务和地区动静提供最优的 CDN 域名列表，这就是动静计算服务的要解决的问题。
计算原理
动静计算服务通过域名池和我的项目的 Appkey 进行关联，依照不同省份、不同地级市、不同我的项目、不同资源等维度进行策略管理。通过获取 5 分钟内对应我的项目上报的资源加载后果进行 定时轮询计算，对域名池中的域名依照地区（城市 && 省份）的可用性监控。计算服务会依据域名可用性动静调整域名程序并对后果进行输入。下图是一次残缺的计算过程：
假如有 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 的流量加大。直至复原初始态。
服务成果
动静计算服务使得资源的首次加载成功率由原来的99.7% 晋升至 99.9%。下图为接入动静计算后资源加载成功率与未接入加载成功率比照。
4.3.3 容灾监控
在监控层面，SRE 团队往往只关注域名、大区域、运营商等复合维度的监控指标，监控流量微小，对于小流量业务或者小范畴区域的 CDN 稳定，可能就无奈被监控剖析辨认，进而也就无奈感知 CDN 边缘节点异样。容灾监控建设，次要是为了解决 SRE 团队的 CDN 监控告警滞后和监控粒度问题。监控整体设计如下：
流程设计
端侧容灾数据的上报，别离依照 我的项目、App、资源、域名 等维度建设监控指标，将 CDN 可用性变成我的项目可用性的一部分。通过计算平台对数据进行剖析聚合，造成 CDN 可用性大盘，依照域名、区域、我的项目、工夫等维度进行输入，与天网监控互通，建设分钟级别的监控告警机制，大大晋升了 CDN 异样感知的灵敏性。同时，SRE 侧的天网监控，也会对动静计算服务后果产生干涉。监控整体流程如下：
监控成果
CDN 监控不仅从我的项目维度更加细粒度的监测 CDN 可用性，还为 CDN 异样排查提供了区域、运营商、网络情况、返回码等更丰盛的信息。在监控告警方面，实现了分钟级异样告警，灵敏度也高于美团外部的监控零碎。
4.3.4 CDN 服务
端侧域名切换的有效性，离不开 CDN 服务的反对。在 CDN 服务方面，在原有 SRE 侧容灾的根底上，对 CDN 服务整体做了降级，实现域名隔离，解决了单域名对应多 CDN 和多域名对应单 CDN 重试有效的弊病。
5. 总结与瞻望
通过一年的建设与倒退，Phoenix CDN 容灾计划日趋成熟，现已成为美团在 CDN 容灾方面惟一的公共服务，在屡次 CDN 异样中施展了微小的作用。在端侧，以后该计划日均容灾资源 3000 万 +，挽回用户35 万 +，笼罩外卖，酒旅，餐饮，优选，买菜等业务部门，服务 200+ 个工程， 外卖 App、美团 App、公众点评 App均已接入。
在 SRE 侧，实现了我的项目维度的分钟级精准告警，同时丰盛了异样信息，大大提高了 SRE 问题排查效率。自从计划大规模落地以来，CDN 异样时鲜有手动切换操作，极大加重了 SRE 同学的运维压力。
因为前端技术的多样性和复杂性，咱们的 SDK 无奈笼罩所有的技术计划，所以在接下来的建设中，咱们会踊跃推广咱们的容灾原理，公开动静计算服务，心愿更多的框架和服务在咱们的容灾思维上，贴合本身业务实现端侧的 CDN 容灾。另外，针对计划自身，咱们会一直优化资源加载性能，欠缺资源验签，智能切换等能力，也欢送对 Phoenix CDN 容灾计划有趣味的同学，跟咱们一起探讨交换。同时更欢送退出咱们，文末附招聘信息，期待你的邮件。
6. 作者简介
魏磊、陈彤、张群、粤俊等，均来自美团外卖平台 - 大前端团队，丁磊、心澎，来自美团餐饮 SaaS 团队。
7. 招聘信息
美团外卖平台 - 大前端团队是一个凋谢、翻新、无边界的团队，激励每一位同学谋求本人的技术幻想。团队长期招聘 Android、iOS、FE 高级 / 资深工程师和技术专家。欢送感兴趣的同学投递简历至：wangxiaofei03@meituan.com（邮件题目请注明：美团外卖大前端）。
浏览美团技术团队更多技术文章合集
前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试
| 在公众号菜单栏对话框回复【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词，可查看美团技术团队历年技术文章合集。
| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至 tech@meituan.com 申请受权。
