近年来随着直播教育的兴起，人们对直播教育的体验感要求越来越高，尤其是在弱网环境下的听课体验显得尤为重要。在本次LiveVideoStackCon 2021 音视频技术大会 北京站，我们邀请到了来自好未来直播中台产品负责人 冯权成，为大家介绍好未来自研RTC是如何进阶演进的、以及如何经受住教育场景严苛的质量要求的。

文 | 冯权成

整理 | LiveVideoStack

大家好，我是冯权成，来自好未来直播中台，主要负责直播中台整体音视频产品工作，包含产品规划和产品团队建设相关工作。好未来直播中台的定位主要是给前台业务团队提供通用的音视频能力，比如RTC+RTMP标准直播+点播云等这些产品形态，以便支持集团前台业务的音视频需求。

本次分享主要是向业界介绍好未来在自研RTC（Real Time Communication，实时通信）领域所取得的技术成果和在教育场景的应用实践。众所周知，教育场景相比于其他场景，对音视频质量和稳定性的要求是非常严苛的，因为一旦出现线上问题，不仅仅是退费/补课时等经济损失，更有可能耽误学生宝贵的学习时间，毕竟学生的学习时间是不可逆的，例如一个正在备战高考的学生，一旦因为线上问题耽误一节课，他的复习时间就少了一天。

好未来从2018开始自研RTC，目前自研RTC已经承接60%以上量级，尤其是去年疫情至今，我们自研RTC经受住了海量并发和高可用的验证。接下来我们一起来看看我们是如何抗住这些挑战的。

此次分享的主要内容包含四个部分：第一部分：直播中台产品全景介绍，向大家介绍我们的全景音视频能力和产品矩阵；第二部分：TalRTC整体架构，会着重介绍好未来自研RTC的整体架构；第三部分：高可用及弱网对抗策略，主要介绍自研RTC的高可用和弱网对抗策略、如何用技术手段保障服务的可用性和稳定性、如何保障极端弱网环境下老师和学生的上课体验；第四部分：针对教育场景的特殊优化，最后分享一下针对教育场景的特殊优化，毕竟教育场景和其他场景还是有很多不一样的地方，比如说教育场景对音视频体验的要求要比泛娱乐/视频会议/电商直播等场景要求高得多，一方面学生都是付费用户，另一方面学生的学习计划是不可逆的，因此我们是怀着敬畏之心在打磨音视频的产品体验。

图：冯权成介绍好未来自研RTC

一、直播中台全景介绍

1.1 直播中台价值定位

直播中台是在好未来集团内成长起来的音视频中台，基于教育场景持续迭代打磨通用音视频能力，向前台业务赋能。我们通过适配层封装自研及其他厂商的方式，向前台业务提供音视频能力，其中自研放量占比已经超过50%。

这里补充一个背景，为什么需要同时封装自研和外部音视频厂商，这主要是出于成本、灾备、技术PK等多方面考虑，成本和灾备大家比较好理解，不做过多赘述。关于「技术PK」，我们的理念是这样的，如果没有竞争对手和你较量，你很难持续保持前进，好比练武之人没有对手和他比拼，他很难知道自己的弱点或者自己的水平怎么样。其中自研部分主要包含：自研RTC、RTMP标准直播、点播云等音视频能力。

直播中台支持的前台业务有网校、培优、学而思1V1等业务线，覆盖了大班、小班、1V1等课堂形态。此外还支持了内部的IM办公软件「知音楼」的音视频通话/在线会议等应用场景。

1.2 直播中台音视频能力整体架构

围绕RTC这一核心产品，衍生出了全场景的音视频产品矩阵；

先说RTC产品，支持标准WebRTC协议及自研私有协议，也就是支持Web端及Native端，其中Native端支持移动端Android和iOS，PC端支持Windows和macOS，此外还支持Linux服务端（方便业务方拉流去做进一步处理，比如本地服务端录制、AI审核等）。为了提高业务对接效率，也支持一些前端框架SDK，Unity（C#）、Electron（JavaScript）、Flutter（Dart）。

