共计 7168 个字符，预计需要花费 18 分钟才能阅读完成。
几年前，很多人对在线网课还十分生疏。随着挪动设施的遍及和音视频技术的倒退，现在在线教育产品百花齐放。而在线教育产品能服务千万学子离不开流媒体散发技术的撑持。本次 LiveVideoStackCon
2021 音视频技术大会北京站邀请到了网易有道研发工程师周晓天，为咱们分享网易有道在线教育业务的流媒体散发相干内容。
文 | 周晓天
整顿 | LiveVideoStack
大家好，我来自网易有道精品课研发团队。现在音视频被各界宽泛关注，“直播 +”成为一个热点，大厂也纷纷推出了一系列音视频的相干服务。
网易有道是一家 以成就学习者“高效学习”为使命 的智能学习公司，依靠弱小的互联网 AI 等技术手段，围绕学习场景，打造了一系列深受用户喜爱的学习产品和服务。除了面向多种场景的在线教育平台，还有有道词典、有道词典笔等当先市场的软硬件学习工具。
其中在线教育业务就是依靠音视频技术的一直成熟应运而生的一项重要业务。
音视频技术内容广、链条长、每个点又会很深。所以明天分享的内容以有道的在线教育业务为主题，聚焦在有道团队流媒体散发服务端的局部。
明天的内容分为三个局部，别离是有道在线教育业务介绍、散发零碎架构的演进和对散发难点的思考与实际。
1. 在线教育业务介绍
首先通过在线教育直播业务状态了解需要，明确媒体散发服务端要思考什么。
不同班型对应着不同需要。2013 年左右最先呈现的是 1V1 课程、一般小班课。实质上是借助 RTC 实时通信模式构建的教育产品。起初游戏直播和娱乐直播被大家相熟，而这个阶段被熟知的在线学习的次要模式是视频点播模式，比方网易公开课。随着音视频畛域技术成熟，以及用户对在线教育需要的降级，直播网课迅速倒退。直播课大概呈现在 2014 年，在疫情后失去了空前的关注。
传统大班直播课是老师的单向推流，在互动大班课中，学生能够和老师进一步互动，取得更好的上课体验。学生连麦、屏幕 / 白板、老师视频和互动音讯形成一节课的次要内容。
互动小班进一步优化产品的互动性，晋升学员课堂参与感、学习体验与学习效果。音视频 +H5 互动组件 + 灵便的布局需要也带来额定复杂性。
面向业务设计服务，须要了解不同业务的差别再去采取相应的技术。这里提供一种思考的形式：以互动大班课为例，一个老师和一个学生正在连麦，再将连麦的过程分发给其余学生。对于流媒体散发，右侧列出一些思考的因素：须要什么水平的提早和流畅性？多大的规模？须要多高的媒体品质？以后业务线对计划老本的敏感度？
进一步能够用这种形式横向比照不同课程状态，通过它们的区别取得更精密的需要。
比方，比照大班直播课和互动大班课：对于规模为 M 的会话，大班直播课要把一个人的信息分发给 M - 1 集体，这能够通过基于 CDN 的视频直播形式做到。如果进一步想要给产品增减少连麦互动性，成为互动大班课。连麦的减少会让简化模型变为两个局部，如何在一个教室内同时满足这两个需要？最简略的思路是在原有 CDN 散发的根底上，让连麦内容通过 RTC 形式替换，再将它们的信息通过原有 CDN 零碎散发，但这么做会带来内容提早和用户切换提早等问题。
比照互动大班和（线上、线下）双师班级，尽管模型相似，但具体到场景中双师班级中的一个“学生端”可能对应一个线下教室的全体学生，这会减少单路散发异样的代价，这样的差别也就要求零碎能对不同场景配置不同策略。
除了在线教育，横向比照的思路同样能够用来剖析其余场景的业务线，例如一般小班和游戏开黑。开黑看似和只发送语音的一般小班课程相似，然而在性能和网络占用方面要求更严格。在尽量不占用游戏带宽的同时，还须要尽量减少 CPU 的操作，为游戏提供短缺的算力。如果间接用小班课程的 RTC 接口用于游戏，保障通话质量的同时反而会影响游戏。如果冀望应用一套零碎反对多种业务，那么在零碎设计晚期就要明确业务差别和设计需要。
通过以上的剖析，能够列出了在线教育业务对媒体散发零碎的一些次要需要点。第一要满足散发低提早、上麦低提早。第二点要做大规模散发。绝对一些娱乐场景，要做到高稳固以及高可用。第四点要对老本进行管制。最初，不同学生、不同教室对于上课场景的需要是不同的，所以肯定要反对多端接入。
2. 散发架构的演进
当多个业务线同时铺开的过程中，从 1v1 到小班、到大班直播、再到互动大班以及互动小班等课程，这会影响散发零碎的演进过程。一种思路是随着业务的演变，散发架构逐步简单，一直反对越来越多的个性。有道并没有采纳该思路，而是经验了从基于 CDN 的散发，到全副业务应用实时通信网络（RTN）的切换，没有架构上的两头过渡状态。
上面咱们简略回顾一些散发架构作为遍及内容。
基于 CDN 网络的直播内容散发的树状架构非常清晰，架构自身决定数据的路由，同时易于保护、危险和老本可控。当一个用户选定一个边缘接入，媒体数据的散发路由就曾经布局好了。同时它有本身的毛病，比方：只反对单向散发、协定带来的固定提早等。
晚期通过 CDN 模式部署的直播为了减少互动性和升高提早，在 CDN 架构的根底上做了两个优化。一方面在边缘拉流节点反对 RTC 的形式接入（图中也写为 RTN 边缘节点），从而屏蔽掉媒体封装协定带来的提早、减少 IM 互动成果，同时还能减少弱网抗性。另一方面为了进一步减少互动性，减少了 RTC 旁路零碎以反对双向连麦，再将连麦内容转推到 CDN 网络中实现直播。一些“低延时 CDN 直播”产品就采纳这样的原理。
刚刚提到用于连麦的旁路 RTC 零碎须要转推内容到 CDN 散发网络，那是否能让这个零碎把 CDN 大规模散发的工作也一起做了呢？于是就有了纯 RTN 的架构。该架构不再有显明的树状散发构造，而是用一个网状拓扑散发所有内容。任意单向拉流客户端能够随时切换为双向通信，不须要先做零碎的切换。
通过上述的剖析，咱们能够大抵总结出业内直播流媒体散发演进的方向——音视频直播 CDN 和 RTC 网络边界含糊，逐渐融为一体。直播 CDN 厂商逐步从单向大规模散发反对低提早接入、连麦。之前的 RTC 产品，从面向小型会议的架构逐渐为了可能同时服务千人、万人，也开始将散发网络变简单。所以当初咱们能看到网易的 WE-CAN 分布式传输网、阿里云 GRTN 流媒体总线、以及其它“X-RTN”都是该演进过程的后果。
刚刚提到的架构次要是 ToB 厂商的产品，在 ToC 服务的场景中也会有如上图所示的架构，通过一个媒体服务器交融两个散发网络提供服务，特地是对于同时有自研和三方接入时。该构造在带来新的非性能个性的同时，也有很大的危险。有道没有抉择应用相似的架构进行适度，而是间接用 RTN 散发网络对原有性能进行代替。
该架构能满足多种场景的需要，也反对多种推拉流客户端接入。例如当同学上公开课时，通过微信小程序或者浏览器间接看是最为便捷的。曾经应用课程 APP、曾经加入系列课程的用户，应用 APP 接入以取得最优体验。
相比 CDN 架构本身的拓扑构造决定了数据散发路由，RTN 网状拓扑在带来灵活性的同时也减少复杂性。比方路由无奈从拓扑间接获取，而是须要一个额定的调度核心去计算、布局路由，实现对应转发资源的调度，这也凸显了 RTN 架构下调度核心的重要性。
图中也有一个 CDN 旁路的局部，他的次要作用是做一些突发接入量过大的课程的负载平衡，减少零碎的弹性。
有道在设计网络节点拓扑的时候更偏差于灵活性。一方面，散发节点没有分层、分级，采纳扁平拓扑。另一方面，通过配置不同的属性、角色能够实现对网络散发个性的扭转。
3. 散发难点思考与实际
对于流媒体散发零碎有以下四个要点——接入问题、网络连通性、路由建设以及转发。除此之外还想分享一下对于分层设计和通道的概念。
解决接入问题的核心理念是“就近”接入——网络品质最好的接入为“最近”的接入。（不同类型的业务可能会有不同思路：有道的教学场景中力求现有每个用户体验尽可能最优，相似于贪婪算法；但在别的业务中，思路可能会是在达到 QoS 最低限度的状况下抉择全局老本最优的接入、路由形式）最直观的办法是应用基于 IP、地位的接入举荐。进一步利用对不同网关网络探测、连贯历史数据优化举荐的后果。除了利用线上、线下数据统计取得的先验的常识进行接入举荐，思考到这样的办法无奈涵盖所有非凡形况，有道还引入人工配置的反对。反对手工热配对局部 ToC 场景十分无效
右下角是一个大班课老师上行丢包率打点图，能够看到存在有法则的、均匀在 9% 左右的丢包。该老师长期在固定地点应用固定设备进行直播，而且晚期还有技术支持同学进行过网络查看，网络始终很好。依照之前的算法，他的地位没有变、网络没有变，应用的举荐数据库也变动不大，所以依据算法每次会给出雷同的举荐后果。忽然呈现的有法则丢包揣测是流量行为被运营商辨认、分类，并对其进行了策略限度。
面对这种状况，批改算法是行不通的。通过有道热配置的形式，在发现问题进行上报的同时就能够人工批改配置，下一次老师接入会避开对应接入节点，解决丢包问题。
咱们通过“过滤器”机制实现该操作：如果所有可接入节点形成一个池子，那么最终“过滤”出的后果形成举荐给客户端进行接入的列表。所以把过滤规定的计算过程作为算法写入零碎，将算法执行要应用的参数作为能够热更新的数据写在数据库来实现。
接入只解决了散发网络的入口问题，那么散发网络到底是怎么的拓扑状态呢？这就波及到网络节点的连通性设计问题。有道的网络是一个扁平的拓扑，每个机房都是拓扑中扁平的点。实践上能够给所有节点之间都建设连贯，成为一个 mesh 网络，那么这样的网络将会无比灵便，任意一条通路都能够被布局进去，齐全依赖算法进行理论路由的抉择。有道并没有采纳这样的形式。
咱们还是引入了一些人工教训，比方依据教训将一些机房的连通性删除，成为非 Full mesh 的构造。能够认为是借助人工的形式进行了剪枝、组织。除了连通性，在路由计算时还须要解决权重的获取问题，也就须要对节点连贯状况差别进行量化形容。这种量化是基于规律性的 QoS 探测实现的，相似后面接入抉择的问题，算法可能没法精密地满足所有 case 或者一些非凡状况，那么在量化差别外，咱们也通过可配置的属性形容定性的差别来减少拓扑的灵活性。
之所以这样进步灵活性、反对人工配置，是为了能满足不同业务的差异化需要。同时也有代价，就是复杂性的进步。所以或者没有最好的架构，只有更适合的架构。
在确定了接入地位（明确了散发的终点和起点）、建设了散发网络的连通性后，要解决的就是路由布局或者说调度问题。这里能够为大家分享的实际和思考有三点：一条路由的布局、多路径还有老本管制。布局单条路由是实现数据散发的根底，咱们依据动静探测、刷新的网络 QoS 量化品质和基于以后节点情况、节点配置共同完成路由权重的计算。有了无向带权图、有了起点和终点，就能够计布局一条最短散发路由。
解决了接入问题，又实现散发网络连通性定义，当初解决了媒体数据散发路由的布局，看似就能够实现散发工作了。但对于有道的业务要求这还不够, 想进一步保障用户体验就须要晋升散发网络对抖动、丢包的抗性。多路径散发是一种保障形式。有道散发网络有三种门路——次要门路、备选门路、实时门路。次要门路间接用于业务散发；备选门路是次要门路的备份，在布局次要门路时生成，当次要门路异样时切换。实时门路是在次要门路之外额定建设的多路冗余散发门路，以提供更加弱小的散发抖动、丢包抗性，这对一些重点工作、大规模散发工作有很高价值。
以图上橙色线路为例。边缘是挪动、联通和电信三个复线机房，除了主门路之外，能够在两个边缘的联通运营商之间建设实时门路，在实现实时备份的状况下升高备份线路老本。
控制中心实现数据散发门路的布局后，就须要沿途节点执行转发工作。这波及到高性能流媒体散发服务器的设计。上图显示了有道的转发服务器线程模型。协定、端口对应不同的线程，从而在无限端口状况下尽可能利用多核资源。
除了每个协定 - 端口对会绑定一个 IO 线程，还有一个 core 线程，实现来自不同接入的数据包路由。比方一个推流用户从协定 A 端口 A1 接入（如应用 UDP，从 3000 端口推流），同会话另一个拉流用户采纳协定 B 端口 B1 接入（如应用 TCP，从 4000 端口拉流），这两个用户依据 IO 线程模型不可能调配到同一个线程，所以须要进行跨线程数据转发。此时 core 线程会依据会话公布订阅的关系，将接管队列的内容向对应 IO 线程的队列进行转发。
该线程模型的设计和业务类型、比例也是相干的。过后零碎负载以大班课为主，即推流人数大大小于拉流人数。如果业务类型发生变化，例如班型越来越小、课程每个成员都进行推流，而服务器总用户量如果不变，这会让 core 线程的转发负载绝对大班课大大增加。这也是小班课业务带来的一项挑战，须要架构能随业务变动灵便应答。
除了下面四个关键问题外，借本次机会想额定分享、探讨两个细节：分层设计和通道的概念。
分层设计相当于转发问题的延长。服务器拿到来自一个连贯的数据当前，通过 core 线程散发。逻辑构造上能够了解为三层：链接层解决不同协定连入的问题；路由层负责解决数据在外部的散发、转移；会话层保护了公布订阅关系，领导路由进行散发，将数据发到正确的连贯。该分层思维不仅用在单机线程模型中，也用在整个散发网络中。
当业务方接入一个实时通信 SDK 时，对于“通道”不同 ToB 厂商会有不同定义，简略了解就是对实时媒体传输资源的一种形象。比方一些厂商所服务的业务场景的次要数据是人脸和屏幕共享，对应 SDK 可能就只提供两个通道资源，其中人脸通道反对大小流的同时推送。
上图以互动大班课为例介绍有道在“通道”设计方面的思考。左下角图片展现了互动大班的典型老师上课成果：右上角是主讲的老师，正在和右边的学生进行连麦，那么如何进一步把以后界面所有信息传递给其它学生？有道实时通信 SDK 提供了 Live、RTC、Group 等多个通道资源。SDK 向外裸露的通道资源数量能够定义，同时能够差异化配置，尽管名字不同然而底层资源属于同一类。一个通道对应一路同步的音视频的散发能力。
仍以刚刚的场景为例：示意图左侧是老师，右侧是学生。橙色是 RTC 通道，这部分实现老师和学生的连麦。随后老师在端上进行混流——将连麦内容、课程白板等内容混为一路音视频通过 Live 通道向其它听课的学生发送。比方能够通过获取以后屏幕内容来做端上的混流。在互动大班型的业务场景下，所有学生须要取得信息都在这一张图里，都是视频和音频的媒体信息，这样就能够采取两个通道组合的形式，一个连麦、一个直播，从而实现整个业务。
不同的通道之所以有不同的名字而不是应用一个通道对象数组，是为了进一步升高客户端接入门槛。比方 Live 通道概念上相比 RTC 更强调流畅性，这能够对应一个更大的视频最小缓冲区来晋升网络抖动抗性。
业务中发现 SDK 提供通道这种资源的形式可能会影响业务方的思考形式：如果只有“人脸通道”和“屏幕通道”，这可能会限度业务产品对新课程模式的思考。
4. 互动小班课为例
借本次机会能够和大家分享有道对于互动小班的尝试，在以下两个方面和大家交换：小班的“互动”到底是怎么的？以及互动课程的录制问题。
在小班课中，多位学生和老师全程能够连麦。不同的同学能够随时被拉到台上进行分享、答题。除了音视频、白板这些根本内容之外，咱们还退出了一些互动元素：本地媒体元素播放、多人实时互动棋盘等。这样的互动元素带来什么影响呢？
后面提到的互动大班课能够在端上混再发送到 Live 通道，这样流既能够省去须要独自服务端混流带来的视频提早和同步问题，同时残缺地传递了所有课程信息。然而对于互动小班课，如果老师端通过这种截取屏幕将内容分发给其余学生的形式，就会失落互动元素的可互动性、布局也无奈扭转。当一个学生回头看录播的时候无奈进行参加，只能作为旁观者看到别的同学的互动过程。这也是互动小班课第一个难点——互动元素如何解决？如何进行录制？回放的时候如何放弃同步？理论中是有很多坑点和挑战。
5. 对于自研
最初想和大家探讨一些对于自研实时通信零碎的问题。
这里的局部内容截取自 ToB 厂商对痛点的剖析，自研所遇到的问题能够分为以下几点：
- 老本：除了人力、资源笼罩、动静扩缩容的运维等，还有与之对应的机会成本。前两点都比拟重要。另外不同业务带宽峰值地位不同，复用一套基础设施和带宽资源能够升高资源、能源的耗费。
- 危险：比方上文提到用一套 MCU 联合两套架构，可能会引入额定的危险。
- 边界：比方是否退出非凡配置解决业务问题，团队内做自研对于业务需要的边界如何把握的问题？
- 系统优化门槛：当跑通上文提到的所有内容后，业务能够跑起来。但如果想要进一步压缩老本，就须要对更深技术栈的了解，比方数据驱动的全链路传输优化，编解码的优化，难度和所需的人力可能都会更高。
但自研的劣势也是很显著的：
- 对音视频基建的了解：音视频逐渐成为一种基建，但如果团队只通过三方 SDK 的形式接入音视频能力可能无奈深刻理解音视频技术的难点、无奈正确评估危险、无奈把握潜在的机会。
- 更多原子能力：自研技术能够依据简单的业务须要依照业务线进行更灵便的配置，用正当的形式裸露更深的接口，这会让业务层取得更大的灵活性。
- 对产品、研发、技术支持提供帮忙：音视频技术波及宽泛且简单，让客户端研发同学、技术支持同学对业务呈现的异样精确排错、依据埋点数据分析问题起因是很艰难的。依赖音视频自研团队对业务中遇到的问题进行积攒、了解更深层的起因、排查将来可能呈现的隐患是一种卓有成效的办法。通过音视频自研团队能够辅助产品进行设计、减速研发对音视频技术的落地，还能辅助技术支持在业务中确定用户问题起因、提前发现更深的隐患。毕竟再快的工单零碎可能也无奈比隔壁工位的反对来的更快。
- 老本管制、面向业务优化：当能操控的技术越底层，针对特定业务能做的优化空间也就越大，进一步优化体验的同时也有更多老本压缩的空间。
感激浏览，以上是本次的分享内容，谢谢！
