去年，火山引擎边缘云流量治理团队的负责人刘学在 LiveVideoStackCon 2023 上海站结合大规模流量场景的挑战，介绍了火山引擎边缘云的云边端一体化流量调度体系，分享了场景落地实例和未来展望。

刘学及他所在的流量治理团队在大规模流量和场景的挑战下，从调度视角对各个接入产品的调度能力和策略进行整合，形成了一个云边端一体化的调度体系。

大规模流量场景的挑战

火山引擎边缘云提供了一系列标准化的接入产品，在端边云的接入路径上，长期服务于抖音集团内各种大规模音视频流量 APP，包括抖音、今日头条、火山小视频、西瓜视频等。这些应用产生的基础流量主要分为点播、直播、投稿和 API，各类型流量的特点分别为：

• 点播流量：包括 CDN 边缘层面的超大规模流量，以及多层缓存系统的回源流量。当边缘流量足够庞大、资源足够丰富时，回源流量在源站层面也是非常重要的流量之一；

• 直播流量：随着大型赛事活动、电商等业务的发展，直播也是流量成分中的重要组成部分。直播的流量架构会包括推拉流及审核流等，在源站和边缘层也都会占用比较可观的网络资源；

• 投稿流量：作为 ugc 形态的 APP，投稿这部分流量是不可忽视的，近一段时间随着点播业务社交属性的增强，投稿流量的压力主要在冷流业务。比如每年投稿系统最大的峰值挑战，其实是在元旦春节的零点，这个时间观众都喜欢集中感慨一下，这给系统提出了比较严峻的挑战；

• API 类流量：这类流量的特点是请求必须在源站，基于复杂的计算或海量用户数据来完成服务，且单个请求的体量较小。场景包括推荐、搜索、账号、直播间刷礼物、消息等等，这些也是音视频 APP 必不可少的流量构成。

对于多种类型的业务流量，这些流量在外网接入的范畴，会经过火山引擎边缘云的哪些产品集进行支持呢？

• 在端内，火山引擎边缘云提供了字节统一的移动端网络库 MNet，经过 MNet 代理的网络请求，在性能、协议、安全性等方面均能得到深度的定制优化支持；

• 在边的层面，边缘云提供了多种形态的缓存和加速服务。其中包括用于支持点播流量的 CDN 产品，贴近用户提供点播推拉流、转码等计算和网络服务的边缘计算、边缘网络产品，以及为 API 类流量提供就近接入、全路径加速的 DCDN 产品；

• 在云的层面，在请求到达最终的业务 server 之前，边缘云接入团队也提供了相应的 4/7 层负载均衡产品。

那么，对于异构的流量，在比较复杂的全局接入架构下，会有哪些具有挑战性的场景呢？流量治理团队在过去几年中帮助业务解决的一个主要问题是：对于抖音集团全部的接入流量，在日常用户规模、流量规模都非常庞大的的背景下，在公司层面进行诸如春晚红包、世界杯直播等大型活动时，外网流量接入的总体解决方案是什么？

流量治理团队面临的流量压力包括：

• 首先，各种流量都有常态的流量作为基础，并且随着活动的拉活、在线人数增加，像 API、点播这类日常流量会有一定的放大；

• 在此基础上，还需要继续承担特定的活动行为所带来的额外流量需求。比如春晚的红包组队任务、世界杯主直播间消息刷屏等；

• 最后，就是一些特殊时刻的关键挑战。比如春晚的口播、元旦零点的投稿，这可能是整场活动的焦点时刻。是在前面所有流量上涨的基础之上，再叠加一个比较夸张的需求数字。

在上述流量场景的背景下，面临的挑战包括：

• 首先是在整个活动的时间轴上，流量治理团队需要考虑上述各种流量增长的高水位叠加。这些增长的流量，在时间和空间层面，有些是可预期的。比如红包的时间点，口播广告的时间点等等；有些是难以预期的，比如世界杯的小组赛阶段阿根廷对沙特、德国对日本的这两场直播，在比分爆冷后整个直播间流量上涨的的情况是远超前期预估的。这就需要团队在难以准确预估的前提下，在方案上去根据资源的供给情况做倒推，根据流量上涨的程度设计分级的降级处理方案；

