跟着近几年音视频流媒体职业的持续开展，海量并发、低延时和低成本作为三大中心诉求依旧需求不断深挖，一起跟着 RTC 和 CDN 这两种技能的界线越来越含糊，因而有必要从底层架构层面从头考虑 RTC 与 CDN 的交融之道。本文将要点共享：网易云信怎么构建 RTC-CDN 服务架构，深化剖析这套架构是怎么处理海量并发、超低延时与低成本三大职业中心诉求，并结合低延时直播和元世界两大场景，为咱们解说 RTC-CDN 的中心技能和最佳实践。

背景介绍

咱们能明显感受到近几年视频云职业的迅猛开展，不论是在传统泛文娱交际、教育、在线会议范畴，仍是在元世界、云游戏等创新范畴都有较好的增长。随之而来的是这个赛道在国内越来越卷，越来越多的公司投入这个范畴，也不断推进着视频云技能的迭代升级。

简略罗列几个这两年比较热门的技能方向：

• 出海和全球化。 跟着视频云国内商场进入红海阶段，咱们都开始向海外商场打破，音视频全球化的技能才能越来越成为各个厂商重视的要点，本文的第二部分会共享网易云信构建全球化的流媒体服务的相关内容；
• 超低延时流媒体技能。 或许换一个说法，便是在一套体系里面去满足不同场景从 200ms 到 1.2 秒的差异化延时需求，一起还要做到低成本，本文的第三部分中共享这些内容；
• 元世界与虚拟人。 跟着 Metaverse、Avatar、NFT、Web3.0 等新兴技能大热，视频云范畴也不断涌现出新的技能方向与之匹配，本文的第四部分会和咱们讨论相关计划；
• 规范化。 跟着职业的开展，规范化协议和规范化计划越来越被企业需求，规范化是低成本的一部分，本文将会共享近两年网易云信在规范化方面的探索、考虑和实践。

跟着音视频流媒体相关需求的日益增长，未来流媒体职业还有无限时机，一起也面对着众多应战。

以下是低延时海量并发流媒体体系会面对的三大应战：

• 在低延时流媒体体系里，需求满足包含 RTC 实时音视频、直播、低延时直播、IoT 机器人、嵌入式设备等各类场景对延时的要求，为了完成不同的延时要求，低延时流媒体体系不仅要具备很强的协议兼容才能还需求具备很强的架构自适应才能；
• 跟着流媒体体系承载的场景越来越丰富，整个体系需求承载的并发也越来越大，包含单频道的百万并发，以及晚高峰的的流量蜂拥，这就要求咱们的体系具备很好的弹性扩缩容才能；
• 跟着全球化的用户接入，还需求面对全球范围内杂乱多变的网络状况，包含小运营商、偏远地区和非洲等国家的 2.5G 或 3G 网络，以及更为杂乱的跨国通讯的网络场景。

带着这些问题和应战，咱们本文的第二部分。在这一部分，咱们紧扣主题里关键字“海量并发”，会和咱们深度讨论一下怎么构建支撑全球化海量并发的流媒体服务器架构。

构建海量并发流媒体服务架构

首要，咱们从大局的维度来看看网易云信是怎么做多协议交融通讯流媒体服务体系的。

如图所示，整个架构的中心，是云信的流媒体传输与处理服务器，其中包含了边际媒体接入体系、实时传输网体系、流媒体处理服务体系以及直播点播服务体系。在交融通讯流媒体体系中，除了云信 SDK 以外还支撑了多种协议客户端的接入，在边际媒体接入服务模块中，咱们的边际媒体服务器既支撑云信 SDK 的接入，也直接支撑了规范 Web 端运用 WebRTC 接入；别的云信自研了 SIP 网关服务器，完成了 SIP、PSTN 的接入；云信运用通用媒体网关完成了规范 RTMP 推流东西、小程序、RTSP 监控摄像头的接入。

在边际媒体服务体系收到各协议客户端的媒体数据包以后，会经过云信实时传输网的边际节点和路由节点进行全球实时媒体数据分发，确保端到端的最优体验。一起运用流媒体处理服务的通用媒体处理服务器 MPS，能够将媒体流混合以后旁路转推到互动直播服务器，再经过云信的直播和低延时直播的交融 CDN 体系进行分发；还能够在云端进行录制后，存储到云信的点播服务体系中。

在流媒体传输与处理服务体系的左面是大局流媒体操控服务，它包含了：频道与流办理服务，统一媒体调度服务和实时传输网调度服务，它是整个音视频交融通讯体系的大脑，由它来动态操控整个体系的工作。

