共计 5125 个字符，预计需要花费 13 分钟才能阅读完成。
随着近几年音视频流媒体行业的继续倒退，海量并发、低延时和低成本作为三大外围诉求仍旧须要一直深挖，同时随着 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 的动静弹性扩缩容能力是流媒体簇拥之道解决的将来。
总结来说我认为好的调度零碎，就是能在资源无限的前提下达到全局最优。
以上内容为上半局部，下半局部内容请继续关注。
