字节跳动大规模多云CDN管理与产品化实践

在世界杯等大规模流量突发的情况下，作为承载抖音集团业务核心流量的基础设施，在运维效率、质量方面都可观测、调度、容灾、成本可观测与优化方面都遇到了很多的挑战。LiveVideoStackCon 2023上海站邀请了火山引擎边缘云融合CDN团队负责人孙益星介绍火山引擎在多云应用架构下的CDN运维管理解决方案。

文/孙益星

编辑/LiveVideoStack

大家好，我是来自火山引擎边缘云融合CDN团队的孙益星，主要负责多云平台的建设。

今天主要想跟大家分享的内容包括三个部分：

第一部分是介绍下我们团队在过去几年面向字节内部业务，持续建设一个多云CDN平台的演进过程；

第二部分主要是介绍在这个过程中我们所面临的一些主要难点和挑战，以及是怎么解决的；

最后是介绍我们接下来的主要投入方向：如何把我们的能力开放出来，以产品的形式提供给火山引擎的用户和开发者。

-01-

字节多云CDN平台的演进

首先为大家介绍一下我们面向内部业务的多云CDN平台，包括这个平台有什么用以及要解决的到底是什么问题。

字节跳动有很多流量型的业务，包括抖音、头条、西瓜视频等。为了承载这样的流量，团队使用了各种各样流量加速的产品，包括静态加速、动态加速、域名解析、证书管理以及与各种配套的解决方案，比如源站缓存、回源调度、边缘函数等。

从业务角度出发，如果有一个平台能够直接管理所有加速域名的配置，这将会带来很大便利。只需要把源站储存的信息发送给平台，剩下的配置解析、流量分配、质量管理等都是由平台完成。

于是字节多云CDN平台——我们叫做融合CDN平台——应运而生，它向上承接所有业务方的CDN加速场景需求，底层对接不同的公有云服务，包含静态加速、动态加速等，这些服务本身由不同的厂商来提供，业务方在上层不需要关心它所对接的是哪些厂商，也不关心具体功能需求在不同的厂商上应该分别怎么去实现，它要做的事情就是把需求提给平台，然后由平台协调不同厂商的资源，最终再交付给业务。对于业务方来说，这就是一个普通的CDN服务平台，像是一家厂商提供的打包的服务一样，所以业内有个比较通俗的称谓是融合CDN平台。

业务对于这个平台的诉求有以下几点：

第一个诉求是质量：业务对平台的加速服务能力是有预期的，平台有责任保障上层的每一个域名的可用性和加速效果；

第二个诉求是成本：成本越便宜越好；

第三个诉求是功能：不同业务有比较大的差异的，比如访问鉴权、回源rewrite，缓存时间等。每个业务都会有自己的设计和需求，作为融合平台需要理解这些设计的差异，然后将它转换成厂商可满足的服务需求，最后实现、验证、最后交付给业务方；

第四个诉求是服务：这个是比较宽泛的概念，就是当我们完成了一系列的资源的配置工作后，业务在日常使用中需要看监控，看报表，刷新预热、排查问题，提一些on call，这些都需要对应的服务能力来支持。

总结下来，上层业务对于平台有四个方面的需求：质量、成本、功能以及服务，这个是上层业务对于平台的需求。

从平台的角度考虑，厂商越少，复杂度的可能性就会越低。但由于这是一个融合平台，所以需要从所有字节的业务体系的角度考虑问题。

首先就是资源的保障，资源方面要能承载日常一两百T的业务带宽，这已经超出了绝大部分厂商的资源储备。

另一方面是在例如春晚、618、世界杯或者演出赛事这种大型的活动筹备时，我们很难在单个厂商上找到充足的冗余，这个冗余可能是超出常规业务量的一倍或者更多的需求，总资源池子需要多个供应商一起协调资源。

其次是质量，用户分布在全国各地甚至全世界，而用户体验跟节点的访问质量密切相关，不同厂商在不同地区、不同运营商的节点分布是有比较大的差异的。这会导致在实际的业务表现中，这个地区厂商质量的排序是ABC，另一个地区就变成了CAB，这种情况在海外会更明显。对于那些时刻要求最优服务资源的业务来说，很难通过单个厂商来满足要求。

