在线教育“疫”外爆发视频直播闯关数百万级用户高并发

　　受特殊情况影响，今年全国普遍延期开课。“停课不停学”，线下教育停摆，教育行业转战在线直播。流量突然暴涨，多家在线教育直播都曾出现过系统崩溃。

　　看似简单平常的在线视频直播为什么难倒了教育公司？数百万学生同时在线学习需要什么样的计算支持？这些问题我们都很好奇。为了更清晰的解答这些问题，我们也与声网Agora技术VP孙雨润、声网Agora教育产品负责人 仇媛媛聊了聊在线教育视频直播背后的技术支持。

　　在线教育直播遭遇登录难、高卡顿

　　假期期间，有多家在线教育的直播课出现了崩溃情况。解释为什么出现崩溃或者卡顿的问题。需要先解释下在线互动直播教学系统的构成，一般有业务系统、白板系统和音视频分发系统构成。

　　概括来说，多家在线教育直播出现的问题有两类：登陆不上、高卡顿导致几乎不可用的问题。登陆不上的原因是业务系统后台容量不足，扩容没有跟上并发的增长，导致的登陆不上。高卡顿的问题主要实时音视频部分的系统可靠性不够导致。春节期间，各在线教育直播平台用户量激增，由于春节期间封网，带宽资源、服务器资源很难短时间扩容，导致超出了系统承载的极限。后台崩溃了，从而导致大范围的不可用。

　　在线教育视频直播的场景是非常重视实时音视频质量的场景。任何一堂课的质量问题可能都会带来赔偿或者退费。音视频质量的好坏是由系统的端到端决定的。大致可归纳几个因素：

　　1.设备端：和设备性能、机型、平台有很大关系。设备性能差的话，如果使用纯音频或者低分辨率视频直播，是没有问题的。但是如果直播业务选择了很高的分辨率，对机器性能要求就会比较高。

　　2.用户端网络：和老师、学生侧的家庭网络有关。电信、联通等运营商的连接质量明显好于小运营商的。有线连接稳定性明显好于wifi连接。

　　3.平台侧：和实时音视频互动强相关的主要是RTC平台。比如声网就是提供这样的RTC PaaS服务的，也有部分教育直播互动平台自研RTC部分。RTC平台提供动态网络路由调度，实时音视频分发等功能。不同大小的厂商提供的平台并发能力、可用性都些差别，这和系统架构设计、运维能力都息息相关。如果服务器与服务器之间的网络有丢包，或某台服务器负载过高，都会导致音视频的卡顿。而春节期间，有些平台没有及时扩容，出现大范围的服务器资源过载，带宽资源瓶颈，导致了音视频传输在服务器与服务器之接出现了高丢包，从而导致大范围的卡顿问题出现。

　　其实，教育、社交、办公是音视频技术的三个场景，但对音视频技术的诉求会有些差别。相比于社交，教育、办公对实时音视频稳定性、流畅度要求更高。因为一旦实时的互动中出现音视频不可用，高延迟、高卡顿的情况，就会影响到学习的效果，和会议中的沟通效率，带来时间上或经济上的损失。

　　社交场景因为娱乐性缘故，对音视频的高清画质、有趣的玩法要求更高，比如视频直播场景里，对连麦的首帧出图时间以及切换频道的延时要求很高。

　　因此技术难度上，教育和办公场景因为强调高质量、低延时、强互动，所有与会方所在的网络、使用的终端、所在环境等多种因素都会导致实时互动的延迟、卡顿、稳定性、视频质量，难度会更高。

　　在线教育直播“闯关”超高并发

　　概括来说，此次一些在线教育直播的崩溃来自于超高并发的流量。

　　高并发顾名思义说的是能同时支持大量用户同时使用服务，这实际上是个结果，这个结果要求背后有一套高可靠性(reliable)、高可扩展性（Scalable）、高可维护性（Maintainable）的大型分布式系统。这些buzzwords向来是说起来容易做起来难。对实时互联网、实时音视频技术来说，突出的难点可以总结成两点：

　　一是实时互联网对质量的要求是近乎苛刻的。比如，声网平台每天高峰期数百万用户同时使用音视频服务，百万分之一的bug都会带来不小的影响。以教育为例，上课时音视频卡顿不仅有可能会带来教学质量差、师生投诉退款流失的风险，由此产生的拖堂、补课还会影响整体排课计划引起连锁反应。

　　二是互联网中包括网络、硬件、软件甚至时间在内的绝大多数组件都是不可靠的：硬盘故障、服务器死机、交换机重启、机架断电、数据中心主干网故障，这些问题司空见惯。尤其在一个包含数万节点的大型分布式系统中，几乎每天都会有一批组件发生故障。