• 第二层挑战来自于资源层面。首先是周期问题，相对于活动决策、资源建设的周期，带宽扩容、机器的采购等都是需要比较长的周期的。其中有部分资源如果短期购买的话，成本非常高，这种高价资源的必要性需求怎样进行评估；以及即使短期内买到了一些异构的资源，架构上如何把这些资源比较稳妥的使用起来，在规划层面要给出经过计算排布、确保可行性、变量和风险可控制的接入方案，这些都是资源层面所面临的一些挑战；

• 最后是容灾场景，在前面提及的海量需求和复杂架构的背景下，需要进一步考虑容灾场景。在活动期间如果发生了各种场景的故障，团队需要具备提前设计好、计算好、演练过的预案。基于常规的接入架构设计方案，进一步的去做 n 种场景的容灾预案，这会将整体的工作量放大 n 倍。并且会进一步的拷问：系统极限在哪里、在最恶劣的情况下，团队要舍弃什么，保留什么，如何确保计划的动作能精准的实施下去。这些是流量治理团队在容灾极限场景下所面临的挑战。容灾的能力十分重要。在各种大规模流量的输入情况下，资源十分受限，可能会导致出现一些故障，这时就需要按照提前计算规划以及演练过的成熟预案进行场景展开。场景上的展开，无论是在技术层面还是工作量层面都翻了很多倍，如何保证容灾的可行可控也具有挑战性。

云边端一体化调度体系

基于前文提及的流量和场景的挑战下，从调度视角对各个接入产品的调度能力和策略进行整合，形成了一个云边端一体化的调度体系。图示架构图是对前文提到的接入架构图进行了一个简单的细化，里面包含了各组件的流量调度能力的部分：

• 首先在端内的层面，抖音集团的流量调度体系中，一个比较突出的特色点就是：调度系统的边界，从传统的基于域名解析方式，上升到了端内。基于端内网络库的能力及云控方案，可以构造出生效速度更快、能力更加强大多样、调度粒度更加精准的新一代解决方案；

• 其次，在边缘层面，抖音集团大规模的使用了融合架构。其中包括静态 CDN 在多厂商间的融合、直播 CDN 在自建的边缘计算资源和三方厂商之间的融合，以及动态 CDN 的融合。这里面提到的融合，即包括同构资源的横向融合，也包括一些异构资源在纵向的跨层融合，比如当核心机房的资源不足时，可以将一部分业务上移至距离核心机房较近的边缘资源上；

• 在源站层面，对于源站各机房、线路的入口带宽，各种接入组件提供了不同的回源调度能力，比如 CDN 系统基于 302、回源配置的源站调度，以及 API 类流量基于域名解析的源站调度。在源站的入口和下游业务之间，LB 产品也提供了最后一层的内网调度能力，将源站业务的调度需求，与复杂的外网接入接入链路进行最大程度的解耦和屏蔽。

由此，调度体系的一个关键特点被凸显，即各系统间的分层和协作。

• 为了构建一个高内聚、低耦合的调度协作体系，计算机领域的一个通用思想需要被引用，即能力和策略分层。在特定问题上，需要十分明确的定义：哪些系统是提供配置能力的、哪些系统或角色是负责对配置进行取值决策的。比如对于融合 CDN 调度系统，在边缘层面首先要负责指定域名在指定线路到指定厂商的决策，这是一个策略系统，其依赖的能力可以是 dns、httpdns 或者 302 配置；另一方面，对于回源流量，CDN 提供多种回源配置的能力，但源站带宽的规划就是另一个独立的策略系统。

• 好的设计能够使每个模块的目标是单一、内聚的，避免在决策时引入太多不合理的顾虑。比如字节在过去的一段时间，各 API 类流量的机房间流量调度，是依赖外网调度的，这会导致后端业务模块间的调度配置在域名维度被绑死，不够灵活；同时外网在局部线路带宽不足需要调整时，还要参考各后端业务的部署容量情况，为了解决这类问题，流量治理团队在 7 层转发层强化了源站的内网调度能力，通过对内外网调度的解耦，使得各层级所要处理的问题更加合理。

• 这种跨多层问题的处理也可以从另一个角度去理解：当问题规模足够大时，是采用 sacle up 的方式尝试在一个单元中去解决所有问题呢；还是用 scale out 的方式，将问题进行合理的拆解，将不同的子问题分发到不同的单元中进行处理，最后再进行整合呢？在这里显然，火山引擎边缘云走的是 scale out 的路线。

