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

  //  

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

文/孙益星

编辑/LiveVideoStack

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

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

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

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

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

-01-

字节多云CDN平台的演进

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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