TutorABC打造覆盖全球的WebRTC实时课堂之路

近年来，在线教育行业发展如火如荼，iTutorGroup 研发总监 董海冰总结了团队在实时互动云课堂TutorMeet+开发过程中的经验教训及技术难点。本文来自其在LiveVideoStackCon 2018音视频技术大会的演讲，并由LiveVideoStack整理而成。

文 / 董海冰

整理 / LiveVideoStack

大家好，我是来自iTutorGroup的董海冰，有十年以上的在线教育相关音视频技术研发经历，擅长分布式系统的搭建、架构与基础平台建设等。本次分享我将围绕以下几个部分为大家介绍我们完全基于WebRTC标准自建的这套已达到商用级别的大容量高并发可扩展实时互动音视频系统—TutorMeet+。

iTutorGroup的主营业务为基于真人实时互动的音视频的在线教育课程，主营产品包括针对少年儿童在线英语教育的vipjr以及面向成人的TutorABC在线教育产品。我们的线上老师来自80多个国家一百多个城市，实行7x24小时授课，每年的课程数量超过千万。可以说我们的WebRTC系统即使在全球范围内也具备相当大的规模。

希望通过此次分享能与大家一起探讨WebRTC的未来发展方向并为我们进一步优化和适应在线教育未来业务发展做好准备。

1. WebRTC概述

WebRTC作为谷歌的一项开源项目用不到十年的时间取得了巨大的成功，以至于现在几乎所有主流浏览器都实现了对其较好的支持。

上图比较清晰地展现了WebRTC浏览器端的整体架构，其中顶层紫色部分为Web开发者API层，蓝色实线部分是面向浏览器厂商的API层，蓝色虚线部分浏览器厂商可以自定义实现。

WebRTC已经基本实现了对市场上主流浏览器的支持，同时由于WebRTC已经成为W3C的国际标准，浏览器厂商也会主动推进其对WebRTC的支持与兼容。即使是之前“独创”了OpenRTC的微软也在新一代浏览器中努力推进对WebRTC的支持。而国际上，Chrome在所有支持WebRTC的浏览器中占据超过70%的份额，并且一直保持着比较高的更新迭代速度。

上图展示了WebRTC的的协议栈，其中颜色相同的基本可以相对应。需要强调的是和WebSocket和HTTP 1.X/2不同，WebRTC协议栈中较为常用的如SRTP、RTCPeerConnection等都是建立在UDP协议基础上的。QUIC较为火爆的原因也是其架构在UDP之上，在减少延时，提升性能和增加容错方面有显著的提升。WebRTC的魅力在于可以动态适配不同条件的网络，网络环境越差，其在传输富媒体的优势越明显，在新的WebRTC协议中，QUIC也占有一席之地。https://w3c.github.io/webrtc-quic/

早期的WebRTC是基于P2P的方案进行设计的。此方案的缺陷在于众多客户端都是NAT网络，甚至有的还在防火墙后面。P2P的方案需要穿墙，而且其成功率不高，仅为70%左右。尤其在1对多的情况下，网络的联通性很容易受到各种条件的限制。因此，我们采用STUN Server与Relay Server的方式设置多台固定服务器并与客户端进行ICE协议的中转建立链路，从而有效避免了复杂网络和防火墙对网络的影响。

上图详细展示了WebRTC的具体连接过程，可以看到WebRTC的数据连接流程还是比较复杂的，需要经过很多步骤才能在浏览器端与Media Server之间建立有效的媒体会话。

WebRTC Server包含以下三种连接方式：Mesh、MCU、SFU。Mesh就是简单的P2P两两相连，而MCU则通过服务端合流实现多路媒体信息的数据交换；SFU则是将上行数据缩减为一路，通过服务器的转发将其他N-1端的数据传送至目标客户端，其特点在于下行带宽明显高于上行带宽。如果从带宽角度来说，MCU无疑是一种不错的选择，而在实时音视频方面必须关注的一项指标便是延迟，延迟时间越长互动效果越差。虽然MCU节省了带宽但却在一定程度上消耗了服务器的CPU转码资源，延长了数据延时时间；而SFU的优势在于只转发，不做任何处理，体现出的效果就是虽然在带宽上尤其是服务器端的带宽有所牺牲，且多路数据的传输也会明显增加对服务器的带宽压力，但其延迟相对于MCU来说更低，实时性更好，也不占太多宝贵的服务端cpu资源。我们根据不同的教学场景，采用了SFU与MCU混合的方式。