质量的另一个体现形式是可用性，地区性的节点不可用是经常发生的，这会造成业务的质量波动。另外，大规模的厂商故障也时常会发生，如果只绑定一家厂商，那么它故障时流量切换也会带来明显的质量影响。所以对我们来说，保证流量较为分散的分配在多个供应商是一个必要的措施。

价格方面也有多厂商的考虑，价格并不是越便宜越好。不同的业务对于质量的要求是不同的，有些对于用户体验不敏感的业务会更关注成本，对质量的要求就没有那么高；另一部分业务为了更好的质量，就对价格容忍度更高一些。平台需要价格和质量层面为不同的业务找到不同的厂商，选出一个最合适的方案。

最后是功能和服务的支持，有多个厂商就可以在我们有新的功能需求的时候，缩短从联调到测试到上线的周期，在排查具体问题的时候也能给我们更多的信息反馈。

作为一个融合平台，我们的目标并不是要对接尽可能多的厂商，或者对接尽可能少的厂商。而是如果需要让整个业务达到这样一个理想的状态，多厂商基本是一个唯一的方案。在这个方案里，资源是动态变化的，不存在一种资源在各种场景下都是最好的。而是不同场景下总有一个最合适的，而平台在这里的职责就是向业务方高效的交付那些最合适的资源，并保证这些资源的可靠性，这是这个平台的核心能力。

平台的建设经过了两个阶段：

第一阶段是最原始的方式：我们会有固定的几个SRE，每个人固定的对接几个业务。大一些的业务可能会有多个专职，小一些的可能会由一个SRE对接多个业务。每个人都比较熟悉自己所对接的业务的需求和背景，按照自己的经验去厂商控制台上去配置，具体的要求也直接跟厂商的技术人员去沟通。在这个初始阶段中，主要靠人的能力来支撑；

第二阶段开始有些通用的功能需求被提出放在平台里：比如说看域名的配置，数据，调流量。于是平台的功能被分成不同的功能方向分别被建设。并且不同类型的资源有不同的团队分别去实现。在这个阶段中由于业务不断有需求进来，整个平台的设计是在被需求拖着走的。这中间暴露出了一些问题，比如权限设计、接口规范不统一、数据一致性有问题等。

经过这两个阶段之后，我们清晰的认识到：需要有一个统一的设计，把这些需要用到的能力都集中起来。

经过几年的迭代，平台完成了多个模块的整合，形成了一个统一的管理平台。大致分为权限管理、资源管理、质量管理、统计监控、厂商管理、运营分析几个模块。

-02-

多云管理的挑战

接下来我跟大家分享下这个平台建设中遇到的一些挑战。

使用多个CDN厂商的情况在行业内是一种普遍的现象。我们一开始对于对接多厂商的认识是打通API，向上统一封装。但是在真正实践时，我们发现事情的复杂度比预期要高很多。

首先，行业里面基本没有公认的规范。作为一个融合平台，需要理解不同厂商的不同规范，逐个对接，避免业务踩坑。要在不同的厂商汇总的数据中，及时准确的发现地区性的质量波动并定位原因等。

其次，当资源选择变多了之后，如何保证我们的选择是最优的变成了一个被大家关注的问题。

最后还有一个重要的问题：就是我去解决这些问题的时候，应该投入多少，怎么来评估产出，团队的价值如何量化。

我们从配置和数据两个基础的问题开始讨论，再展开到上层的方案，介绍我们质量和成本的运营，最后讨论平台团队价值的问题。

2.1|配置

行业内配置的差异非常大。厂商之间没有规范，对接成本高。厂商的开放接口并不能覆盖全部的能力，接口操作风险高，一次变更全网下发。有些功能还必须去和厂商的后台沟通才能加入。

解决这个问题分为三个方面：

1. 制定配置规范