最后，在每个调度子系统各司其职的前提下，仍然需要一个对全局情况进行汇总的综合调度系统，即全局流量调度系统 BTM。一些综合性的问题，需要在全局层面进行统一决策协调，因此仍然需要一个顶层的仲裁者角色。比如前面提到过的活动期间的容灾场景，假设一个源站机房故障，各流量负责的系统都在向其他机房切流，那么谁来计算和保障其他机房的容量是安全的呢？谁来协调各流量间的降级优先级和降级深度呢？这都需要一个综合决策性质的系统，参考各业务流量的特点、流量实时大小，以及资源的水位和状态，从全局角度进行决策，在调度系统通用的这几个目标下，即容量、容灾、成本、质量、以及考虑特定的业务约束，寻求相对的最优解或者可行解。

场景落地 Story

接下来通过一些具体的场景和案例，介绍火山引擎边缘云调度体系能够提供的解决方案，以及对应的特点。

Story1

首先将镜头拉回到春晚的场景，介绍一个最极端的时刻——口播时刻。这个场景在业务层面的情况是，主持人会在特定的广告时刻，引导全国的观众打开抖音系的 app，进入红包活动。在技术层面，预期会发生的流量包括，以活动期间高于常规晚高峰的大盘流量为基础，短时间内叠加海量的冷启流量和活动流量。冷启流量包括启动后的一系列 api 请求，以及首刷点播，活动流量主要指红包玩法。众所周知，红包玩法可以做一系列的缓存、打散、削峰的定制化设计，反而是冷启流量更加难以控制，因为口播行为是固定的，口播带来的冷启请求也是无法做打散的。

为了应对这些挑战，传统的解决方案包括：对于首刷点播流量，可以通过限制码率、推荐高热视频等手段尽量减少 CDN 流量的消耗；对于 API 类流量，可以通过版本更新，将活动版本的冷启流量限制到最低。但这受限于活动版本的开发时间和发布周期，往往到活动时刻的版本覆盖率并不理想。在此基础上，常见的一些处理方案可能包括在 dns 层做黑洞，但整域名的封禁往往会伴随很多误杀，且 dns 层面的封禁和解封时效性也并不可控；或者将接入层作限流作为主要手段，但这需要对接入层堆很多的资源，毕竟流量洪峰到来时，握手和协议的开销不可避免。

那么，是否存在着更加有效的解决方案呢？

在抖音集团内部，端上的请求主要是通过定制化的网络库进行代理发送的。请求处理的过程中，会由网络库进行内部域名的定制、协议优化、甚至请求 drop 等操作，这一系列操作都是云端实时可控的。经过网络库的请求，在调度层面可以获得更快、能力更强、维度更加精准的优势：

• 首先对于调度的生效速度。端内的请求根据是否链接复用，会分为两种不同的执行情况。使用 dns 或 httpdns 解析，在变更解析结果进行调度时，除去解析结果缓存更新速度的影响，链接复用也是影响切流速的重要因素。在链接复用维持的较好的业务上，可能数十分钟都难以完成切流操作。而端内调度使用的是域名替换的机制，在请求发起前决策具体要使用的域名，这样就避免了链接复用的影响。当前端调度流量治理团队能做到 5min 内切流 93%的生效速度，结合动态加速回源机制，最快能做到 2min97%的外网切流生效速度，这种方式对比常规域名解析的切流形成了巨大的优势；

• 其次，在能力方面，由于网络库代理了端上网络请求的全流程，因此在请求的各个阶段都可以施加定制逻辑。比如决定这个请求使用什么协议，解析结果的使用策略如何，自动化的测速选路，甚至决定这个请求是否要发出。这对比传统的决策一个非连接复用的请求的目标 ip，在能力上也是得到了极大的提升；

• 最后，在调度的粒度上，由于端上网络库的获取机制是基于用户参数的，因此火山引擎边缘云的调度除了区分传统的地域运营商外，还可以增加各种丰富的维度。比如根据用户的机型和操作系统版本、 app 版本、用户 id 分组、实验分组，甚至能够在域名之内对不同的 path 定制不同的调度策略。

综上所述，火山引擎边缘云在端内的调度层面提供了很多强大的特性，可以一定程度上理解为将 7 层能力下沉到端上，并且，这一切是不需要额外的资源消耗的。