　　基于不可靠的组件、在全球范围内构件出一套极致可靠的大型分布式系统，来满足客户、用户实时音视频通信需求，这是非常有挑战的。分布式系统的原则和思路在学术和工业界都相似，这里我更想分享下从源头工程管理和工程实践上如何保证质量。

　　首先架构设计上：声网Agora的架构师团队在做架构演进设计是要考虑10X以上负荷。比如，如果平台在高峰期需要支持100W用户同时在线时，那么系统从架构设计上要有能力支撑1000W；高峰期请求QPS在1K时，系统要至少具备10K的处理能力。

　　然后在工程师代码管理上：针对工程师有完整的自动化工具来扮演专家code review的角色：包括coding style、模块化程度、UT覆盖率、黑盒自动化测试覆盖率、staging环境测试、压力测试、自动灰度升级、灰度升级期间自动验证等。这样才能保证以两周一个班车的高频迭代下，仍然有可用性的质量保证。刚来的工程师会发现进代码很难。

　　最后极其重视从错误中学习：公司初期，有一个“等号”写成“不等号”的低级错误，声网Agora CEO 赵斌牵头复盘了3次，背后的逻辑是这种低级错误如果都不能避免，就别奢谈什么解决行业前沿、世界前沿的难题。

　　超高并发背后的资源瓶颈

　　超高并发背后其实是资源瓶颈。资源瓶颈包含两个方面，第一个是CDN和RTC这类直播、互动云服务的后台瓶颈，第二个是企业自身业务后台是否存在瓶颈。

　　CDN/RTC：在线教育的视频直播主要包括两个类型，一类就是偏向于直播，老师和学生之间有简单的实时互动要求，学生能听/看清楚即可，允许3-10秒的延迟；二类就是更偏向于互动，教师和学生之间需要有较多的互动，教师和学生要实时与对方进行互动，要求延迟低于300毫秒。第一类CDN即可解决，第二类RTC。

　　业务后台：不论做纯直播还是做互动，服务器对在线教育视频直播是不可用或缺的，业务后台依赖于服务器资源，包括教育中需要用到的录像等业务也依赖于服务器资源或者云存储资源。业务平台功能，例如登陆、后台消息互通都是需要有并发量支持，所以业务服务器资源多少决定了平台能承载的并发量。云主机、云存储都是很成熟的IaaS服务了。购买可以解决服务资源的问题，云服务厂商也会提供一定的技术支持。但是怎么用，能不能用的好还是需要有后台开发和运维人员的。

　　其实，这波疫情期间，有很多在线教育视频直播平台冒出来。其中大部分都是基于第三方的PaaS实现的。

　　在线教育视频直播是自己建团队、开发平台，还是直接采用SaaS服务，还是要看团队自身的能力。

　　第一类像大型的教培机构，有构建研发团队能力，他们在短期应急可能会选择采用SaaS，因为有较全的基础功能，可以立马用，缺点是扩充性较差、实时互动质量难以保证。但从长期来，他们会更偏向于基于专业的PaaS服务来构建自己的平台，优点是实时互动质量得以保证，有较好的扩容性，可以做针对性业务需求进行定制化的功能开发，缺点是需要开发能力和集成时间。

　　针对这一类，基于PaaS自己实现在线教育视频直播业务的。可能需要采购RTC、CDN、云主机、云存储服务，然后基于这些第三方的服务开发自己的应用。还需要完成的工作包括研发团队组建、适合自己场景的业务需求定义、开发运维、平台的运营以及对老师学生的服务支持等等工作依然需要自己完成。

　　比如，声网就是提供RTC PaaS层服务的，服务客户群包括：中大型的教培机构、在线教育公司、提供互动直播教学工具的SaaS公司。在教育行业的客户包括：新东方、好未来、VIPKID、沪江CCTALK、火花思维、学而思网校等。SaaS客户包括：伯索、百家云、保利威、奥鹏教育、欢拓、希沃云课堂、学点云等。

　　第二类小规模的教培机构或者公立校，以老师和内容输出为主的，没有能力构建研发团队，以采购SaaS为主，有较全的基础功能、即买即用，可满足他们的需求。

　　针对这一类，基于SaaS平台开展在线教育业务的。需要基于自己的业务，发展出适合自己的业务运营模式，从引流、试听、购买、授课一整套环节都要实现在线化。需要结合内容对老师进行培训并提供必要的工具，有些线下讲课很好的老师未必能很好的适应在线教学。

　　编辑：朱紫瑛