共计 8329 个字符，预计需要花费 21 分钟才能阅读完成。
火山引擎是字节跳动旗下的云服务平台，将字节跳动疾速倒退过程中积攒的增长办法、技术能力和工具凋谢给内部企业，提供云根底、视频与内容散发、数智平台 VeDI、人工智能、开发与运维等服务，帮忙企业在数字化降级中实现持续增长。LiveVideoStackCon 2023 上海站邀请到刘学介绍火山引擎在大规模流量下的云边端一体化流量调度体系。
文 / 刘学
编辑 /LiveVideoStack
大家好，我是来自火山引擎边缘云流量治理团队的负责人刘学。明天我将会从大规模流量场景的挑战、云边端一体化调度体系、场景落地实例和将来瞻望四个局部开展介绍大规模流量下的云边端一体化流量调度体系。
-01- 大规模流量场景的挑战
火山引擎边缘云提供了一系列标准化的接入产品，在端边云的接入门路上，长期服务于抖音团体内各种大规模音视频流量 APP，包含抖音、今日头条、火山小视频、西瓜视频等。
这些利用产生的根底流量次要分为点播、直播、投稿和 API，各类型流量的特点别离为：
- 点播流量：包含 CDN 边缘层面的超大规模流量，以及多层缓存零碎的回源流量。当边缘流量足够宏大、资源足够丰盛时，回源流量在源站层面也是十分重要的流量之一。
- 直播流量：随着大型赛事流动、电商等业务的倒退，直播也是咱们流量成分中的重要组成部分。直播的流量架构会包含推拉流及审核流等，在源站和边缘层也都会占用比拟可观的网络资源。
- 投稿流量：作为 ugc 状态的 APP，投稿这部分流量是不可漠视的，近一段时间随着点播业务社交属性的加强，投稿流量的压力次要在冷流业务，比方每年投稿零碎最大的峰值挑战，其实是在除夕春节的零点，这个工夫大家都喜爱集中感叹一下，也给咱们的零碎提出了比拟严厉的挑战。
- API 类流量：这类流量的特点是申请必须在源站，基于简单的计算或海量用户数据来实现服务，且单个申请的体量较小。场景包含举荐、搜寻、账号、直播间刷礼物、音讯等等，这些也音视频 APP 必不可少的流量形成。
对于多种类型的业务流量，这些流量在外网接入的领域，会通过火山引擎边缘云的哪些产品集进行反对呢？
- ①在端内：边缘云提供了字节对立的挪动端网络库 MNet，通过 MNet 代理的网络申请，在性能、协定、安全性等方面均能失去深度的定制优化反对；
- ②在边的层面：边缘云提供了多种状态的缓存和减速服务。其中包含用于反对点播流量的 CDN 产品，贴近用户提供点播推拉流、转码等计算和网络服务的边缘计算、边缘网络产品，以及为 API 类流量提供就近接入、全门路减速的 DCDN 产品；
- ③在云的层面：在申请达到最终的业务 server 之前，边缘云接入团队也提供了相应的 4 / 7 层负载平衡产品。
那么，对于咱们提到的这些异构的流量，在比较复杂的全局接入架构下，会遇到那些有挑战的场景呢？我和我的团队，在过来几年中须要帮忙业务去解决的一个次要问题是：
对于抖音团体全副的接入流量，在日常用户规模、流量规模都十分宏大的的背景下，在公司层面进行诸如春晚红包、世界杯直播等大型流动时，外网流量接入的总体解决方案是什么？这外面咱们面临的流量压力会包含：
- 首先，各种流量都有常态的流量作为根底，并且随着流动的拉活，在线人数减少，像 API、点播这类日常流量，会有肯定的放大；
- 在此基础上，咱们还要持续承当特定的流动行为所带来的额定流量需要，比方春晚的红包组队工作、世界杯主直播间音讯刷屏等；
- 最初，就是一些非凡时刻的要害挑战，比方春晚的口播、除夕零点的投稿，这可能是整场流动的焦点时刻，是在后面所有流量上涨的根底之上，再叠加一个比拟夸大的需要数字。
在上述流量场景背景下，咱们所面临的挑战会包含：
首先是在整个流动的时间轴上，咱们须要思考上述各种流量增长的高水位叠加。这些增长的流量，在工夫和空间层面，有些是可预期的，比方红包的工夫点，口播广告的工夫点等等；
有些是难以预期的，比方世界杯的小组赛阶段阿根廷对沙特、德国对日本的这两场，在比分爆冷后整个直播间流量上涨的的状况是远超后期预估的，这须要咱们在难以精确预估的前提下，在计划下来依据资源的供应状况做倒推，依据流量上涨的水平设计分级的降级解决计划；
第二层挑战来自于资源层面：首先是周期问题，绝对于流动决策，资源建设的周期，比方带宽扩容、机器的洽购，都是须要比拟长的周期的；其中有局部资源如果短期购买的话，老本是十分高的，这种高价资源的必要性如何去评估；以及如果短期内咱们即便买到了一些异构的资源，架构上如何把这些资源比拟稳当的应用起来，在布局层面要给出通过计算排布、确保可行性、变量和危险可管制的接入计划，这些都是资源层面所面临的一些挑战；
最初是容灾场景。在后面咱们介绍过的海量需要和简单架构的背景下，咱们须要进一步思考容灾场景。在流动期间如果产生了各种场景的故障，咱们须要具备提前设计好、计算好、演练过的预案。基于惯例的接入架构设计计划，进一步的去做 n 种场景的容灾预案，会将整体的工作量放大 n 倍，并且进一步的拷问咱们的零碎极限在哪里，在最顽劣的状况下，咱们要舍弃什么，保留什么，如何确保打算的动作能精准的施行上来。这些是咱们在容灾极限场景下所面临的挑战。
容灾的能力也非常重要。在各种大规模流量的输出状况下，资源非常受限，可能会导致呈现一些故障，这时就须要依照提前计算布局以及演练过的成熟预案进行场景开展。场景上的开展，无论是在技术层面还是工作量层面都翻了很多倍，如何保障容灾的可行可控也具备也具备挑战性。
-02- 云边端一体化调度体系
接下来这一页咱们介绍一下，在后面提到的这些流量和场景的挑战下，咱们从调度视角能够如何对各个接入产品的调度能力和策略进行整合，造成一个云边端一体化的调度体系。
首先咱们看右边这张架构图，这是对后面的接入架构图的一个简略的细化，外面蕴含了各组件的流量调度能力的局部：
首先在端内的层面，抖音团体的流量调度体系中，一个比较突出的特色点就是：咱们将调度零碎的边界，从传统的基于域名解析形式，回升到了端内。基于端内网络库的能力及云控计划，能够使咱们获失效速度更快、能力更加弱小多样、调度粒度更加精准的新一代解决方案。
其次，在边缘层面，抖音团体大规模的应用了交融架构。其中包含动态 CDN 在多厂商间的交融、直播 CDN 在自建的边缘计算资源和三方厂商之间的交融，以及动静 CDN 的交融。这外面咱们提到的交融，即包含同构资源的横向交融，也包含一些异构资源在纵向的跨层交融，比方当咱们外围机房的资源有余时，能够将一部分业务上移至间隔外围机房较近的边缘资源上。
在源站层面，对于源站各机房、线路的入口带宽，各种接入组件提供了不同的回源调度能力，比方 CDN 零碎基于 302、回源配置的源站调度，以及 API 类流量基于域名解析的源站调度。在源站的入口和上游业务之间，LB 产品也提供了最初一层的内网调度能力，将源站业务的调度需要，与简单的外网接入接入链路进行最大水平的解耦和屏蔽。
由此，咱们能够看到调度体系的一个要害特点，就是各零碎间的分层和合作。为了构建一个高内聚、低耦合的调度合作体系，咱们须要援用计算机领域的一个通用思维，即能力和策略分层。在特定问题上，须要十分明确的定义，哪些零碎是提供配置能力的，哪些零碎或角色是负责对配置进行取值决策的，比方对于交融 CDN 调度零碎，在边缘层面首先要负责指定域名在指定线路到指定厂商的决策，这是一个策略零碎，其依赖的能力能够是 dns、httpdns 或者 302 配置，另一方面，对于回源流量，CDN 提供多种回源配置的能力，但源站带宽的布局就是另一个独立的策略零碎了。
好的设计可能使每个模块的指标是繁多、内聚的，防止在决策时引入太多不合理的顾虑。比方字节在过来的一段时间，各 API 类流量的机房间流量调度，是依赖外网调度的，这会导致后端业务模块间的调度配置在域名维度被绑死了，不够灵便，同时外网在部分线路带宽有余须要调整时，还要参考各后端业务的部署容量状况，为了解决这类问题，咱们在 7 层转发层强化了源站的内网调度能力，通过对内外网调度的解耦，使得各层级所要解决的问题更加正当。
对于这种跨多层问题的解决，咱们也能够从另一个角度去了解。当问题规模足够大时，咱们是用 sacle up 的形式尝试在一个单元中去解决所有问题呢，还是用 scale out 的形式，将问题进行正当的拆解，将不同的子问题散发到不同的单元中进行解决，最初再进行整合呢？在这里显然，咱们走的是 scale out 的路线。
最初，每个调度子系统各司其职的前提下，咱们依然须要一个对全局状况进行汇总的综合调度零碎，对应左边的这个零碎 BTM。对于一些综合性的问题，须要在全局层面进行对立决策协调的时候，咱们依然须要一个顶层的仲裁者的角色。比方后面咱们提到过的流动期间的容灾场景，假如一个源站机房故障，各流量负责的零碎都在向其余机房切流，那么谁来计算和保障其余机房的容量是平安的呢？谁来协调各流量间的降级优先级和降级深度呢？这都须要一个综合决策性质的零碎，参考各业务流量的特点、流量实时大小，以及资源的水位和状态，从全局角度进行决策，在调度零碎通用的这几个指标下，即容量、容灾、老本、品质、以及思考特定的业务束缚，寻求绝对的最优解或者可行解。
-03- 场景落地 Story
Story1
接下来咱们通过一些具体的场景和案例，介绍咱们调度体系可能提供的解决方案，以及对应的特点。
首先还是将镜头拉回到春晚的场景，咱们先讲一个最极其的时刻，就是口播时刻。这个场景在业务层面的状况是，主持人会在特定的广告时刻，疏导全国的观众关上抖音系的 app，进入红包流动。
在技术层面，预期会产生的流量包含，以流动期间高于惯例晚顶峰的大盘流量为根底，段时间内叠加海量的冷启流量和流动流量。
冷启流量包含启动后的一系列 api 申请，以及首刷点播，流动流量次要指红包玩法。家喻户晓，红包玩法能够做一系列的缓存、打散、削峰的定制化设计，反而是冷启流量更加难以管制，因为口播行为是固定的，口播带来的冷启申请也是无奈做打散的。
为了应答这些挑战，传统的解决方案包含，对于首刷点播流量，能够通过限度码率、举荐高热视频等伎俩尽量减少 CDN 流量的耗费，对于 API 类流量，能够通过版本更新，将流动版本的冷启流量限度到最低，但这受限于流动版本的开发工夫和公布周期，往往到流动时刻的版本覆盖率并不现实。在此基础上，常见的一些解决计划可能包含在 dns 层做黑洞，但整域名的封禁往往会随同这很多误杀，且 dns 层面的封禁和解封时效性也并不可控，或者将接入层作限流作为次要伎俩，单这须要对接入层堆很多的资源，毕竟流量洪峰到来时，握手和协定的开销不可避免。
那么，是否存在着更加无效的解决方案呢？在抖音团体外部，端上的申请次要是通过定制化的网络库进行代理发送的。能够看到，申请解决的过程中，会由网络库进行外部域名的定制、协定优化、甚至申请 drop 等操作，这一系列操作都是云端实时可控的，通过网络库的申请，在调度层面能够取得更快、能力更强、维度更加精准的劣势：
首先对于调度的失效速度，咱们能够看到，端内的申请依据是否连贯复用，会分为 2 种不同的执行状况：
- ①应用 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 的外围模块。
其中蕴含了对流量的实时数据、调度配置的实时元数据取值的对立治理，在运行时依据资源和流量调度的实时后果，疾速实现布局，并通过 adapter 下发执行，察看执行后的流量变动状况，在下一轮中进一步调整，最终造成闭环。以后 BTM 的布局能力，对于上千条 flow，在上百各资源对象的布局取值，曾经可能做到分钟级求解。
最初咱们从另一个角度来介绍 BTM 零碎的愿景，即数字孪生。
数字孪生的概念提出：对于物理运行的零碎，该当存在着一套 infrastructure as code 的数字零碎，对其进行实时映射。那么基于这个数字的映射，咱们就能够监控察看零碎的状态，当零碎存在问题时，可能进行疾速的诊断。当咱们预期要做一些操作时，能够在数字孪生零碎中对系统行为进行预测，从而提前躲避危险。
最终，数字系统对物理零碎该当是具备可控性，可能将咱们布局验证好的操作，疾速批量的执行上来。基于这样的数字孪生零碎，咱们的调度体系对与大规模简单流量场景的管制，可能取得更加成熟、高效、可控的成果。
-04- 将来瞻望
结合实际解决线上大规模流量的教训，咱们提出对将来的一些瞻望。
首先在资源层面，以后咱们源站接入正在向更加简单的 pop 点形式演进。如果调度零碎可能适配退出资源的复杂度，就能取得新资源在容量和老本上的收益。当然这对咱们的资源体系构建、容灾场景的复杂化，都提出了进一步的挑战。
其次，字节整体的服务架构正在向着多 Region 化、多云的方向演进，这对调度零碎的适配也提出了进一步的挑战，咱们须要在形象层面全面适配业务的单元化革新。
最初综合调度零碎作为一个协调者，他对上游调度零碎的影响，有些是指令式的。比方间接管制一个域名的解析，这种形式对底层的能力零碎是没有决策空间的；而另一种和上游调度零碎的联动是策略式的，是间接的影响。比方我会心愿直播零碎在源站某条线路的应用，最多不能超过一个 quota 值，而在 quota 内的调度，由直播调度零碎来自行决策。
这样对综合调度零碎提出的挑战是，为了给出理论可执行的决策，咱们须要对这些策略型的调度零碎进行建模，依据一个无效的模型推导出无效的 quota 决策，进而继续晋升策略联动的可控性。