为了支持大班课大规模观看的需求，我们搭建了支持标准CDN直播协议RTMP/FLV/HLS的标准直播。通过RTC的媒体服务器将RTC流转码为RTMP流，旁路推流到RTMP标准直播源站进行分发。RTC的录制和标准直播的RTMP录制文件会自动上传到点播云进行处理；点播云对视频进行二次加工，比如媒资管理、拼接、云剪辑、裁剪、截图、水印、转码等其他相关的媒体处理，便于学生课后观看回放复习或者做教学内容的二次剪辑推广。

1.3 直播中台RTC能力整体架构

整个直播中台的RTC能力是部署在IaaS层计算资源的基础上的，IaaS层使用了云主机+线下IDC物理机的组网方式，使用IDC物理机的原因是网络质量、线路质量有保障、物理机的算力和性能更好，这部分资源作为兜底资源，而云主机主要是为了应对量级变化时可以快速弹性伸缩，当线上的用量有突增时用云主机快速扩容，当线上用量下降时用云主机快速缩容。为了应对量及突发时达到快速弹性伸缩的目的，我们在此基础上构建了一个可视化管理后台，能够高效的通过可视化页面的方式快速弹性伸缩，目前能够实现分钟级扩容/下线上百台机器，针对线上用量做精细化管理，保障线上稳定可用的同时做到精细化成本管理，降低业务成本。

1.4 直播中台产品全景图

这张图是直播中台的产品全景图，我们可以看到从底层的音视频服务端+客户端SDK；再到中间的调度管理、负载均衡、房间管理、后台管理系统、云控配置下发以及引擎切换相关的系统。

最上层是对外提供标准化产品服务的官网和开发者中心，方便前台的业务高效、便捷地使用我们的产品和服务，提高业务对接效率。

右侧是一套服务支撑以及保障系统，比如驾驶舱管理系统，主要负责实现弹性扩容、引擎切换、云控配置下发等功能；其中需要重点谈一下云控配置下发功能，云控配置下发是为了解决什么问题呢？因为客户端SDK发版具有一定周期性，且SDK发版后需要终端用户升级后新功能才能生效，不便于新功能的灰度和全量推广；云控配置下发可以在SDK不发版的情况下将一些新功能、新特性、调度策略等配置下发到客户端。

告警系统主要是基于全链路的质量监控进行异常行为告警、便于研发和运维同事及时处理线上问题，将问题消灭于萌芽阶段，避免问题的影响面扩大。

全链路质量监控系统，主要监控全链路的QoS/QoE的质量和体验指标、比如五大指标（入会成功率、延时、卡顿、音画同步、端上性能开销）和服务器资源水位监控，通过可视化的管理页面，配合上面提到的告警系统，实现及时的针对异常情况进行提前干预和保障。全链路质量监控还有另一些比较重要的功能，比如根因分析，技术支持同事可以通过根因分析系统快速定位问题，从而解决用户反馈的问题。

日志埋点管理系统，主要负责将埋点流程系统化，通过可视化系统的方式去新增或管理埋点，规范埋点流程。最后再基于埋点日志，做日志分析，大数据的分析计算，给上面提到的这些服务质量保障系统提供数据支撑。

二、TalRTC整体架构

2.1 好未来自研RTC架构

接下来介绍好未来RTC的整体架构，大概分为三层。

第一层，SDK终端接入层；

第二层，业务服务器层；这一层有IPLocation（调度服务器）

RoomManage（房间管理服务），RECMGR（录制管理服务），HeartServer（心跳服务）；

第三层，流媒体服务器层。

整体接入流程是这样的，终端SDK通过DNS调度到负载均衡服务器集群，之后负载均衡服务会给终端SDK分配一台最优的调度服务器（IPLocation）；调度服务器会告诉客户端去连接最优媒体服务器，客户端和媒体服务器建立起连接后，首先开始信令交互（SignalGW）,然后开始音视频数据的传输。

