海量并发低延时 RTC-CDN 系统架构设计（上）

随着近几年音视频流媒体行业的持续发展，海量并发、低延时和低成本作为三大核心诉求依旧需要不断深挖，同时随着 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 的动态弹性扩缩容能力是流媒体蜂拥之道解决的未来。

总结来说我认为好的调度系统，就是能在资源有限的前提下达到全局最优。

以上内容为上半部分，下半部分内容请持续关注。