最右侧，是大数据与装备服务体系，它包含了大局大数据分析和发掘体系，担任全链路各个采集的数据处理、告警和质量透明，并运用大数据发掘的成果指导全链路各模块算法和战略的拟定，另一个是咱们智能大局装备办理和下发服务，它担任对咱们各类云端参数的下发，包含 QoS 参数，音视频编解码参数以及 A/B test 的相关开关。

在网易云信交融通讯流媒体架构中，许多运用了解耦与分层的思路。接下来，咱们深化到其中流媒体传输与全球传输大网两大中心体系，看看解耦的思路详细是怎么落地的。

网易云信交融通讯流媒体架构——解耦

首要是流媒体传输模块的解耦，包含了操控面、媒体转发面以及全球大网传输面三层解耦。客户端衔接到边际的媒体服务器上以后，客户端流的发布和订阅的信息都由边际服务器同步给频道与流办理服务，所有频道事务层面对流的操作都由办理服务器统一处理，这便是操控面和转发面的解耦。这么做最大的优点便是媒体服务器上没有杂乱的频道状况，那么在多台媒体服务器级联的时分，就无需在媒体服务器之间同步流的状况和信息，这么做大大降低了级联的难度以及各级联的媒体服务器之间状况不同步导致的问题，也十分易于完成万人乃至十万人的大房间。

其次，边际媒体服务器之间的级联采用的是无向图结构，所有级联的媒体服务器节点都是相等的，没有极点就不存在单点毛病问题。

最后，两台媒体服务器的级联中心链路的路由优化，由中心的实时传输大网来做，媒体服务器自身并不关怀中心途径的规划问题，这么做也进一步的解耦了媒体服务器与大网传输体系，大网传输也无需关怀详细的音视频事务。实时传输网的边际节点依据实时传输网调度服务的统一调配，经过传输网的路由节点，将数据包以最优途径发送到目的边际媒体服务器。在这个过程中实时传输网路由勘探和核算服务是链路路由挑选且确保最优质量的的操控大脑。媒体服务器的级联行为彻底按需由用户的媒体分发需求触发，而大网的也只需求考虑网络传输链路最优路由，两个体系各司其职，做到极致优化；由于采用了彻底解耦的设计，因而大网体系也充满了幻想空间，可用于除了 RTC 媒体传输以外的许多场景。

云信流媒体服务器架构——解耦（大网内部）

下面一起来看实时传输网 WE-CAN 内部的解耦和分层是怎么做的。

咱们把 WE-CAN 从下到上分为 6 层，中心的当然是网络层、传输层和应用层了，某种程度上对应传统的互联网模型的三层，当然不是严厉对照。

在分层架构最底下是基建层，基建层都是咱们网易自研或许说云信自研的一些根底渠道。包含数据渠道、管控渠道即咱们 WE-CAN 的内部 Dashboard、咱们自研的一个全球的分布式的缓存体系即所谓存储渠道，还有装备渠道。

基建层往上的操控层其实和网络层结合十分严密，能够看到接入、转发、路由和调度这四块是 WE-CAN 最中心的模块。再上面的传输层主要是一个协议层，网络层和操控层是做路由的，传输层是做 QoS 和各种各样的传输战略。最上面的应用层是对传输层和网络层才能的封装，做了许多比较笼统的根底服务，而事务层是实际各个事务场景中对应用层才能的运用。

那么为什么要强调网络分层呢？首要 WE-CAN 自身便是一个 overlay，它自身便是根据公共互联网上的一层。其次网络分层做得好，我以为能够做到各个体系模块各司其职，体系鸿沟也十分明晰，并且其实各层有各自不同的传输优化战略，比方网络层和传输层的优化战略是不一样的，能够做的工作不一样，乃至相同的优化战略如重传，在网络层和传输层的完成方法也是不一样的，网络层战略都是转发节点间逐跳的，传输层是接入节点到接入节点之间的。

最后网络分层宽和耦做得好，能够支撑更多的传输场景。WE-CAN 不仅是要支撑实时音视频通讯、低推迟媒体流传输，咱们是要做一个通用的传输加速网络，所以分层做得好能够把各层的才能笼统剥离，就能够支撑更多的传输场景。目前云信已经将 WE-CAN 应用在 RTC、IM、直播点播和数据上报等场景。

全球化与单元化

跟着全球化和出海的需求越来越多，为了优化全球用户的接入质量以及防止单点毛病，体系的全球化和单元化是极其重要的。

下图是一个 RTC 服务器架构的简图，咱们简化了操控单元的数量，可是足以阐明问题，关于它的布置架构，右边这三个关键词能够十分形象的描述它的整体设计理念。