这张图是在 21 年春晚的现场，基于流量治理团队的接口级降级能力，现场全站实际流量的控制情况。在整场晚会期间，通过实时控制及预埋配置等手段，确保降级配置的在各版本的覆盖度。在口播前后，能做到 2min 内执行深度降级，口播结束 2min 后全量回复。可以看到，中间这个峰值就是口播降级后冷启流量的冲锋，如果没有高效灵活的降级策略，这个峰值会对系统造成比较大的冲击。最终正常活动在用户体验无损的情况下，基于有限的资源消耗顺利结束。

Story2

接下来介绍的是端边调度结合的案例：

同样是春晚场景，即使流量治理团队在端上做了一系列的深度降级尝试，流出到网络上的需求，依然对资源产生了巨大的压力。比如在动态加速层面，需求已经到达了 97%的规划水位。这对团队提出了一个新的问题：如何做精细化的调度控制，确保流量在高水位情况下的运行是高度可控的。

对于静态流量，常见的精细化调度，可以通过 302 调度，或者在 feed 推荐服务返回资源链接时，顺便在服务端进行精细化的厂商间调度。这些操作对于 CDN 这种资源类的请求是合理的，因为调度的成本相对与请求的成本还是比较小的。但是对于 API 类流量，不太可能在请求的同时，为了做调度而大范围的增加一跳 302，或者对每个请求附加一次调度计算，这样会导致成本很高。实际的解决方案，还是基于端能力的维度控制能力，将端按照设备 id 进行 hash 分组，控制不同分组的用户，指定请求发往不同的厂商，从而低成本的实现了高度精准可控的调度效果。

Story3

接下来介绍一个云边调度结合的案例：

仍然是春晚场景，当流量需求过大时，即使已经在端上做了足够的降级，在边缘层面做了精细化的调度。但是在源站层面，当时已有的资源，仍然不能满足需求。这就需要对系统架构进行一些调整。

经过业务方的努力，可以将一部分便于拆解的活动业务，上移到源站机房之外，距离源站机房较近且有专线互联的边缘资源上，那么接下来对调度系统的挑战就会被细化成：

• 首先，业务在新的架构下部署，如何引导流量进行快速验证、在云边之间做灵活的流量切换；

• 其次，是流量进入边缘侧后，在边缘层面的多个节点间，符合确保负载均衡、就近接入的效果，以及容灾效果。

应对这些挑战，火山引擎边缘云提供了功能丰富的标准化解析类调度产品 TrafficRoute。TrafficRoute 能够将多个边缘节点上的业务，进行地址池的定义和编排，结合每个接入点的容量、以及临近省份线路的质量和举例，进行综合的负载均衡调度决策，并且其自带的拨测模块，也能够快速的发现故障并自动执行故障转移。

TrafficRoute 在真实的海量活动流量场景下，提供了有效可靠的支持，也是火山引擎边缘云内部最早完成内外部统一的标准化调度组件。

Story4

接下来介绍云边端一体的综合调度系统。

当缺乏一个全局综合操作系统时，可能会遇到如下的情况：各标准化的产品，基于自身提供的能力，各自面向不同的业务需求提供服务。其中有一些是经过接入方 SRE 把控的，有一些是业务直接和产品对接的。在这种情况下，各需求和方案没有一个统一的控制方，可能会导致方案的规范性问题，比如有些自动容灾特性被遗漏，或者有些特性被应用到错误的场景上。此外，各方案独立维护，对于全局公用的资源缺乏协调决策，当出现冲突时，方案之间的同步成本较高，决策链条较长，这在大型流量场景下都导致了全局可控性变差。

为了规范性的管理和解决上述问题，流量治理团队对调度体系中的策略管理体系进行了梳理。从策略影响的资源角度进行划分，对于完全独立控制资源的策略系统，不需要综合调度系统进行干涉的，可以直接对接全部需求方。比如融合 CDN 在厂商间的容量分配，或者自建 CDN 在节点间的容量分配，这些问题都是系统内闭环的；另一方面，对于需要进行综合决策的资源，比如源站的带宽、各业务公用的接入集群，可以将需求统一收敛到全局流量综合调度系统 BTM 中，由 BTM 负责感知全局的流量和资源情况，在具备全量背景信息的状态下进行综合决策，并负责将决策结果下发至各实际调度系统中去执行。