媒体服务中SignalGW主要负责包括入会退会或者相关信令的通知，Record负责录制服务，Audio负责音频的转发，AudioMix负责音频混流，Video负责视频的转发，VideoMix负责视频混流， LocalLog负责本地日志落盘。Convert负责转推到CDN，将RTC转成RTMP推流到CDN进行大规模分发，例如在线大班课，需要百万千万级并发同时在线观看。

最右边的分布式缓存系统，用于缓存业务服务器相关的数据，如业务服务器的资源情况、可用服务器的状态、健康度、链路探测质量等，调度服务器根据上述信息进行调度。后台管理系统就是我们前面提到的服务质量支撑管理系统，这里不再赘述。

2.2 终端接入流程

接下来我们看一下终端SDK的接入流程，支持域名+IP的调度方式，当域名解析不通时走IP方式（作为兜底）分配服务器。客户端通过DNS或者IP调度到负载均衡集群，负载均衡服务器会给终端分配最优的调度服务器，调度服务器会根据Redis集群存储的信息给客户端分配最优媒体服务器，Redis集群存储的信息主要有：媒体服务器资源水位情况、健康度情况（实时探测，服务器自身负载，以及链路的丢包、延迟、RTT等链路探测信息）。

2.3 SDK架构

SDK架构，最上层是API层，将音视频能力通过API的形式暴露给业务层调用；API层之下有房间信息、用户信息以及配置信息。

最重要的是「音频引擎」和「视频引擎」：

音频引擎包含了音频设备管理、音频的处理、输入外部音频源（输入外部PCM数据，伴奏混音等）、opus编解码器、媒体传输通道的管理、netEQ弱网对抗（JitterBuffer+解码+信号处理），netEQ包含对抗网络异常丢包和抖动的机制和策略；

视频引擎包含了视频设备管理、视频的处理、输入外部视频源（输入外部YUV的数据，桌面共享、视频自采集等）、编解码器、媒体传输通道的管理、netEQ（JitterBuffer+解码+信号处理）。

右侧的信令模块主要负责房间消息管理、mute和unmute等管理，日志采集模块，以及本地录制、推流到CDN的模块、拉流器等模块。拉流器是RTMP拉流器，因为我们的SDK提供两种模块组合，一种提供方式是纯RTC模块，另外一种方式RTMP模块+RTC模块，方便业务根据业务场景进行自由切换。

三、高可用及弱网对抗策略

3.1 RTN调度-节点分配策略

RTN在给客户端分配媒体节点时，会根据三个信息做节点的分配。第一，是地域；第二，运营商；第三，大数据的分析。其中大数据分析会实时探测服务器链路间的丢包、延迟、RTT等信息，得出最优链路。调度服务器根据上述三个信息找到可用服务器后，以负载均衡的方式，把请求均匀得调度到不同的服务器上，会分配就近接入节点（不是物理上的最近，是逻辑上的最近，即最优节点）、备用节点、兜底节点，当最优节点异常时，客户端可以在秒级内自动切换到备用节点，保证用户端无感知。这里的就近接入不仅是距离上的就近，更主要是基于延时以及基于丢包来计算，延时最低、丢包最少的就是最近的。

3.2 RTN调度-路由策略

路由策略会根据3个信息来做路由，第一，路径最短；第二，延迟最低；第三，丢包最少。基于上述三个信息，选择出可用路由，经过负载均衡，选出最佳路由节点，同时选一个作为备用路由节点，当最佳路由节点不可用时，客户端可以在秒级内自动切换路由，保障用户无感的情况下，完成切换工作，从而实现高可用地保障用户体验。

3.3 单点&同运营商、多点&跨运营商调度

RTN的调度系统目前有多种调度方式，支持单点、多点、同运营商、跨运营商等调度方式。

