URTC万人直播互动实践之路

本文由UCloud RTC首席架构师王立飞的线上分享内容整理而成。详细介绍了URTC万人直播互动的架构设计与难点，在研发、业务应用和产品迭代过程中的架构演进与考量标准。

文 / 王立飞

整理 / LiveVideoStack

大家好，我是王立飞，目前在UCloud负责RTC的架构以及优化，本次分享的主题是URTC在万人直播互动场景下的实践与优化经验，主要从万人直播互动难点、URTC架构设计及实践、URTC产品介绍这三个部分展开：

1. 万人直播互动难点

万人直播互动的难点有很多，其中大家经常遇到或普遍关注的主要有四个问题：大流量、读写扩散、高并发以及用户分布。

大流量：实时互动本身就是一种大流量的数据交互活动，而万人直播则是在小规模直播互动形式的基础上进行了万级别的末端放大或中间链路的放大，因此其数据流量是非常庞大的，尤其是在拉流端。

读写扩散：RTC在控制层面（信令层），每个人的操作都可能会被放大至万倍甚至十万倍。在转发面（数据包转发），边缘节点以及核心节点流量又将会被放大多少倍？

用户分布：用户分布是多人实时活动中比较常见的一个问题。用户分布于全国各地，面对不同的运营商、不同的网络质量，就近接入该如何为每个用户提供更优质的观看体验。

2. URTC架构设计及实践

接下来我主要讲一下针对上述难点，我们设计了一个怎样的URTC架构，为什么要这么设计架构，URTC产品在线上运维过程中所遇到的问题以及如何解决这些问题。

2.1 URTC架构设计

URTC系统架构如图所示，我相信大道至简，架构应该明确清晰，每个子系统应该简单高效，因为简单的东西更容易稳定，更容易维护，同时更容易产生更大的性能飞跃。

第一个是RTC核心业务集群，承载的是RTC的信令控制以及RTC实时互动数据转发的核心功能。

第二部分是转码录制转推，在RTC核心业务集群之上，完成的是整个RTC 实时画面合成和转码的工作，CDN转推以及云端录制保存。

第三部分是支撑业务，包括监控、计费、接入以及增值业务四个模块。监控部分是针对线上服务运营情况的监测，方便我们与用户定位问题并优化产品。接入服务主要负责用户的就近接入以及负载均衡。

2.2 URTC设计准则

我们系统的设计原则：微服务、极简设计、普通化。

微服务：这个是一个很普遍的设计原则，这里不再赘述。

极简设计：首先，URTC系统中所有的功能都进行了系统的拆分，单一的系统只实现单一的功能。其优点是更方便后台研发人员熟悉整个系统，进行单一功能的优化。其次，系统可以做到单独发布、验证，这对于整体灰度来说是非常好的体验。

普通化：普通化对应的主要是减少硬件依赖、减少系统依赖，这也是大家经常会忽略的地方。例如许多开源系统软件涉及功能繁多，像RTC的SFU服务、MCU、画面合成以及录制转推可能都在一个系统中，这会带来许多各种各样的问题。我们可能需要一个64核 128G内存 1T硬盘 1G带宽的机器配置，在系统扩容的时候这将会非常受限，没办法很快地找到系统的替代品是一件相当危险的事情，因此在系统设计之初我们要极力避免这种高度依赖资源的行为。

2.3 URTC的实践

URTC的实践是我们线上运维过程中的一些心得，主要分为四个部分，涵盖了RTC整个交互链路，从调度、推流、分发到拉流业务功能的业务闭环。

2.3.1 URTC实时调度

实时调度最大的一个目标即实现负载均衡，将流量分散。其次是就近接入，为用户选择最优质的节点进行调度。而最容易被忽略的则是流量隔离以及分区保护两点。流量隔离是指服务器或者用户的业务可能会受到攻击和流量暴增，此时我们需要对存在问题的区域进行流量隔离，以降低风险。分区保护是指可能存在部分用户对分区有一定需求（如活动产生的流量暴增），此时可能造成系统的不稳定，就需要对这一特定区域进行隔离，单独进行容量扩容，同时保证不会对其他用户服务产生影响。

2.3.2 URTC推流接入

推流、分发和调度是RTC中通用的链路过程。在实时交互的过程中，推流是非常重要而又脆弱的一个环节。假设一个拉流点存在问题，它只会影响某个观众的观感，而推流端影响的则是所有观众的体验。因此在推流端一定要保证接入质量的稳定，以及链路容灾的备份。

推流相对于拉流来说不会呈几何倍数的放大，我们可以在推流端进行一些优化工作。推流端接入通过HTTP DNS进行分区后，分区会给我们的SDK分配三个接入地址，然后进行动态的Ping速。在此基础上我们做了进一步的优化，针对大运营商，我们将最快历史接入地址保存下来，以便于用户快速接入、提升用户体验。

2.3.3 URTC源站保护

多路径接入：推流的边缘节点由多个接入点作为备份，如果一个点发生故障，推流端可以通过另外的节点继续进行推流，中断切换影响最多仅有秒级别。

多路径传输：从边缘点到路由节点，路由节点在每个区都会有节点，以防止其中一个路由节点崩溃，流量可以迅速迁移到另外的转发节点，保证推流端不会发生长时间中断。