与WebRTC相关的几个经典开源项目有Janus、Licode与Kurento。以Kurento为例，尽管提供了丰富的接口与强大的功能，甚至集成了图像识别和AI的相关功能。但首先由于基于GStream的Kurento媒体数据处理时会叠加处理大量的Filter，使得性能和服务端的承载能力明显不足，单位CPU的承载能力非常有限，无法大规模应用。其次， Kurento的服务端有C++，Java，Javascript等不同语言的诸多模块组成，系统设计比较复杂，稳定性与综合性能也并不突出。而Janus的功能虽然比较简单，不及Kurento，但其C代码结构清晰，质量较高，完全可以作为一个合格的WebRTC网关来使用。当然我们在测试的过程中也发现了一些bug，但是整体上性能还是非常好的。Licode由C++开发，我们用得比较少，在此不做评价。

2. TutorMeet+概述

由于TutorMeet+的Web端是基于Html5开发，可实现较为自由的个性化定制。这里我想强调一点UI对用户体验的影响：TutorMeet+的初版页面中音量指示条设计的比较小，“波动“并不明显，这就导致虽然用户未听到声音，且网络连接正常，但用户会因为外接设备（耳机或者麦克）的问题，导致听不到声音。而误认为是连接问题，对产品有一些抱怨。随后，我们调整了这一设计问题，进一步明晰化了音量波动的设计，用户就再少出现类似的负面反馈了。其实这个教训告诉我们，好的产品不仅需要高水平的技术实现，而且与产品的用户体验息息相关，二者缺一不可。

WebRTC只是一套标准，并未给出具体解决方案。大家可以结合自己的业务用各种技术实现，我们的TutorMeet+的服务端是基于Golang研发，有少部分模块由C、C++开发。视频编解码器支持VP8、VP9、H.264，未来将会支持最新的AV1。音频编码器支持OPUS与AAC。在部署上我们全部采用了Docker化的部署策略，使其具备了秒级快速弹性扩展的特性，并使其具有更快的更新与发布频率。采用了“自建机房+公有云”的混合云部署方案，目的是为了方便在业务高峰时段实现服务器的弹性扩展与资源调配，且兼具公有云与私有云的优点。例如：公有云在分布式存储与大文件处理上的优势较为明显，而私有服务部署可以提升核心数据的安全和稳定性性。并且，我们针对公司的业务特点，研发了可以支持一对一、一对多（1v6以下）、一对N与N对N（云讲堂支持上麦）等主流模式的分区服务集群。

TutorMeet+不仅可以通过Chrome访问，也可以通过轻量化客户端实现对PC Natvie，Android与iOS等从PC到移动设备的全端良好支持。具体来说我们用Golang自主编写了一套被称为Beacon的路由层，并使用分布式API把某一部分课定位到某私有机房的某一套宿主机当中，也可部署在多个彼此隔离的公有云的独立分区中。自研路由层意味着我们可以灵活定制业务逻辑，将每种业务类型的教室定制到每一服务器分区，从而实现较为灵活的切换与AB Test和灰度发布。分区部署则允许我们在网络出现异常时通过服务隔离和及时转区的方式尽量减小由公有云软、硬件故障带来的的影响。

其次，我们在架构中构建了媒体与信令两套独立网关。我们的许多讲师身处海外，学员也分布在世界各地，这就需要我们实现网关的全球就近部署。经过这么多年的积累，我们已经建立了遍布全球的数量庞大的加速节点，无论是国内与海外连接还是国内与国内连接，TutorMeet+建立连接始终遵循就近原则，同时通过服务端的专线以保证重要数据传输的稳定性。

统一配置方面我们使用consul，而服务间的协议则使用gRPC。客户端与服务端的交互基于WebSocket，而前端基于ReactJS进行开发。数据访问层则使用Actinia统一封装，同时使用MySQL DB，Mongo，以及Redis作为数据层。

3. 面对的挑战