那么，BTM 作为一个全局感知、综合决策的系统，其内部应当如何设计呢？

这是一个在业界没有参考的问题，需要流量治理团队独立去抽象和拆解它。首先，从系统的核心元数据模型进行介绍。根据经验，大多数调度决策系统的共性问题，可以抽象为流量、策略、资源三元素。这个模型可以描述为，首先存在这一定接入资源，这些资源有容量、拓扑、状态信息；其次，系统中存在着各种流量，每种流量可能由不同的调度系统负责，根据不同的策略，最终都在这个具有拓扑和容量的资源系统中。只要能对这个三元素的元数据完成建模，就有可能在一个抽象的空间中进行模拟和规划，快速获得全局调度的可行解。

简单的介绍一下 BTM 系统的架构：

• 首先整个系统的运行被划分成物理层和抽象层：如同为了让一次编译后的程序运行在不同的硬件机器上一样，需要有一个操作系统，有各种硬件设备的驱动适配，有虚拟的运行时地址空间，通过物理和抽象之间的映射，为上层策略层提供统一稳定的控制环境。物理层和抽象层的边界，称为 adapter，对标操作系统的驱动。adapter 需要适配各个实际调度系统的 api、逻辑和特性，尽可能的将各系统的能力按照流量、策略、资源三元素进行抽象，完成状态上传和指令下达的功能。同时，还需要一套强大的数据 adapter，根据多种数据源，根据 BTM 对各种流量和资源的定义将真实的流量运行数据反馈上来。

• 在抽象层内，BTM 调度系统的工作会分为静态管理和运行时管理；

• 在静态管理范畴，BTM 的主要工作是，基于对资源的容量及拓扑、流量的调度策略模型的抽象，对流量需求进行管理。在规划层面对流量进行快速的预分配，其中也包含了大量容灾场景的自动规划工作。这些前置性的工作能够以较低的成本，快速发现局部的资源风险，为流量架构设计及资源建设提供有效的输入；

• 运行时的管理是 BTM 的核心模块。其中包含了对流量的实时数据、调度配置的实时元数据取值的统一管理。在运行时根据资源和流量调度的实时结果，快速完成规划，并通过 adapter 下发执行，观察执行后的流量变化情况，在下一轮中进一步调整，最终形成闭环。当前 BTM 的规划能力，对于上千条 flow，在上百各资源对象的规划取值，已经能够做到分钟级求解。

最后从另一个角度来介绍 BTM 系统的愿景，即数字孪生。

数字孪生的概念提出，对于物理运行的系统，应当存在着一套 infrastructure as code 的数字系统，对其进行实时映射。那么基于这个数字的映射，就可以监控观察系统的状态，当系统存在问题时，能够进行快速的诊断。当团队预期要做一些操作时，可以在数字孪生系统中对系统行为进行预测，从而提前规避风险。最终，数字系统对物理系统应当是具有可控性，能够将规划验证好的操作，快速批量的执行下去。基于这样的数字孪生系统，火山引擎边缘云的调度体系对于大规模复杂流量场景的控制，能够获得更加成熟、高效、可控的效果。

未来展望

结合实际处理线上大规模流量的经验，刘学提出了对未来的一些展望。

• 首先在资源层面，当前源站接入正在向更加复杂的 pop 点方式演进。如果调度系统能够适配加入资源的复杂度，就能获得新资源在容量和成本上的收益。当然这对火山引擎边缘云的资源体系构建、容灾场景的复杂化，都提出了进一步的挑战。

• 其次，字节整体的服务架构正在向着多 Region 化、多云的方向演进，这对调度系统的适配也提出了进一步的挑战，流量治理团队需要在抽象层面全面适配业务的单元化改造。

• 最后，综合调度系统作为一个协调者，它对下游调度系统的影响，有些是指令式的，比如直接控制一个域名的解析，这种方式对底层的能力系统是没有决策空间的；而另一种和下游调度系统的联动是策略式的，是间接的影响。比如，如果希望直播系统在源站某条线路的使用，最多不能超过一个 quota 值，而在 quota 内的调度，由直播调度系统来自行决策。这样对综合调度系统提出的挑战是，为了给出实际可执行的决策，需要对这些策略型的调度系统进行建模，根据一个有效的模型推导出有效的 quota 决策，进而持续提升策略联动的可控性。