近日，火山引擎边缘云交融 CDN 团队负责人孙益星在 LiveVideoStack Con 2023 上海站围绕交融 CDN 团队继续建设多云 CDN 平台的演进过程，联合建设过程中面临的难点和挑战，介绍了交融 CDN 团队接下来的次要投入方向，分享了火山引擎在多云利用架构下的 CDN 运维治理解决方案。
孙益星与他所在的交融 CDN 团队在大规模流量突发的挑战下，通过几年的一直迭代与打磨，使字节多云 CDN 平台实现了多个模块的整合，造成了一个对立的治理平台。
01 字节多云 CDN 平台的演进
面向外部业务的多云 CDN 平台是什么？有什么用？要解决的到底是什么问题呢？
字节跳动有很多流量型的业务，包含抖音、头条、西瓜视频等。为了承载这样的流量，团队应用了各种各样流量减速的产品，包含动态减速、动静减速、域名解析、证书治理以及与各种配套的解决方案，比方源站缓存、回源调度、边缘函数等。
从业务角度登程，如果有一个平台可能间接治理所有减速域名的配置，这将会带来很大便当。只须要把源站贮存的信息发送给平台，剩下的配置解析、流量调配、品质治理等都是由平台实现。
于是字节多云 CDN 平台——即交融 CDN 平台，应运而生，它向上承接所有业务方的 CDN 减速场景需要，底层对接不同的私有云服务，蕴含动态减速、动静减速等。这些服务自身由不同的厂商来提供，业务方在下层不须要关怀它所对接的是哪些厂商，也不关怀具体性能需要在不同的厂商上应该别离怎么去实现，它要做的事件就是把需要提给平台，而后由平台协调不同厂商的资源，最终再交付给业务。对于业务方来说，这就是一个一般的 CDN 服务平台，像是一家厂商提供的打包的服务一样，所以业内有个比拟艰深的称呼是交融 CDN 平台。
业务对于这个平台的诉求有以下几点：
- 第一个诉求是品质：业务对平台的减速服务能力是有预期的，平台有责任保障下层的每一个域名的可用性和减速成果；
- 第二个诉求是老本：老本越便宜越好；
- 第三个诉求是性能：不同业务有比拟大的差别的，比方拜访鉴权、回源 rewrite，缓存工夫等。每个业务都会有本人的设计和需要，作为交融平台须要了解这些设计的差别，而后将它转换成厂商可满足的服务需要，最初实现、验证、最初交付给业务方；
- 第四个诉求是服务：这个是比拟宽泛的概念，就是当咱们实现了一系列的资源的配置工作后，业务在日常应用中须要看监控，看报表，刷新预热、排查问题，提一些 on call，这些都须要对应的服务能力来反对。
总结下来，下层业务对于平台有四个方面的需要：品质、老本、性能以及服务，这个是下层业务对于平台的需要。
从平台的角度思考，厂商越少，复杂度的可能性就会越低。但因为这是一个交融平台，所以须要从所有字节的业务体系的角度思考问题。
- 首先就是资源的保障，资源方面要能承载日常一两百 T 的业务带宽，这曾经超出了绝大部分厂商的资源储备。
- 另一方面是在例如春晚、618、世界杯或者上演赛事这种大型的流动筹备时，咱们很难在单个厂商上找到短缺的冗余，这个冗余可能是超出惯例业务量的一倍或者更多的需要，总资源池子须要多个供应商一起协调资源。
- 其次是品质，用户散布在全国各地甚至全世界，而用户体验跟节点的拜访品质密切相关，不同厂商在不同地区、不同运营商的节点散布是有比拟大的差别的。这会导致在理论的业务体现中，这个地区厂商品质的排序是 ABC，另一个地区就变成了 CAB，这种状况在海内会更显著。对于那些时刻要求最优服务资源的业务来说，很难通过单个厂商来满足要求。
- 品质的另一个体现模式是可用性，地区性的节点不可用是常常产生的，这会造成业务的品质稳定。另外，大规模的厂商故障也时常会产生，如果只绑定一家厂商，那么它故障时流量切换也会带来显著的品质影响。所以对咱们来说，保障流量较为扩散的调配在多个供应商是一个必要的措施。
- 价格方面也有多厂商的思考，价格并不是越便宜越好。不同的业务对于品质的要求是不同的，有些对于用户体验不敏感的业务会更关注老本，对品质的要求就没有那么高；另一部分业务为了更好的品质，就对价格容忍度更高一些。平台须要价格和品质层面为不同的业务找到不同的厂商，选出一个最合适的计划。
- 最初是性能和服务的反对，有多个厂商就能够在咱们有新的性能需要的时候，缩短从联调到测试到上线的周期，在排查具体问题的时候也能给咱们更多的信息反馈。
作为一个交融平台，平台的指标并不是要对接尽可能多的厂商，或者对接尽可能少的厂商。而是如果须要让整个业务达到这样一个现实的状态，多厂商根本是一个惟一的计划。在这个计划里，资源是动态变化的，不存在一种资源在各种场景下都是最好的。而是不同场景下总有一个最合适的，而平台在这里的职责就是向业务方高效的交付那些最合适的资源，并保障这些资源的可靠性，这是这个平台的外围能力。
平台的建设通过了两个阶段：
- 第一阶段是最原始的形式：交融 CDN 团队会有固定的几个 SRE，每个人固定的对接几个业务。大一些的业务可能会有多个专职，小一些的可能会由一个 SRE 对接多个业务。每个人都比拟相熟本人所对接的业务的需要和背景，依照本人的教训去厂商控制台下来配置，具体的要求也间接跟厂商的技术人员去沟通。在这个初始阶段中，次要靠人的能力来撑持；
- 第二阶段开始有些通用的性能需要被提出放在平台里：比如说看域名的配置，数据，调流量。于是平台的性能被分成不同的性能方向别离被建设。并且不同类型的资源有不同的团队别离去实现。在这个阶段中因为业务一直有需要进来，整个平台的设计是在被需要拖着走的。这两头暴露出了一些问题，比方权限设计、接口标准不对立、数据一致性有问题等。
通过这两个阶段之后，交融 CDN 团队清晰的意识到：须要有一个对立的设计，把这些须要用到的能力都集中起来。
通过几年的迭代，平台实现了多个模块的整合，造成了一个对立的治理平台。大抵分为权限治理、资源管理、品质治理、统计监控、厂商治理、经营剖析几个模块。
02 多云治理的挑战
平台建设中遇到了哪些挑战呢？应用多个 CDN 厂商的状况在行业内是一种广泛的景象。交融 CDN 团队一开始对于对接多厂商的意识是买通 API，向上对立封装。然而在真正实际时，交融 CDN 团队发现事件的复杂度比预期要高很多。
- 首先，行业外面根本没有公认的标准。作为一个交融平台，须要了解不同厂商的不同标准，一一对接，防止业务踩坑。要在不同的厂商汇总的数据中，及时精确的发现地区性的品质稳定并定位起因等。
- 其次，当资源抉择变多了之后，如何保障交融 CDN 团队的抉择是最优的变成了一个被大家关注的问题。最初还有一个重要的问题：就是我去解决这些问题的时候，应该投入多少，怎么来评估产出，团队的价值如何量化。
咱们从配置和数据两个根底的问题开始探讨，再开展到下层的计划，介绍咱们品质和老本的经营，最初探讨平台团队价值的问题。
1. 配置
行业内配置的差别十分大。厂商之间没有标准，对接老本高。厂商的凋谢接口并不能笼罩全副的能力，接口操作危险高，一次变更全网下发。有些性能还必须去和厂商的后盾沟通能力退出。
解决这个问题分为三个方面：
制订配置标准所有厂商所有的性能汇合尽可能凋谢到一个标准外面，一次性实现残缺的标准。即使人力开销会增大，但会变成一个相对来说较为固定的投入，不会像以前那样始终在重复的调整。
标准变更流程首先要求所有的配置变更必须有一个对立的入口。任何操作必须在外部的平台实现，不能在厂商操作。入口收敛之后，所有的配置只有有权限的人才可能发动变更，须要有熟悉业务的人来审批，审批之后由 SRE 来触发理论下发的流程。配置在下发实现之后，在接口层面会查看对应的配置是不是合乎预期后果，进行一次从新的配置读取，厂商也会给到相应的反馈。配置下发实现之后，也会做一些调度层面的筹备，例如新建域名或者删除域名。
最初在交付之前，会进行一次残缺的回归测试。这些测试须要是配置项级别的，比方批改源站，交融 CDN 团队要确认回源相干的响应外面有没有新源站的信息，如果是批改访问控制规定，须要确认对应条件的拜访是不是真的被拦挡了或是被放行了。这些回归做完之后，意味着这次变更从用户侧的拜访成果应该是真的达成预期了，最初才会告诉业务方这个变更实现。
欠缺测试框架最初还有一个接口的测试框架，与后面提到的回归测试区别在于：上述的测试是面向配置后果，而这个测试框架是面向整个配置接口。因为接口转换的实现很重要，并且很容易出问题，导致这些问题的起因可能是代码的 bug，或者厂商 API 层面的一些变更导致不兼容的问题、环境的变动产生的影响等，这些问题如果没有一个很好的测试框架，就只能等它呈现问题的时候能力发现。
在过来的一两年，通过测试框架的积攒，火山引擎边缘云实现了大概 2000 多个 case 的建设，每次 API 上线都会跑一个残缺的测试，每天有定时的巡逻保障厂商测试的性能是合乎预期的。这样大量的测试积攒，也帮忙咱们发现了很多问题。
2. 数据
上面再说一个比拟根底的能力：数据。
数据产生的源头别离来自于服务端和客户端。服务端从 access log 开始由厂商转换成两种数据进口，离线日志和实时统计的接口，前者提早个别是小时计甚至天级别的，后者可能能够做到分钟级。平时看到的带宽申请数状态码都是从服务端的数据源产生的。客户端则是咱们本人的业务上报客户端的拜访品质数据，同时加上本身的拨测工作巡检，采集一些更具体的链路品质信息。
为了做对立的聚合剖析，这些数据被对立存储到数据中台的对立数仓里。整体来看很容易能够了解要做什么，然而跟传统的大数据系统相比，多云平台的工程实现有呈现一些额定的问题。
- 首先就是数据的提早，接口级别的提早尽管是分钟级的，然而不同厂商的差别也比拟大，有的 1 分钟、有的 5 分钟、有的 10 分钟。然而咱们本人的调度零碎在做切换的时候心愿拿到的数据是越实时越好；
- 其次是接口的局限，尽管接口的提早绝对日志会低一些，然而它能提供的信息量是无限的；
- 再次是采集能力，采集时会呈现接口不可用，被限频等问题，这就要求咱们的采集零碎可能辨认哪些谬误须要重试，针对厂商被动地管制本人的采集频率；
- 最初是采集的数据品质如何保障，厂商对于接口的实时性是没有方法 100% 保障的，接口报错很频繁。采集数据还没进去时，有问题的数据如何修改，修改之前如何判断这个数据是不是可信的。
整个建设分为三个阶段：
- 第一阶段是多源数据采集，解决包含客户端的、服务端的、实时的、离线的不同数据源的适配；
- 第二阶段是数据可靠性建设。厂商的数据、日志、API、账单等数据会有比照过程，如果发现某个数据呈现问题，会发动被动的修复。同时会对整个数据大盘进行实时性监控。下层零碎会依据数据做置信度判断。联合服务端的 QPS 和业务侧上报的数据，判断以后数据是否真实可信。如果不可信，须要应用其余的数据拟合进行针对性的修复；
- 第三阶段是对立数仓。数据采集之后，会应用对立的标准贮存到数据仓库里，向上会提供对立的 API 查问和信息查问能力。在实际操作过程中，可能会遇到 API 层面无奈实时采集地区运营商级别数据的状况。业务方在查问的时候，须要把这部分查问实时转化成接口的申请转发给厂商，以达到雷同的成果。
上图为整体的模式图。底层是对立的数据中台，负责数据的采集、计算、存储、对外提供查问的接口，下层包含监控、经营、策略等不同模块，面向不同的用户提供不同的性能。
3. 品质治理
介绍完配置和数据这两个根底的能力，上面向上讲一些业务方更关怀的横向的能力，首先是品质保障。作为一个交融平台，业务方如果有感觉到品质呈现问题，个别是呈现了故障。平台要做的事件就是把品质的规范进步，尽可能防止对业务产生影响。很多问题对下层没有影响，然而在外部曾经走了一个残缺的故障解决流程，包含问题的检测发现、告诉告警、诊断定位、预案复原。
对于一些比拟显著的问题，不论有没有对业务造成影响，交融 CDN 团队都会做外部的复盘和改良。在这个流程中，交融 CDN 团队要面对各种各样的问题，比方如何保障检测到的告警的有效性、缩短定位的时长、晋升咱们无人工干预主动复原的比例，以及前面的复盘定级须要怎么做。
这个过程是：最根底的能力是监控的数据源，相较于方才的多源数据采集，还定制了厂商侧的告警上报、实时谬误日志推送等能力，也会联合业务侧的 SDK 打点、拨测数据、以及自有节点的一些品质数据。这些对立到数仓里，构建了一个比拟实时的品质库。往右就是数据的检测告警，数据会依据不同的维度聚合，比方域名的、业务的、AB 测试的都可能有不同的告警规定。这些规定能够是例如状态码异样比例、播放错误率比例这类动态的规定，也能够是依据时序数据的特色和历史趋势动静判断告警阈值应该是多少。咱们对于周期性的和非周期的时序数据都能够反对动静阈值的告警。当告警触发后，会进入根因剖析流程，判断这个告警产生的实在起因是什么。
比方当业务方客户端错误率上升时，须要判断对应的是哪个域名，这个域名是放在哪个厂商上，对应的各个维度的监控是否失常。这些判断会波及到时序数据异样检测、不同数据的相关性剖析等等。基本上咱们常见的异样都会有残缺的根因剖析逻辑，直到排查出最终的问题，比方到底是厂商侧的问题还是咱们源站的问题还是地区性的网络问题。这样最终在告警发送时，曾经带着残缺的诊断后果告诉咱们的 SRE。比方会通知你，以后的景象是客户端错误率回升，起因是源站问题，对应两头的查看后果是怎么的。这时候咱们能够间接告诉业务方解决本人的源站问题了。如果是厂商的问题，例如地区性的节点不可用，除了会告诉厂商之外，咱们还会主动去执行一些预案。
最常见的就是切流，把对应地区的调度权重从问题厂商上调走，同时放弃对厂商对应地区的被动探测，当厂商的流量失常时再切回来。最初这个品质问题的影响时长、故障定级等等会在品质零碎中有明确的体现，厂商侧也能够依据咱们反馈的信息进行检查和改良。
这样最终整套的零碎就实现了闭环，品质数据的检测会触发告警和根因，主动的根因剖析和预案执行可能主动的改善品质数据。过来几年交融 CDN 团队始终在改善闭环里的执行效率和准确性，让更多的问题可能被主动预案来笼罩。目前的告警准确性，就是那些稳定异样通过智能阈值判断，以及降噪解决后，被确认真的是异样的占了 98% 以上，80% 以上的告警会带着精确的根因剖析信息一起提供给 SRE 和技术支持的共事。
4. 老本经营
老本经营在过来几年始终是一个令人十分头疼的问题。因为因为数据的敏感性，交融 CDN 团队最后做了很多的限度，导致相干的技术只能局限在一个很小的范畴内探讨。然而这个团队要解决的工程问题还是非常复杂的，须要充沛的投入。比方每个月一到月初就要花大量的工夫去校验厂商的账单数据是不是精确，还有像老本摊派、稳定归因等方面都存在很大的挑战。
解决办法一种是让业务方相熟咱们的老本逻辑，本人去剖析，另一种形式是从平台层面提供对立的能力来帮忙业务。
首先须要明确的是数据因为和钱相干，的确是很敏感的，因为波及到商务的窃密问题等，然而钱能够拆分成两局部：一部分是单价，一部分是用量。
单价只有有权限的人才能可见，所以交融 CDN 团队额定做了一套零碎，把价格隔离起来治理。用量信息则没有那么敏感，大部分业务方都会接触用量信息。将单价隔离开当前，平台的负责人就能够深度的参加到用量的优化之中。这些用量，比方边缘带宽、存储、专线会别离对应到不同的摊派算法中去，让每一种资源的用量都有一个固定的逻辑摊派到最小的老本单元上，个别就是域名。域名在总的用量下面占多大比例是能够明确的，老本单元有本人的组织归属，包含叶子结点和跟结点的归属都能够映射过来。
对于业务方来说，能够直观的看到每月的带宽上涨到底是哪些业务甚至是域名导致的问题，这个就是咱们近期面向业务方凋谢的老本剖析能力。在排查问题的时候，每一层的数据都是可校验的。所有域名的总用量加和，肯定等于摊派前的总用量加和。每个资源的总用量，乘以对应的单价，肯定等于对应的资源花掉的钱。做数据校验的时候，只须要一层层的校验就好了。
5. 平台价值
方才说了咱们作为一个多云治理的平台，资源是来自于底层的厂商，流量来自于下层的业务，平台做的事件只是把这个资源更好的交付给业务，帮助咱们的业务应用好这些资源。
在这个过程中咱们投入了接口开发、QA、数据工程、经营剖析、调度零碎、品质监控、权限治理还有前台、文档等等，然而向上还是要落实到业务层面能够感知到的收益上，就是我的品质是不是有保障，还有我的老本是不是在继续的优化。所以始终以来掂量交融 CDN 团队产出的指标始终都是一些绝对固定的维度，品质、老本、效率、稳定性。
最近一年来整套的零碎设计才逐步残缺，把线上问题收敛稳定下来。到当初为止仍然要投入很多的人力去保护咱们配置接口的迭代、数据的保障、以及平台化的性能建设。另一方面，正是因为有了业务体量的撑持，咱们团队的投入价值能力最大化。过来一段时间里，交融 CDN 团队也跟火山引擎的客户和开发者做了一些技术上的交换，去介绍交融 CDN 团队是怎么治理多云的。
一个常常提出来的问题是，我有什么简略的方法实现你这套零碎，我能够不要那么简单的前台界面、审批流程。然而那些要害的能力，比方品质治理、老本剖析，咱们怎么样能力用最小的投入做起来。所以在去年交融 CDN 团队对系统又从新做了一次革新，把底层的要害能力，数据系统配置系统调度零碎还有两头的一些外围解决方案，逐渐的凋谢成咱们的产品能力，放到火山引擎下面提供进去。这个就是咱们的多云 CDN 产品。
03 火山引擎多云产品能力
多云 CDN 底层还是对接不同资源厂商，蕴含不同服务类型。但中间层正在经验一个深度的革新，从右到左一直地将咱们的外围能力孵化为凋谢的产品；从左到右，以上云的模式一直地将咱们已有零碎的实现以更加标准的设计和概念定义去做重构，让一些本来比拟含糊的外部概念可能以一个内外部用户能了解的形式去运行。
在这套零碎之上，现有的交融平台会变得越来越薄，将来可能只会保留一些跟外部业务深度耦合的局部，比方流程的审批、外部业务的预案等。业务方还是应用咱们交融平台的界面，然而这个平台的底层将来会和火山引擎的客户一样是咱们这个多云产品的用户，通过它提供的凋谢接口能力去治理各自的资源。
1. 资源管理
多云 CDN 产品去年刚刚上线，就曾经实现了根本的资源管理能力。平台当初反对曾经实现接口规范化革新的国内外厂商。在接口能力上配置的对立查问性能曾经实现，也反对了像域名创立、证书更新这样的能力，更残缺的配置变更流程正在做产品化的革新。在资源管理的根底上，业务组织、权限、统计聚合的能力也实现了，一些拓展的性能，比方在 TOS 文件变更的时候同时刷新多个厂商的 CDN，咱们称之为联动刷新的能力，有了多云的平台就比拟容易实现，目前正在被理论应用。
2. 监控剖析
在数据的能力上，统计的 API 和日志的 API 在第一阶段都曾经反对。刚刚实现了数据采集的能力，能够间接帮忙用户从 API 采集数据而后存下来，在这个数据能力之上，用户能够做不同厂商数据的对立聚合，或者灵便的比照不同厂商的数据。将来咱们还会凋谢自定义报表的能力，帮忙咱们的客户剖析全局的业务数据。
3. 智能运维
在监控能力上，有了方才说的数据采集的能力，加上咱们的拨测能力，以及将来会凋谢的客户数据上传的通道，咱们把外部的智能告警、根因剖析、主动容灾的预案也都放到了产品上，将来会联合咱们本人的品质库帮忙咱们的客户更好的剖析业务品质、晋升服务的可靠性。
4.FinOps
近期，老本治理能力曾经上线。总的来说就是将老本经营能力凋谢，联合数据采集能力和账单剖析能力，帮忙客户精确的剖析账单形成、业务老本形成和稳定的起因。将来还会联合不同的计费模型，帮忙业务方更好的剖析老本，组成对应的优化计划。
上述就是整个多云 CDN 产品的演进过程。
火山引擎多云 CDN 产品在去年上线，目前还在疾速地迭代过程中。交融 CDN 团队冀望和厂商、开发者一起，为火山引擎的用户，实现一个标准、对立、平安、高效、智能的多云流量治理平台。
对于火山引擎边缘云：
火山引擎边缘云，以云原生技术为根底底座，交融异构算力和边缘网络，构建在大规模边缘基础设施之上的云计算服务，造成以边缘地位的计算、网络、存储、平安、智能为外围能力的新一代分布式云计算解决方案。
👇 理解更多👇