TutorMeet+上线以后也面临着诸多挑战，首先前端的挑战在于我们对Web端的控制力。由于我们前期在服务端投入的精力更多，导致系统上线之后，前端尤其是客户端上出现的问题令我们疲于应付。一方面是因为由于WebRTC还算一种新的前端技术，其浏览器内部的API也在不断调整，与此同时Chrome升级频繁也容易出现许多亟待解决的问题。这些都需要我们在测试、运营TutorMeet+时不断改善、调整。前端的优化在我看来更像是老工匠在蛋壳上雕花，考验的是研发的自信心和控制力，也需要异常的耐心。

例如，在GetUserMedia环节我们就遇见了类似于异常退出或权限申请异常等问题，有些是由于浏览器沙箱带来的申请硬件资源的权限受限，但诸如设备不可读这样的问题，表面上是因为浏览器端的权限申请失败，实际上却并非如此。

由于在浏览器端访问麦克风与摄像头是两个独立权限，如果麦克风或摄像头中有一个处于权限禁用的状态就会导致NotFoundError的错误出现。其后果便是用户无法知晓出现错误的真正原因是无法找到设备还是权限申请失败，从代码层面我们可以找到造成此问题的蛛丝马迹。解决这种问题的方案是通过捕获设备的label来判断设备是否有权限，如果是无权限设备则label为空，有权限label则非空，从而明确知晓NotFoundError错误出现的真正原因并及时处理。整个项目中，类似这样的tricky的地方有数十个之多，需要一处处攻克。

网络的复杂性则是我们在探索过程中的另一项挑战。如上图展示的那样，中国的网络状况并不太好，平均带宽相对于一些发达国家的差距还相当明显，延时与丢包在数据传输的过程中也经常发生。此时自研TutorMeet+的优势便能得以显现——我们搭建了一套可在稳定的国际传输中控制低丢包率与延迟的网络，通过智能路由以及运维手段加以优化。同时引入公有云，结合海外节点与国内加速形成一个较为完善的全球分布的加速网络。

虽然我们搭建的全球分布式网络能极大优化数据传输的稳定，但从实际测试来看短时间丢包或RTT过高等问题依旧较为明显，这就需要借助WebRTC的码率自适应处理的能力。WebRTC提供了许多应对方法，例如：FEC、NACK、GCC等，都可以较好地解决此类问题。

完善的数据监控能为服务尤其是故障排除带来极大帮助，在我们开发TutorMeet+的过程中，大概有1/3的时间用于数据搜集和搭建监控平台。借助自研的便利性，我们可以从Server到Client，全链路地收集各种关键数据。我们搭建了智能监控平台，使其可对整个链路进行分析并及时发现一系列问题。海量数据与科学精准的分析能发现平台的许多潜在问题与风险。

数据除了可以发现问题，也可为自动化干预带来依据与支撑。我们正在搭建的AIOps系统可通过自动化手段处理问题，让我们尽量减少人工的干预。即便需要人工的技术支持，分析系统也能帮助相关技术支持人员快速定位问题和给出及时的解决方案。

需要强调的是，全方位的监控系统TutorConsole+系统的建立是我们公司近20年的线上运营经验的积累汇聚而成的。

但是，监控系统的问题有时会为整个平台带来严重影响，因而也应该被我们视作关键链路中的一部分。例如：有一次我们发现分布式缓存的监控数据返回的时间从原先的几毫秒一下变成十几毫秒。初期影响并不明显，而随着业务高峰到来，用户数量的急剧增加，其对主流程的数据传输的延时干扰愈发严重，最终酿成了一次较大的故障。虽然最终我们通过回滚的方式迅速解决了问题，但在排障时我们完全没有意识到其原因是监控系统升级导致的故障。随后才发现原因竟然和监控系统相关，即使出现毫秒级的延时影响也会使得累积的数据量增加了几十倍，防微杜渐，这对我们来说是一次宝贵的经验教训。

上图是我国古代航海船的内部水密舱的结构，水密舱可以有效的隔离海船因为局部触礁带来的整体风险。我国古代的航海业才能从近海走向远洋，才有了后来的海上丝绸之路和郑和下西洋。“分区策略“可以说是中国古代劳动人民对世界作出的卓越贡献。甚至影响了今天的互联网，诸如QQ、YY等拥有海量数据的平台都会建立其专门的系统分区策略。一旦用户规模上升到相当的水平，良好的分区策略可极大地隔离风险，增强系统的可靠性，降低故障率。