所有厂商所有的功能集合尽可能开放到一个规范里面，一次性实现完整的规范。即便人力开销会增大，但会变成一个相对来说较为固定的投入，不会像以前那样一直在反复的调整。

2. 规范变更流程

首先要求所有的配置变更必须有一个统一的入口。任何操作必须在内部的平台实现，不能在厂商操作。入口收敛之后，所有的配置只有有权限的人才能够发起变更，需要有熟悉业务的人来审批，审批之后由SRE来触发实际下发的流程。配置在下发完成之后，在接口层面会检查对应的配置是不是符合预期结果，进行一次重新的配置读取，厂商也会给到相应的反馈。配置下发完成之后，也会做一些调度层面的准备，例如新建域名或者删除域名。

最后在交付之前，会进行一次完整的回归测试。这些测试需要是配置项级别的，比如修改源站，我们要确认回源相关的响应里面有没有新源站的信息，如果是修改访问控制规则，我们要确认对应条件的访问是不是真的被拦截了或是被放行了。这些回归做完之后，意味着我们这次变更从用户侧的访问效果应该是真的达成预期了，最后才会通知业务方这个变更完成

3. 完善测试框架

最后还有一个接口的测试框架，与前面提到的回归测试区别在于：上述的测试是面向配置结果，而这个测试框架是面向整个配置接口。因为接口转换的实现很重要，并且很容易出问题，导致这些问题的原因可能是我们代码的bug，或者厂商API层面的一些变更导致不兼容的问题、环境的变化产生的影响等，这些问题如果没有一个很好的测试框架，就只能等它出现问题的时候才能发现。在过去的一两年，经过测试框架的积累，火山引擎边缘云完成了大约2000多个case的建设，每次API上线都会跑一个完整的测试，每天有定时的巡查保证厂商测试的功能是符合预期的。这样大量的测试积累，也帮助我们发现了很多问题。

2.2|数据

下面我们再说一个比较基础的能力：数据。

我们知道数据产生的源头分别来自于服务端和客户端。服务端从access log开始由厂商转换成两种数据出口，离线日志和实时统计的接口，前者延迟一般是小时计甚至天级别的，后者可能可以做到分钟级。我们平时看到的带宽请求数状态码都是从服务端的数据源产生的。客户端则是我们自己的业务上报客户端的访问质量数据，同时加上自身的拨测任务巡检，采集一些更详细的链路质量信息。

为了做统一的聚合分析，这些数据被统一存储到数据中台的统一数仓里。整体来看很容易可以理解要做什么，但是跟传统的大数据系统相比，多云平台的工程实现有出现一些额外的问题。

首先就是数据的延迟，接口级别的延迟虽然是分钟级的，但是不同厂商的差异也比较大，有的1分钟、有的5分钟、有的10分钟。但是我们自己的调度系统在做切换的时候希望拿到的数据是越实时越好；

其次是接口的局限，虽然接口的延迟相对日志会低一些，但是它能提供的信息量是有限的；

再次是采集能力，采集时会出现接口不可用，被限频等问题，这就要求我们的采集系统能够识别哪些错误需要重试，针对厂商主动地控制自己的采集频率；

最后是采集的数据质量如何保障，厂商对于接口的实时性是没有办法100%保证的，接口报错很频繁。采集数据还没出来时，有问题的数据如何修正，修正之前如何判断这个数据是不是可信的。

整个建设分为三个阶段：

第一阶段是多源数据采集。解决包括客户端的、服务端的、实时的、离线的不同数据源的适配；

第二阶段是数据可靠性建设。厂商的数据、日志、API、账单等数据会有对比过程，如果发现某个数据出现问题，会发起主动的修复。同时会对整个数据大盘进行实时性监控。上层系统会根据数据做置信度判断。结合服务端的QPS和业务侧上报的数据，判断当前数据是否真实可信。如果不可信，需要使用其他的数据拟合进行针对性的修复。

第三阶段是统一数仓。数据采集之后，会使用统一的规范储存到数据仓库里，向上会提供统一的API查询和信息查询能力。在实际操作过程中，可能会遇到API层面无法实时采集地区运营商级别数据的情况。业务方在查询的时候，需要把这部分查询实时转化成接口的请求转发给厂商，以达到相同的效果。

