共计 3865 个字符，预计需要花费 10 分钟才能阅读完成。
技术系列课回顾 | 网易云信线上万人连麦技术大揭秘
本文依据网易云信资深音视频服务端开发工程师陈策在《MCtalk Live#5：网易云信线上万人连麦技术大揭秘》线上直播分享整顿。
导读
大家好，我是来自网易云信的陈策。连麦作为一个强互动场景，单房间内的高并发始终是个比较复杂的问题。这次给大家分享网易云信在万人连麦这个场景上的摸索和实际。
比拟典型的万人连麦需要场景有视频会议研讨会、低提早直播、在线教育大班课、类 Club House（多人语聊房）等。对于万人连麦的需要场景市面上广泛的解决方案是“RTC+CDN”的形式，即限度上麦主播人数在小规模（50 人左右）进行 RTC 互动，而后转推到 CDN，大规模的观众再通过 CDN 直播拉流的形式实现。这种解决方案在业务上限度了上麦人数，并且观众和主播之间有较大的声画提早，无奈满足云信的业务要求。例如，在游戏语音场景中，会有大量的用户开公麦，须要做到所有人都能够上麦，并且上麦人数不限度。那么，网易云信是如何解决这个问题的呢，本文将和大家分享咱们在这个问题上的摸索。
信令的技术难点
信令并发、弱网和高可用问题
咱们在这个问题的探讨分为几个方面：信令、音频技术、视频技术以及服务器间的网络传输，先来看看信令的实现。
RTC 是应用长连贯进行双向告诉的。假如某个语聊房主播有一万人，那么只有其中某一个主播上 / 下麦或者退出 / 来到房间，都会触发对其它 9999 人的信令告诉。这种随机的用户行为会让服务器刹时压力十分大。
传统的中心化单点服务器显然是支撑不了万人房间这么大并发的，必须应用分布式架构来扩散压力。如果一个万人房间散布在多台服务器上，那么服务器之间还要实时同步 Nx(N-1) 的用户状态和公布订阅关系，同时为了实现高可用，还须要反对某台服务器解体重启后的数据同步。
另一方面，媒体服务器个别会做成分布式网状架构来升高点对点的提早。但如果信令服务器也放弃每一个节点都平等的网状架构，那么每一个节点都要保护全量的级联关系。这其中盘根错节的音讯同步性问题将会极难保护。
网易云信分布式树状架构
为了实现高并发和高可用，联合信令都是在房间外部传递，房间之间不会有信令交互这一业务特点，咱们将信令服务器设计成分布式树状架构，每个房间是一颗独立的树，如下图：
- 根节点：房间治理服务器，治理和存储所有的用户状态和订阅关系。
- 子节点：作为边缘服务器，负责用户就近接入。
这种树状架构能够无效扩散各节点的播送压力。根节点会尽量依据就近用户的准则进行调配，防止其与子节点之间链路过长，同时子节点尽量只充当音讯 proxy，不参加业务，把业务集中到根节点上，从而防止信令的同步乱序等问题。
根节点应用缓存加数据库来保障业务数据存储的性能和可靠性。子节点因为不波及用户业务状态，在解体重启后，只须要客户端信令的长连贯重连，不必进行相似重新加入房间的操作，做到对用户无感知。在遇到子节点宕机的状况下，则会依附客户端的超时机制，从新申请调度。通过这一系列伎俩，实现服务的高可用。
信令弱网问题
在 RTC 架构中，因为信令十分多且交互简单，个别采纳信令和媒体通道拆散的策略。但这会引入一个问题，就是两者的抗弱网能力不统一。媒体个别应用 Udp 传输，很容易做到在 30% 丢包下仍然能流畅观看。但信令个别应用 Tcp 传输，30% 丢包下信令就根本不可用了。
为了解决这个问题，咱们应用 Quic 作为信令减速通道，来保障信令媒体的弱网反抗能力一致性。同时在 Quic 连不通时(可能存在用户网络对某些 Udp 端口不敌对)，也能退却到 Websocket，以此来保障信令在弱网下的高可用。
音频的技术难点
混音和选路的缺点
在多人连麦场景中，最简单的就是多个用户同时谈话场景下的音频并发问题。
假如万人房间中每个主播都上麦，因为语音的个性，每个主播实践上都要订阅其它所有人（视频能够按需订阅，但音频实践上应该全订阅）。如果每个客户端都订阅 N-1(9999) 路流，不仅仅是流量的节约，客户端也反对不了如此多的上行，而且在事实场景中，只有超过 3 集体同时谈话，其他人基本上就听不分明内容了。
解决这个问题的办法个别有音频选路和服务端混音两种。但在万人房间的场景下这两种解决方案都有所缺点：
- 音频选路是在 N 路音频中抉择音量最大的几路进行下发(个别 2~3 路)。这个计划的确可能解决上述问题，但它有一个前置条件：与客户端直连的边缘服务器上必须会集全量的音频流，这样能力选路。所以，即便是 48 核的服务器，也难以反对万路并发。
- 服务端混音是解码 N 路混成 1 路，或者选路之后再解码 3 路混成 1 路。前者的问题次要是 MCU 服务器很难顶住这么大的转码压力，而且耗时过长。后者还是会有上述音频选路的缺点。其实 MCU 最大的毛病是单点问题，解体后会影响全量的用户，很容易成为零碎瓶颈。
网易云信的分布式选路
为了解决音频的上述问题，咱们采纳了 在服务器级联之前预选路 的计划。假如一个万人房间均匀散布在 20 台边缘服务器上，每台服务器有 500 路上行流，如果不应用级联预选路，那么每台服务器相互级联后，都须要拉全量的 10000 路流能力供上行选路应用。
当咱们应用级联预选路计划后（默认 3 路），每台服务器只须要拉 3x(20-1) 路流就能够，之后再从本机的 500 路流加上级联的 3x(20-1) 路流中进行二次选路，选出最终音量最大的 3 路流下发给客户端。通过这种形式，实现音频的全订阅。假如在 M 台服务器上传输 N 路音频流，服务器传输数据量的数量级就从 N^2 降落到 M^2。
视频的技术难点
Simulcast/Svc 和码率压抑在大房间的局限
因为客户端性能限度，个别能同时解码渲染的视频流路数不会太多，能够通过“被订阅才发流”这种形式来躲避上述媒体并发问题。
万人房间的视频技术难点次要在于 QoS，RTC 中服务端的 QoS 伎俩次要有两个：
- 利用 Simulcast/Svc 切流
- 通过 RTCP 压抑发送端编码码率
Simulcast 和 Svc 的实质是将用户的上行带宽分层在散发对应的流，但在万人房间中，用户带宽往往散布很散，机械的分层并不能让大多数用户都有最好的体验。RTCP 码率压抑是依据接收端带宽反馈给发送端的编码器，编出最适宜的码率，其最实用的场景是 1v1，在万人房间中会很难决策。
网易云信 QoS 策略
为了让尽可能多的用户都取得匹配其网络的视频流，咱们制订了如下的 QoS 策略：首先咱们会依据上行带宽将用户从高到低分为 4 个层级，发送端同时应用 Simulcast+Svc 编码，例如 720p/30fps，720p/15fps，720p/8fps，180p/30fps，服务器依据用户层级为其调配对应的数据流。
这种办法的长处是可能实现每一个用户都能匹配对应其带宽的视频流，但有一个不言而喻的毛病，就是调配不够均匀。比方一个万人房间中，大部分用户的带宽都命中 720p/15fps 这一层，其它大量用户扩散在另外三层上，那么实际上这个房间大多数用户的视频体验都不是最佳。
为了解决这个问题，还须要在分层编码的根底上再联合 码率压抑：首先将用户的带宽依照从高到低排序，取 topN% 用户的最低带宽反馈给发送端，领导最高层级 (720p/30fps) 的编码码率，以此让 topN% 的用户都能命中体验最好的数据流。N 能够用户设置，也能够依据房间内用户的上行带宽状况动态变化。
下图以 Top60% 举例：
还有一种场景是当用户上行带宽有余时，假如只有 1.2M，根本无法实现 Simulcast+Svc。这种状况下，咱们会让客户端只编码一路 720p 的单流，而后在房间中引入一个 MCU，将单流转发给它，MCU 在转码时再应用 Simulcast+Svc，并回推给 SFU，以此来匹配咱们的上行 QoS 策略。
服务器之间网络传输的技术难点
跨运营商和跨国传输
理论开发的过程中，咱们还遇到了一些服务器之间网络传输问题，这里也和大家分享一下。
比方为了缩小最初一公里间隔，咱们会应用一些复线机房作为边缘节点，不同运营商的复线机房如果间接级联，他们的网络传输很显著是不可控的。想要从架构层面解决这个问题，就必须在级联网络中再引入一个三线 /BGP 机房作为直达，而这又要思考直达服务器的节点地位调配和单点解体问题，这样无疑大大增加了调度的复杂性。
另一种状况是跨国场景下的机器级联，服务器之间的公网路由不肯定是最优，抖动也可能十分大，两头一公里的网络齐全不可控。
WE-CAN
为了解决相似问题，咱们将服务器之间的传输模块形象进去，引入了本人的公网基建，大规模分布式实时传输网：WE-CAN（Communications Acceleration Network）。在寰球次要地区都部署节点，节点之间一直探测网络品质并上报，核心决策模块收到上报后综合运营商，实时网络品质，带宽老本等信息后计算任意两个节点之间的最短门路并生成路由表，再下发给各个节点作为下一跳的路由参考。WE-CAN 跟业务无关，齐全是传输层解决方案。通过这种形式，媒体级联只须要在包头打上指标地址，再投递给 WE-CAN，齐全不须要思考业务之外的传输问题。
总结
以上技术计划就是本次分享的全部内容，通过云信的万人连麦技术，将服务降级为无状态，不须要限度房间最大人数和同时上麦人数，并且反对程度弹性扩容，轻松应答突发流量，秒级匹配用户网络。
当然任何零碎的搭建都不是欲速不达的，其中每一个点，咱们都是踩坑有数。网易云信也将持续打磨音视频技术，给行业带来更好的服务。
作者介绍
陈策，网易云信资深音视频服务端开发工程师，负责云信寰球 RTC 网络的搭建和负责外围开发，在媒体数据传输和 RTC 全栈架构设计方面有丰盛的教训。