适当冗余：在推流端可以进行适当冗余。冗余的方式有很多，例如在用户到边缘节点可以采用FEC或者多发的策略进行数据的冗余上传，在边缘节点到路由节点也可以进行适当的冗余传输，以降低整个RTC的延时。

2.3.4 URTC分发优化

许多公司都有智能路由的路由转发系统，我们的智能路由系统在国内设有华东、华北、华南等几个路由节点进行各个区域路由转发的操作，同时也可进行几个节点间的灾备。路由节点的链路依旧要进行适当的冗余，链路一般会选择最优路径以及次优路径作为传输路径。延时、丢包是其中比较关键的衡量指标，跳数与成本两项指标也会占有一定权重，综合计算得出一条最优路径。所有的数据包经过路由转发后都会通过最优路径优先到达另外的边缘。次优路径则会作为灾备或最优路径变差情况下暂时性的链路传输，以便后续再次传输时筛选新的最优路径进行传输。

UCloud的数据中心是有专线进行互联的，在某些地点，例如跨洲际的中美之间的互通，我们都是通过专线来保证重要数据的传输。在国内也是专线和公网作为链路灾备，同时几个节点间的智能路由管理作为分发网络。

2.3.5 URTC拉流

万人直播系统中除了推流端是脆弱的优化点之外，拉流端也是优化最多的地方。其中常见的问题有以下几种：

第一，用户的网络是不对等的，要解决不对等网络下用户的体验。

第二，万人直播互动中，端上的解码性能可能会遇到瓶颈。在同时接收和解码多路码流时，由于移动端解码能力有限，可能会导致用户体验骤降。

第三，万人直播在末端流量会存在万倍的放大，那么如何优化流量的放大比？实际上我们无法在末端进行优化，大量的用户使得每台服务器都会承载一个放大比，我们能做的更多的是在路由节点与核心转发之间通过几倍的放大比使得末端达到完整的流量共享。

第四，在系统达到极限的情况下，应该通过柔性的降级使得用户的实时交互正常进行。

用户网络不对等

用户的位置、网络运营商、网络（4G/WIFI）千差万别，而远端推流来源相同。针对这种情况，在Web端常用的解决方式为多播，压力主要集中在推流端上传，需要编码多路流上传（常见的是一路高质量流和一路低质量流）。用户端只需要根据自己的实际情况选择相应质量流完成下发，以此达到不同用户可以享受不同的用户级别。在Native端更多采用的是分层的编码。

解码性能

在互联网中用户大都使用的是分辨率较低的场景，因此解码性能的应用比较少。但在传统领域例如教育、金融，对于清晰度的要求则会相对较高。假设在17人连麦的场景中，每个链路的带宽按1M计算，每个人要拉取17路流，这就需要17M的下行网络带宽，并且每个用户还需要解码17路 720P的视频。对于使用较稳定的有线网络以及性能较好的PC设备的用户来说没有什么问题。但对于4G网络，低功耗移动端设备用户来说 17路 720P无论是带宽还是解码性能都会成为瓶颈。此时多播无疑是更好的选择，我们可以通过转发低质量的码率供移动端用户享用，高质量的码流供PC端、有线网络用户享用。

在产品中更好的优化方式：在有主持人的会议中，可以让主持人动态选择主讲人的画面为高质量画面，其他人使用低质量画面。或者在自由讨论的模式下所有人都应用低质量画面进行沟通，这样对于交互的实时体验会是均衡的结果。当然我们也可以选择MCU，但是在互联网规模级别的视频会议和实时沟通中不太现实，硬件的成本会特别高。通过多播加SFU的场景策略优化，可以很好的达到MCU的效果，同时可以节省流量以及硬件成本。

流量优化

在万人直播场景中流量在最末端会被放大万倍，假设用户分布在不同的服务器中，如果说没有路由节点使用的是传统的桥接模式，源站会被路由节点瞬间上万路的拉流，每一路假设有500K ，就已经被放大了1万倍。而加入路由节点的好处是我们可以在路由节点之间进行流量的转发。路由节点下面的所有码流针对源站只需要拉一路流，在每台服务器上用户去共享这路流，核心路由的节点的流量不会被放大上万倍，同时可以很好的保护源站的回源质量，保证下端算法的更好应用，为拉流端的最后一公里提供更好的视频观感。

其实服务器的架构有很多种。最常用的是用户通过一台服务器来服务一个会议，每个会议分布在不同的服务器上，调度方式是主讲人（管理员）定位整个会议室。如果会议的规模较大，服务器的配置要求高，替代品较少。服务器一旦崩溃，庞大的数据流量很难进行迁移。

第二种，应用相对较多的是桥接模式，边缘节点之间进行桥接。假如我们的源站分布于100台服务器，源站会同时被100台服务器拉流，放大比为100倍。假设在源站上存在100个主播同时推送，源站的下行压力会非常大，而且每一路源站的回源质量会非常差，反而会破坏下行的观看体验。

第三种，源站推流到转发中心，再由转发中心通过合并回源进行边缘的流量下发，在最边缘承载更多的用户量，同时转发中心可以完成智能路由，故障转移方案。