第一个关键词仍是分层解耦。整个 RTC 服务器能够划分成三个层次，首要是信令接入层，这是整个 RTC 服务的进口。其次是媒体信令层，这层是 RTC 媒体服务器的操控中心，会和底下第三层次的媒体服务层进行许多的信令交互。

详细来看每个服务层的完成计划，关于信令接入层来说，运用全球布置的智能 DNS 和 HTTP DNS 服务，云信完成智能 LBS 服务能够将请求智能负载均衡和灾备到各个操控单元进口网关；每个操控单元均独立布置支撑 HTTP3 和 QUIC 的进口网关、频道与流办理服务以及调度服务，操控单元之间运用 WE-CAN 完成的全球分布式消息同步机制，同步必要的信息，做到操控单元间的灾备和信息一致性，做好上面这些，就完成了第二个关键词——数据阻隔和同步；而关于媒体服务来说，全球范围内的所有媒体服务器以及 WE-CAN 传输大网节点均是所有单元共享的，这样就能够做到边际节点最高资源运用率；

最后一个关键词——单元互备。操控单元内的不论信令进口仍是频道管控调度服务均是单元互备，每个服务层均支撑单元化的布置，经过单元间的互备，能够防止单点的毛病影响大局。

调度之道

在看完了全球化与单元化的计划后，咱们把目光聚集到调度体系，调度作为流媒体体系中的中心体系，它的重要程度不言而喻。

打开来看，云信的调度体系里面最中心的要两套战略：静态调度和动态调度，这两套战略并不是相互独立收效，而是严密配合的。关于静态调度来说十分好理解，调度依靠的中心数据源是全球静态的 IP 库，云信运用多个 IP 库并保持 IP 库的每日更新，来尽量保障 IP 解析的正确性；静态调度的调度战略也相对简略：运用同 ISP 运营商、地理位置就近接入；运用 BGP 节点掩盖小运营商；当然还需求确保大局的负载均衡以大区阻隔，所谓的大区阻隔举个比如：中国大陆的用户无论怎么不会调度到中国大陆以外的服务器节点，即便是数字层面的距离十分近。

静态调度战略在云信早期运用多年，但跟着全球化和各类不同用户的接入，由于用户网络和运营商的杂乱性，静态调度已经满足不了最优接入的要求；最典型的比如便是在中东，各种网络运营商数量繁多，某些中东用户衔接欧洲节点反而比衔接中东本地节点更快、更稳定。为了处理此类问题，咱们引入动态调度体系，中心思维是运用真实事务数据的大数据分析，驱动调度的调度战略的动态批改。打开来讲：用户登录边际节点的前史登录成功率，用户在某个边际节点的服务端侧的 QoS 数据以及客户单侧真实的 QoE（卡顿、延时）数据，这些数据都会作为某个用户的前史通话质量指标成为动态调度体系的输入；别的通话前的实时勘探和通话过程中的采样打点勘探，这些勘探数据也会用于那些没有前史通话数据用户的动态调度。动态调度体系不仅处理了用户的接入由原来的 “最近”接入升级为了的“最优”接入，还对成本优化带来了正向作用，咱们发现在许多省市的小运营商用户运用带宽费用较低的单线机房时 QoE 作用还优于运用带宽费用高昂的 BGP 节点。

当然再智能的调度的调度算法也有掩盖不了的边际状况，所以咱们在调度体系中也引入了特别规矩装备体系，我以为这个是十分必要的，某些 bad case 现阶段仍是只能运用特别规矩来匹配；别的关于一套老练的调度体系来说，任何的调度算法和战略变更都需求做完好的 A/B Test，所以一套完善 A/B Test 体系要满足：从规矩收效、灰度份额操控、请求染色，到最后的成果量化验证，一定要构成一个完好的闭环。

流量蜂拥处理之道

• 根底是要做要负载均衡，需求要点重视负载搜集的及时性，包含算力和带宽负载压力的搜集。
• 从流媒体的角度需求做好事务结合，特别是 RTC 的事务形状比较特别，一个大房间的流量蜂拥，有时就会形成雪崩效应。从媒体分发的角度上要从频道级别做好频控和带宽预测；从信令的角度上要做好信令兼并，信令分级和滑润削峰行列。
• 除此之外需求有兜底战略，做好限流和熔断，设计好服务优先级。比方在大房间的场景下，用户列表的实时同步是一个十分消耗资源的服务功用，在蜂拥的状况下，非主播的用户列表能够从实时同步降级为定时同步，这样能够尽量不影响事务可用性的状况下，大大降低服务端的压力。
• 最后根据 K8S 的动态弹性扩缩容才能是流媒体蜂拥之道处理的未来。

总结来说我以为好的调度体系，便是能在资源有限的前提下到达大局最优。

以上内容为上半部分，下半部分内容请持续重视。