当然，在应用分区策略的同时我们也经历过惨痛教训。例如：有一次我们发现公有云中一台物理的宿主机发生了硬件故障，造成多台ECS故障，随后我们马上进行了自动切换，因为调整及时未受进一步影响。但是，每台ECS上都部署了几十甚至上百个Docker，在服务器重新启动后，一些关于Room管理服务在重启后突然出现异常。随后我们迅速迁移走了故障服务器分区的流量，并由研发紧急寻找原因。但是问题比较棘手，到了晚上高峰时段还未有效定位问题。结果直接带来的影响就是故障分区的服务器无法上线，使得系统整体的承载能力下降，导致当晚用户访问峰值阶段由于国外Gateway承载能力不足，再次出现异常。最终我们不得不采取紧急扩容的方式保证服务正常上线。而在紧急扩容时又由Docker内部的DNS问题导致了另一起故障……，这种连锁的故障接二连三的接踵而至，尽管每次处理还算及时，但是却非常出乎意外。这让我们不能重新审视其根本原因。之所以出现这种“蝴蝶效应般”连锁式的故障，其根本原因在于我们前期在预估分区容量过于“保守”以至于当某一个区出现故障时其他区的数据弹性容量不足导致整个系统承载力大打折扣。此后我们设立了新的估算原则，让分区的资源尽量可以支持两个以上分区同时出现故障的极端情况。

新系统的灰度发布的挑战在于要在测试或上线新系统的同时继续运行主服务并保证整个服务不会受到任何影响。其难度就象给正在飞行的飞机更换引擎。灰度发布的同时我们也不能一次性将所有数据全部迁移至新平台，只能逐步调节新系统的流量占比。这就需要我们同时调度两套系统平台以保证整体的服务稳定。

在新平台上线的初期我们会暂时封闭一些新特性以保证用户迁移至新平台时不会遇到严重的问题，用户迁移完成后新平台的新特性才会逐一开放。这样做的好处在于可随时实现双向切换，并且由于用户体验几乎完全相同，因此不会受到任何影响。在长达数月的新系统灰度发布的过程中，我们不断采集个方面对新旧两套系统的故障、发火数据和用户反馈，及时发现了新系统存在的隐藏问题，并且不断改进，提升新系统的占比，让用户体验得以大幅提升。

4. 崭新的教学体验

基于音视频的在线教育课程只是在线教育的基础，我们的一些特殊课程，例如：“编程课“就是通过基于Go语言实现的RDP协议得以实现教学中的远程控制。这个重要突破让我们在行业可以率先实现老师在线“手把手“地进行编程教学，获得了很好的教学效果，也是我们探索崭新教学体验的成功尝试。

我们构建了如上图展示的这样一个可以实现良好人机交互的在线互动编程课，老师甚至还可通过权限控制直接帮多个学生一块实时操作、修改、运行学生所编写的Scratch程序。这种复杂的交互模式除了可以应用在在线教学领域，对于异地办公的线上协同也是非常有帮助的。

除此之外，针对数学课的教学特点。我们的平台也支持光电或者电磁笔等书写工具，为学生带来更接近线下纸质化教学的在线课堂学习体验。

AI也是TutorMeet+系统中不可或缺的一部分，已经被我们用于分析学生的课堂行为，来判断学生情感与内心活动从而指导老师对所教内容及时作出调整，以实现个性化教学与关怀。

由于WebRTC良好的灵活扩展性，VR与AR也成为丰富教学内容激发学生好奇心与积极性的重要功能，基于一些3D厂商提供了许多Web端的接口，实现VR与AR已不再成为一件难事。

针对一些特别场景，我们可以通过Native的Client端为老师提供3D的动态贴纸或者面具。就象上图展示的那样，给在线教学带来线下没有的更加生动教学体验。

总之，通过对WebRTC的不断探索，我们不仅打造了TutorMeet+平台，还在此基础上研发了一系列面向未来的在线教育应用。相信通过大家的不断努力，TM+的应用体验一定会越来越好。让更多热爱学习的人享受在线教育的公平、便利。让越来越多的人通过互联网收获知识的力量，改变自己，改变我们的世界！