右侧是整体的模式图。底层是统一的数据中台，负责数据的采集、计算、存储、对外提供查询的接口，上层包括监控、运营、策略等不同模块，面向不同的用户提供不同的功能。

2.3|质量管理

介绍完配置和数据这两个基础的能力，下面向上讲一些业务方更关心的横向的能力，首先是质量保障。

作为一个融合平台，业务方如果有感觉到质量出现问题，一般是出现了故障。平台要做的事情就是把质量的标准提高，尽可能避免对业务产生影响。很多问题对上层没有影响，但是在内部已经走了一个完整的故障处理流程，包括问题的检测发现、通知告警、诊断定位、预案恢复。对于一些比较明显的问题，不管有没有对业务造成影响，我们也会做内部的复盘和改进。

在这个流程中，我们要面对各种各样的问题，比如如何保证检测到的告警的有效性、缩短定位的时长、提升我们无人工干预自动恢复的比例，以及后面的复盘定级需要怎么做。这里我简单介绍下这个过程：

最基础的能力是监控的数据源，相较于刚才的多源数据采集，还定制了厂商侧的告警上报、实时错误日志推送等能力，也会结合业务侧的SDK打点、拨测数据、以及自有节点的一些质量数据。这些统一到数仓里，构建了一个比较实时的质量库。

往右就是数据的检测告警，数据会根据不同的维度聚合，比如域名的、业务的、AB测试的都可能有不同的告警规则。这些规则可以是例如状态码异常比例、播放错误率比例这类静态的规则，也可以是根据时序数据的特征和历史趋势动态判断告警阈值应该是多少。我们对于周期性的和非周期的时序数据都可以支持动态阈值的告警。

当告警触发后，会进入根因分析流程，判断这个告警产生的真实原因是什么。比如当业务方客户端错误率上升时，需要判断对应的是哪个域名，这个域名是放在哪个厂商上，对应的各个维度的监控是否正常。这些判断会涉及到时序数据异常检测、不同数据的相关性分析等等。基本上我们常见的异常都会有完整的根因分析逻辑，直到排查出最终的问题，比如到底是厂商侧的问题还是我们源站的问题还是地区性的网络问题。

这样最终在告警发送时，已经带着完整的诊断结果通知我们的SRE。比如，当前的现象是客户端错误率上升，原因是源站问题，对应中间的检查结果是怎样的。这时候我们可以直接通知业务方处理自己的源站问题了。

如果是厂商的问题，例如地区性的节点不可用，除了会通知厂商之外，我们还会自动去执行一些预案。最常见的就是切流，把对应地区的调度权重从问题厂商上调走，同时保持对厂商对应地区的主动探测，当厂商的流量正常时再切回来。最后这个质量问题的影响时长、故障定级等等会在质量系统中有明确的体现，厂商侧也可以根据我们反馈的信息进行检查和改进。

这样最终整套的系统就实现了闭环，质量数据的检测会触发告警和根因，自动的根因分析和预案执行能够自动的改善质量数据。

过去几年我们一直在改善闭环里的执行效率和准确性，让更多的问题能够被自动预案来覆盖。目前的告警准确性，就是那些波动异常经过智能阈值判断，以及降噪处理后，被确认真的是异常的占了98%以上，80%以上的告警会带着准确的根因分析信息一同提供给SRE和技术支持的同事。

2.4|成本运营

成本运营在过去几年一直是一个令人非常头疼的问题。由于数据的敏感性，我们最初做了很多的限制，导致相关的技术只能局限在一个很小的范围内讨论。但是这个团队要解决的工程问题还是非常复杂的，需要充分的投入。比如每个月一到月初就要花大量的时间去校验厂商的账单数据是不是准确，还有像成本分摊、波动归因等方面都存在很大的挑战。解决办法一种是让业务方熟悉我们的成本逻辑，自己去分析，另一种方式是从平台层面提供统一的能力来帮助业务。

