总第485篇2022年第002篇CDN的容灾总结与展望

第 485 条

2022年第002条

CDN已经成为互联网的重要基础设施之一。越来越多的网络服务离不开CDN，其稳定性也直接影响服务的可用性。CDN的容灾一直由美团的SRE团队负责，设备端的解决方案和实践很少。

本文结合美团外卖业务的具体实践，介绍了一种在设备端感知CDN可用性状态并进行容灾自动切换的解决方案。该方案可以有效降低业务对CDN异常的敏感性，提高业务可用性，同时减轻CDN运维压力。我希望这个解决方案可以帮助或启发被CDN问题困扰的学生。

1. 前言

2. 背景

3. 目标和场景

3.1 核心目标

3.2 适用场景

4. 凤凰解决方案

4.1 整体设计

4.2 容灾流程设计

4.3 实现原理

5. 总结与展望

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容灾。在这样的假设下，凤凰通过前端能力建设，不断实践和完善一套端到端的CDN容灾解决方案。该方案不仅可以有效降低CDN异常对业务的影响，还可以提高CDN资源加载的成功率。目前已经服务了整个美团的多个业务和应用。

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. 凤凰解决方案

长期以来，CDN 的稳定性由 SRE 保障，SRE 侧也进行了容灾措施。但是，仅仅依靠链路层面的保证，很难解决局部问题，实现快速止损。用户终端作为服务的最终交付载体，具有天然的独立性和对资源加载的敏感性。如果终端侧预装CDN容灾，时效性和准确性是SRE侧无法比拟的。在设备端进行容灾，需要感知CDN的可用性，进而实现设备端自动切换的能力。我们调查了整个前端领域，发现在端侧CDN容灾方面没有实践和输出，

4.1 整体设计

ͼ 1

凤凰端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资源主要是图片、音视频，以及各种动态方案的捆绑资源。Native侧的容灾建设也主要围绕上述资源进行。

实现想法

重请求是原生CDN容灾方案的基本原理。根据互备CDN域名，Native容灾基础设施的容灾域名会重新请求资源。整个过程发生在原始请求失败之后。原生容灾基础设施在原始请求期间不会进行任何操作，以免影响原始请求。原请求失败后，Native容灾基础代理处理失败返回，业务方仍在等待结果。重请求结束后，将最终结果返回给业务方。整个过程中，从业务方的角度来看，只发送一个请求，接收一次结果，从而达到业务方感知不到的目的。为了最大化重请求效率，需要保证重请求的数量趋于尽可能少。

研究业务的重点和技术层面使用的网络框架，结合凤凰容灾解决方案的基本流程，在方案设计上，我们主要考虑以下几点：

便捷性：接入的便捷性是SDK设计的首要考虑，即业务方可以以最简单的方式接入，实现资源容灾，同时SDK可以简单无残留地移除.

兼容性：Android端的特殊性在于各种网络框架。该组包括很少使用的Retrofit框架、okHttp框架、okHttp3框架和URLConnection框架。提供的SDK要兼容各种网络框架，同时即使业务方改变网络框架，也能以最小的成本实现容灾功能。在 iOS 端，考虑复用一个 NSURLProtocol 来拦截请求，减少代码冗余，实现初始化项的统一适配。

可扩展性：需要在基本功能之上提供可选的高级配置以满足特殊需求，包括监控方面的特殊监控数据上报能力。

基于以上设计要点，我们将Phoenix分为如下结构图。图中，整体容灾SDK分为两部分：Phoenix-Adaptor部分和Phoenix-Base部分。

ͼ 8

凤凰基地

Phoenix-Base是整个Phoenix容灾的核心部分，包括容灾数据缓存、域名替换组件、容灾请求执行器（不同于原来的请求执行器）、监控四个不可见的内部功能模块，并包含外部访问模块提供外部访问功能。

容灾数据缓存：定期获取和更新容灾数据，生成的数据仅供域名替换组件使用。