单点和同运营商调度比较简单，客户端向调度服务器请求媒体节点，调度服务器向客户端分配同地区、同运营商的媒体节点。

跨地区、跨运营商的调度相对复杂一点，如北京移动的学生要跟上海电信的老师进行1V1通话，调度服务器会分别给北京移动的学生分配北京移动的媒体节点、给上海电信的老师分配上海电信的媒体节点，北京移动媒体节点和上海电信媒体节点之间通过上海多线媒体节点进行转发。

跨运营商及地区的情况也类似，首先根据客户端所属的运营商来给他分配最近区域同运营商的媒体节点，再通过多线节点做级联转发。

3.4 业务异常恢复

客户端首先向调度服务器请求最优媒体节点，业务服务器的心跳服务，会定期上报媒体服务器的心跳，如：服务器可用资源、水位、服务器健康度、负载情况、丢包、延迟、RTT等信息，调度服务器根据这些信息来做调度。

高可用主要是依赖服务的自动自愈来实现的，目前整个RTN服务器有80+多个自愈case，这里列举三种加以说明，第一种是支持断网重联的机制，客户端断网，网络恢复以后自动重联。第二种是SDK支持切换服务器，SDK通过调度服务器获取主节点和备用节点，当主节点不可用时可自动切换到备用节点，从而保障终端用户无感知，不会影响老师和学生的上课体验。第三种是兼容TCP和UDP，就TCP而言，弱网的情况下连接的成功率、连接的到达率会受到影响，TCP当丢包率10%左右时就已经不可用了，而UDP至少可以抗30%以上丢包。我们目前所有服务都兼容TCP和UDP，比如当TCP不可用时，会通过UDP的方式去做通知或广播，提高弱网下抗丢包的能力。

3.5 媒体节点异常恢复

媒体服务支持功能模块的进程守护机制，保障功能模块不会假死或发生其他问题，支持故障自愈逻辑。之前提到的会自动切换到备用节点，其实就是一种故障自愈的逻辑。

接下来我们针对不同场景分析一下异常恢复逻辑：

首先，先看一下单线媒体节点异常恢复逻辑。电信用户A和用户B进行1V1的音视频通话，开始时电信用户A连接电信节点1，电信用户B连接电信节点2，电信节点1和电信节点2建立起级联连接，在双方通话过程中电信节点1机房突然出现网络故障，此时会自动启动节点切换逻辑，电信用户A 的客户端会自动切换到备用节点电信节点3并与其建立连接，电信节点2和电信节点3之间建立级联连接，保障平滑切换链路，整个切换过程终端用户无感知。

接下来再看一下多线媒体节点异常恢复逻辑，多线的逻辑也是类似的，假设电信用户A和联通用户B进行1V1的音视频通话，由于跨运营商，所以需要三线节点3做转发。假设双方通话过程中，三线节点3所在的机房网络故障，电信节点1和联通节点2会自动切换到备用的三线节点4，与三线节点4重新建立连接，从而保证双方音视频通话不受影响。

3.6 SDK弱网对抗策略

SDK目前支持SVC分层编码，支持两种分层逻辑。

第一种逻辑是传统意义上的SVC，支持时域分层，共分为3层，其中基础层帧率最低（5-6fps），中间层帧率居中（10fps）,最上层帧率最高（15fps）；每一层均能被独立解码播放，因此即使上层丢失了，之下的层级还能够被正常解码播放，媒体服务器的「下行状态统计决策控制器」可以根据接收端的网络评估情况做相关决策，通知SVC过滤器给接收端转发与之网络情况匹配的媒体流，从而降低卡顿率。