首先需要明确的是数据因为和钱相关，确实是很敏感的，因为涉及到商务的保密问题等，但是钱可以拆分成两部分：一部分是单价，一部分是用量。单价只有有权限的人才能可见，所以我们额外做了一套系统，把价格隔离起来管理。用量信息则没有那么敏感，大部分业务方都会接触用量信息。将单价隔离开以后，平台的负责人就可以深度的参与到用量的优化之中。这些用量，比如边缘带宽、存储、专线会分别对应到不同的分摊算法中去，让每一种资源的用量都有一个固定的逻辑分摊到最小的成本单元上，一般就是域名。域名在总的用量上面占多大比例是可以明确的，成本单元有自己的组织归属，包括叶子结点和跟结点的归属都可以映射过去。

对于业务方来说，可以直观的看到每月的带宽上涨到底是哪些业务甚至是域名导致的问题，这个就是我们近期面向业务方开放的成本分析能力。

在排查问题的时候，每一层的数据都是可校验的。所有域名的总用量加和，一定等于我们分摊前的总用量加和。每个资源的总用量，乘以对应的单价，一定等于对应的资源花掉的钱。做数据校验的时候，只需要一层层的校验就好了。

2.5|平台价值

刚才说了我们作为一个多云管理的平台，资源是来自于底层的厂商，流量来自于上层的业务，平台做的事情只是把这个资源更好的交付给业务，协助我们的业务使用好这些资源。

在这个过程中我们投入了接口开发、QA、数据工程、运营分析、调度系统、质量监控、权限管理还有前台、文档等等，但是向上还是要落实到业务层面可以感知到的收益上，就是我的质量是不是有保障，还有我的成本是不是在持续的优化。

所以一直以来衡量我们的团队产出的指标一直都是一些相对固定的维度，质量、成本、效率、稳定性。

最近一年来整套的系统设计才逐渐完整，把线上问题收敛稳定下来。到现在为止依然要投入很多的人力去维护我们配置接口的迭代、数据的保障、以及平台化的功能建设。另一方面，正是因为有了业务体量的支撑，我们团队的投入价值才能最大化。

过去一段时间里，我们也跟火山引擎的客户和开发者做了一些技术上的交流，去介绍我们是怎么管理多云的。一个经常提出来的问题是，我有什么简单的办法实现你这套系统，我可以不要那么复杂的前台界面、审批流程。但是那些关键的能力，比如质量管理、成本分析，我们怎么样才能用最小的投入做起来。

所以在去年我们对系统又重新做了一次改造，把底层的关键能力，数据系统配置系统调度系统还有中间的一些核心解决方案，逐步的开放成我们的产品能力，放到火山引擎上面提供出来。这个就是我们的多云CDN产品。

-03-

火山引擎多云产品能力

多云CDN底层还是对接不同资源厂商，包含不同服务类型。但中间层正在经历一个深度的改造，从右到左不断地将我们的核心能力孵化为开放的产品；从左到右，以上云的形式不断地将我们已有系统的实现以更加规范的设计和概念定义去做重构，让一些原本比较模糊的内部概念能够以一个内外部用户能理解的方式去运行。

在这套系统之上，现有的融合平台会变得越来越薄，未来可能只会保留一些跟内部业务深度耦合的部分，比如流程的审批、内部业务的预案等。业务方还是使用我们融合平台的界面，但是这个平台的底层未来会和火山引擎的客户一样是我们这个多云产品的用户，通过它提供的开放接口能力去管理各自的资源。

3.1|资源管理

多云CDN产品去年刚刚上线，就已经完成了基本的资源管理能力。平台现在支持已经完成接口规范化改造的国内外厂商。在接口能力上配置的统一查询功能已经完成，也支持了像域名创建、证书更新这样的能力，更完整的配置变更流程正在做产品化的改造。在资源管理的基础上，业务组织、权限、统计聚合的能力也完成了，一些拓展的功能，比如在TOS文件变更的时候同时刷新多个厂商的CDN，我们称之为联动刷新的能力，有了多云的平台就比较容易实现，目前正在被实际使用。