域名替换组件：连接容灾数据缓存、容灾请求执行器、监控中心节点，负责匹配原故障主机，过滤错误码，提供容灾域名给灾难恢复请求执行器，并为监视器提供整个存储容量。灾难过程的详细数据副本。

容灾执行器：容灾请求的真正请求者目前使用内部的OkHttp3Client，业务端也可以独立切换到自己的执行器。

监控：分发灾备过程的详细数据，并上报内置数据盘。如果有外部自定义监视器，数据也会分发到自定义监视器。

凤凰适配器

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

绑定器：生成适合每个网络框架的拦截器并绑定到原始请求执行者。

Parser：将网络框架的Request转换成Phoenix内部执行器的Request，将Phoenix内部执行器的Response解析成外部网络框架的Response，从而达到适配的目的。

灾难恢复效果

创业成功率

以外卖图片业务为例，Android业务成功率对比（同版本7512、2021.01.17无凤凰容灾、2021.0< @1.19 晚）启用 Phoenix 灾难恢复）。

ͼ 9

iOS业务成功率对比（同版本7511、2021.01.17无凤凰容灾，2021.01.19夜开启凤凰容灾）。

ͼ 10

风险应对

外卖和美团图片对比，CDN服务异常时，外卖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

流程设计

端到端容灾数据的上报，基于项目、应用、资源、域名等维度建立监控指标，CDN可用性成为项目可用性的一部分。通过计算平台对数据进行分析汇总，形成CDN可用性仪表盘，按域名、地区、项目、时间等维度输出，并与天网监控通信，建立分钟级监控报警机制，大大提高了CDN异常感知的灵敏度。. 同时，SRE端的天网监控也会干扰动态计算服务的结果。整体监控流程如下：

ͼ 17

监测效果

CDN 监控不仅从项目维度更细化地监控 CDN 可用性，还为 CDN 异常排查提供更丰富的地区、运营商、网络状态、返回码等信息。在监控告警方面，实现分钟级异常告警，灵敏度也高于美团内部监控系统。

ͼ 18

4.3.4 CDN 服务

客户端域名切换的有效性离不开CDN服务的支持。CDN服务方面，在原有SRE端容灾的基础上，对整体CDN服务进行了升级，实现域名隔离，解决了单个域名对应多个CDN、多个域名对应单个的无效性。 CDN 重试。

ͼ 19

5. 总结与展望

经过一年的建设和发展，凤凰CDN容灾解决方案已经越来越成熟。成为美团在CDN容灾中唯一的公共服务，在众多CDN异常中发挥了巨大的作用。终端方面，该解决方案目前日均容灾资源3000万+，恢复用户35万+，覆盖外卖、酒旅、餐饮、选品、买菜等业务部门，服务200+项目、外卖APP和美团应用程序。, 大众点评App已连接。

在SRE侧，实现了项目维度的分钟级精准告警，丰富了异常信息，大大提升了SRE排查效率。自该方案大规模落地以来，很少在CDN异常时进行人工切换操作，大大减轻了SRE同学的运维压力。

由于前端技术的多样性和复杂性，我们的SDK无法覆盖所有的技术方案，所以在接下来的建设中，我们会积极推广我们的容灾原则，公开动态计算服务，希望更多的框架和服务在我们的灾难中恢复思路，我们根据自己的业务实施端侧CDN容灾。此外，对于解决方案本身，我们将持续优化资源加载性能，提升资源签名验证、智能切换等能力。也欢迎对凤凰CDN容灾解决方案感兴趣的同学与我们探讨。同时，更欢迎您加入我们。招聘信息附在文末。我期待着你的电子邮件。

6. 关于作者

魏磊、陈彤、张群、岳君等均来自美团外卖平台——大前端团队，丁磊、辛鹏，来自美团餐饮SaaS团队。

– – – – – 结尾 – – – – –

工作邀请