在世界杯等大规模流量突发的情况下，作为承载抖音集团业务核心流量的基础设施，在运维效率、质量方面都可观测、调度、容灾、成本可观测与优化方面都遇到了很多的挑战。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，向上统一封装。但是在真正实践时，我们发现事情的复杂度比预期要高很多。

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

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

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

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

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

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

1. 制定配置规范

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

2. 规范变更流程

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

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

3. 完善测试框架

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

2.2|数据

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

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

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

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

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

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

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

整个建设分为三个阶段：

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

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

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

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