另外一种分层编码逻辑是大小流的逻辑，大流和小流通过一路流，在编码时一次性编码了两种分辨率。同样的，媒体服务器根据接收端的网络评估情况做决策，决定给接收端转发大流还是小流，通过媒体服务器的SVC过滤器进行转发；当网络质量正常时转发大流，比较差的时候转发小流。这两种分层编码逻辑由「SVC Controller」控制采用哪种逻辑，下边分程编码及RTP/RTCP协议的打包，接下来经过NACK重传和FEC前向纠错，最后经过「Pacer Sender」平滑发送，保证在网络抖动比较厉害的时候，能够匀速地发送数据。

如果横坐标表示时间，纵坐标表示发送的码率，画出来一条线应该是趋近于水平线，保证发送码率是恒定的，接收端才能流畅拉流播放。媒体服务器中有一个比较重要的模块就是「下行状态统计决策控制器」，该模块会根据接收端REMB模块评估的带宽情况来决策，通知SVC过滤器给接收端转发适合接收端网络条件的媒体流。当接收端带宽资源过剩时，向其转发高帧率、高分辨率的流；反之则会向其转发低帧率、低分辨率的流。

此外，接收端还有一个弱网对抗模块JitterBuffer,该模块为接收端缓冲区，负责对数据包的丢失、延迟、乱序等情况进行处理，配合NACK重传，从而实现抗丢包，降低弱网环境下的卡顿率。

AVsync模块主要负责音画同步，保证音视频通话的体验。

四、针对教育场景的特殊优化

4.1 优先拉“老师流”策略

教育场景下无论大班课还是小班课，学生上课的时候最关心的肯定是老师的流，其他学生的动作，学生本人关心程度相对较低，所以，老师的那路流需要重点保障。

优先拉老师流的架构如上图所示，为了作为对比，我们先说一下之前没有优先拉老师流策略的架构，右侧这个橘色的多路媒体资源控制器是没有的，因此每一路流都是独立的，N路流的带宽评估是独立评估，当学生端的带宽资源有瓶颈时很难保障学生拉所有流都不卡。

有了统一带宽评估策略，把多路流消化的带宽做统一评估，从流1到流N所有消耗的带宽，由右侧这个多路媒体资源控制器去做统一评估，得出接收端带宽资源最大能够拉多大码率的流，如果带宽不足以拉所有流的话，就优先保障老师的流，最大限度保障学生的上课体验。

4.2 推拉流的回退策略

在一些弱网的场景下，学生要拉多方的流，或者说即便只拉一方的流，音频和视频两路流都要拉的话，在极端弱网情况下是很难保障流畅性的。TalRTC的回退策略是当网络比较差的时候，接收端的REMB负责带宽评估以后，会将评估数据发送给流媒体服务器，如果认为当前学生端的网络情况不能满足拉视频大流时，会通知回退控制器，回退控制器又通知转发过滤器，先回退到只转发小流，如果接收端的网络条件还是不满足拉视频小流，会进一步回退到纯音频。

这样能够保障在极端弱网情况下，学生即使不能流畅看老师的视频，至少还能够听到老师的声音，不会错过重要的知识点，最大限度地保障了学生的上课质量。

4.3 基于AI的音频3A算法—AI_AEC。

大家都知道，音频前处理的3A算法是实时通信里很重要的一种技术，音频3A算法保证了实时互动时的音频质量：语音清晰、没有噪音、没有回声、声音大小合适。

然而，传统的3A算法存在一些问题，比如对非线性回声消除不干净、对非平稳突发噪声抑制能力差。针对当前的业务痛点，直播中台与集团AI研究院合作，将AI算法与实时音视频的技术结合起来，创新性的将AI算法用于音频3A优化中，显著改善了传统音频3A算法的不足。

基于AI算法实现的噪声抑制，目前主要支持一些特定场景的噪声抑制，例如老师或者学生在家上课的时候，环境中其他人发出的咳嗽声、开关门声、敲键盘声、或者临街环境有汽车鸣笛声等，对于这类非平稳的突发的噪声用传统的降躁算法是很难消除干净的，而基于特定场景训练的AI模型就能够彻底将噪声消除干净。