教育场景高性能架构技术选型与实践

By 伍新春@跟谁学

背景

近两年来，互联网+教育的概念非常火热，成为互联网发展的一大风口。2014年成立的跟谁学是一个O2O找好老师教育服务电商平台。老师、机构通过网络在平台上入驻，发布课程，学生通过科目分类或者直接搜索找到合适的老师、机构或课程。平台做学生与老师、机构、课程的连接，并支持学生直接在平台上下单买课、支付、学习、评价，完成整个教与学的闭环。目前平台有6600万的学生，50万的老师和6万家机构，在教育O2O领域是遥遥领先的第一名，平台的技术架构对于行业有一定的参考价值。

架构选型

跟谁学定位为一个O2O找好老师教育服务电商平台，其中有几个关键字：O2O，找好老师，教育服务，电商平台。O2O的定位意味着平台需支持线上到线下的连接，有基于LBS的服务，学生或家长可以通过APP寻找附近的老师和机构，在产品形态上也需要支持线上进行连接，交易，支付，线下进行服务的逻辑。而“找好老师”的定位决定了平台需要提供科目分类，搜索与推荐等便于用户获取老师和机构信息的服务，并且能够基于老师和机构的多维度的信息，对老师和机构进行评估和排名，并和学生进行匹配，做出最佳推荐。“教育服务”意味着平台需要提供上课（直播和点播）、答疑等服务。而“电商平台”则要求平台对课程展示、IM沟通、交易、支付、评价等进行支持。基于这些定位，跟谁学平台的产品架构图如下。

上述的产品架构图基本上罗列了跟谁学平台上的主要服务，每个服务都是相对独立的系统或模块，大部分通过接口或者独立项目的形式呈现。

技术架构选型

产品架构确定之后，需要对平台的基础架构做技术选型，经过创始技术团队充分的沟通和讨论，最后决定采用传统的LNMP架构，主要考虑的以下几点：

• LNMP非常成熟，是主流的网站建设技术架构，各种场景都有相对完善的解决方案
• 开发部署方便快捷，能快速迭代，符合创业电商平台公司定位
• 行业人才储备丰富，能够快速搭建团队，快速开发上线

应用部署与运维选型

在应用部署和运维层面，2014年云计算技术发展已经相对成熟，当时应用的部署和运维的主要方案有两个：自建IDC和使用云服务，这两种方案各有优劣，经过评估最终决定使用云服务。相对于自建IDC，云服务有几大优势：

• 成本低

  传统自建IDC需进行机房选型和机柜租赁，一次性投入较大成本购买新的服务器，交换机，防火墙等硬件设备，前期一次性投入较大，而创业公司前期资金比较紧张，采用云服务器无需一次性大的投入，可以按使用规模和时间付费，使用成本门槛低。

• 部署快

  创业公司前期业务一般扩张速度比较快，在业务快速发展时，服务器将经常面临扩容的需求。如果使用自建IDC，扩容需要新增服务器、交换机采购，机柜租赁等。而这些硬件设备的采购和上架，通常需要较长的周期，时间周期上无法满足业务快速发展的需要。提前准备又将面临业务的不确定性，和增加资金的提前投入。云服务则不存在这些问题，可以按需购买，弹性付费，灵活应对业务变化。也可以对已购服务器直接进行配置升级，无需单独购买内存，CPU等设备，进行停机维护和升级。

• 运维简单

  自建IDC运维投入相对较大，需要有专门的运维人员进行服务器的上下架，安装，部署，网络布线等操作。为保证服务的稳定性，一般还需要专门的驻IDC运维人员，以应对突发的软硬件及网络故障。对于创业团队，这无疑是一笔较大的成本，也增加了团队组建的门槛。而云服务器通过提供的统一的控制台管理工具，可以方便的对服务器进行在线安装，重启，扩容，上架，下架等，所有IDC基础运维的工作都由云计算公司统一承担了，极大的减少了企业的运维成本。

  当然云服务器也有其固有的劣势，比如运维管理及问题排查黑盒，单机性能稍差，共享硬件资源有一定的安全隐患等。对于初创企业，云服务器的这些问题相对于他的优势，相对影响较小。在云计算供应商选型时，跟谁学选择了当时国内最大的公有云服务提供商阿里云，因为其当时用户量已经比较大，经过大量客户的验证，服务相对稳定可靠，价格方面也有一定的优势。当业务发展到一定规模之后，自建IDC的可控性，规模效应，成本优势将体现出来，届时公有云将不再是最佳选择。

数据库选型

数据库层面我们也选择了阿里云的RDS服务，并且对接了DRDS服务，直接透明支持数据库的读写分离服务。RDS背后有高水平的专业DBA团队在建设和维护，相对于自主搭建mysql，有几方面的优势。

• 数据可靠

  RDS使用主从热备的集群架构，当出现硬件故障时，能在较短时间内完成自动切换。只要应用程序支持数据库连接自动重连，业务或应用不需要任何人为干预即可正常运行。RDS支持根据自定义的备份策略自动备份数据库。防止数据丢失和误删除，数据相对安全可靠。

• 维护方便

  无需维护数据库，只需根据自己的需要选择相应的RDS实例，部署也非常简单快速。大大节省硬件成本和维护成本。支持根据系统压力的变化，支持在线方便地进行存储容量和性能容量的升级从而获取更多资源。

• 性能优秀

  采用高端高性能服务器配置，为高性能提供了有效的硬件平台。同时由专业DBA对数据库参数做了特定的优化。与自建mysql相比具有一定的性能优势。

  基于阿里云RDS的强大功能，跟谁学平台前期都没有专门的DBA，都是由运维同学在管理和维护数据库。而RDS的问题在于和阿里云其他服务绑定太死，无法灵活应用，另外数据安全性也存在一定的隐患。在业务发展壮大之后，需要考虑将部分的核心业务数据库的迁移到私有云上。

平台总体架构

因为跟谁学平台的云服务器都是使用的阿里云，为了网站的快速搭建，在应对高并发的访问场景时，选择的负载均衡工具也是阿里云的SLB服务，内存缓存也使用的阿里云的Redis和MemoryCache服务，消息队列的服务大部分场景也是用的阿里云的MNS服务，包括云存储也是用的OSS，整体与阿里云绑定的比较紧。整体的平台网站的架构图如下。

从上图可以看到，为了提升网站的访问性能，增加了NginxCache，MemoryCache，Redis等多重缓存，针对每个缓存技术的特点和业务的实际状况，用于缓存不同的内容。同时也从业务层面解耦，将一些非强一致性的业务使用消息服务进行剥离。纯静态资源以及视频流等使用CDN分发。等等这些都是为了提升平台的性能，减少访问的等待时间，提升用户体验。

最佳实践

跟谁学平台发展至今也已有两年多的时间，期间业务在飞速的发展，在各个功能模块开发和维护过程中也犯了不少错误，踩了不少坑。因为场景及功能模块太多，这里将选取一个比较有代表性的模块的发展案例，详细阐述一下。

万人直播

跟谁学定位为教育服务平台，赋能B端、让老师有方便好用的上课工具，一直是平台追求的目标。老师在线授课主要有两种手段：直播和录播。录播就是我们常说的视频课，一般由老师在线下录制完后上传到平台，学生直接在平台上下单购买观看。而直播上课因为其互动性强，上课效果好，课程内容时效性高，一直是老师给学生上课的主要工具和手段。从技术角度看，直播对于技术的要求也远比录播要高。跟谁学一开始就决定自主研发直播技术，从最开始支持几十人，几百人，到后面支持几千人，上万人的大课。直播技术从无到有，从有到优，一步一步走到现在，中间有很多的经验值得分享和借鉴。

那么教育场景下的直播技术和其他比如游戏直播，秀场直播有哪些区别了？

1. 教育场景的直播通常没有游戏和秀场直播那么多同时在线的用户量

   在游戏或秀场直播场景中，几十万人甚至上百万人同时在线观看的情况是比较常见的（不考虑在线人数虚报的水分），而教育场景下万人以上的大课已经比较少见，十万人以上的大课可以说是凤毛菱角。这是否说明教育场景的直播技术要求不如秀场等直播场景了？其实不然。

2. 教育场景的直播互动性要求比游戏和秀场直播高很多

   通常我们看到的游戏或秀场直播的场景下，用户和主播的互动都是通过文字来进行的，在观众人数较多的情况下，只要做好文字聊天服务器的交互和分发就可以了，而视频通过CDN的分发和扩容就能达到支撑海量用户在线要求。而在教育场景下，老师讲课和学生提问题是相互作用的，互动的次数越多，说明教学的效果越好。因此教育场景下的直播不仅需要支持老师发言，还需要支持学生举手提问，通过语音和视频发言，这一互动不仅仅是老师和提问学生之间，也需要同步给所有正在听课的其他学生。仅这一项需求就让直播的技术难度成倍的增加。

3. 教育场景对于直播工具的功能丰富度有很高的要求

   游戏和秀场直播场景中，主播端的操作功能相对简单，除了单向的视频和语音外，文字和其他互动，只需要进行文本、表情等信息传递和同步以及简单道具的支持就可以了。但教育直播场景则复杂很多，需要支持老师在视频中动态展示各种PPT，PDF或Word文档等，同时还需要支持激光笔和画笔，用于在展示的各类文档上做指示和标记，另外还需要支持白板，支持老师随手写写画画。这些复杂的交互使得信息同步的要求增高，数据的传输量也会加大。

在跟谁学平台直播工具研发之初，场景更多的是基于PC，为了快速搭建直播平台，采用了Flash的技术。那么Flash在直播场景提供了哪些技术支撑了？

• 标准清晰的多媒体传输协议（RTMP）。
• 支持H264视频格式，支持AAC高清语音，支持低码流的Speex语音。
• 多平台的SDK。

利用上述的Flash技术，平台完成了跨平台的网页客户端和windows客户端，基础的课程功能和基础音视频的互通等直播基础功能。

可以说平台使用Flash完成了最初的直播工具的搭建，是一个从0到1的过程，使得平台快速有了直播的能力。但是随着平台的发展，Flash技术的一些问题逐渐体现出来:

1. 移动端方案不完善。UI效率低下，与原生应用无法融合，耗电，IOS平台的种种限制等。
2. 协议层面上对低延迟应用考虑不足。比如使用TCP传输，对流控无设计。
3. 由于运行在虚拟机中，开发者受限于其提供的SDK，无法发挥硬件平台能力。
4. 各个平台、浏览器对Flash限制越来越多，比如chrome对Flash广告拦截等等。

在直播的在线人数快速增长之后，经历了各种卡顿、延迟、掉线等问题，已有Flash方案已经不能满足业务的需求，新的直播工具的研发就被提上了日程。那么新直播工具的研发具体要解决哪些问题了？首当其冲的是卡顿和延迟的问题，这个是最影响用户体验的。其次要解决各端适配的问题，如何能最低成本的适配Windows，Mac，iOS，Android和移动网站等。最后要解决的是针对之前遇到的那些问题点如何去监控、告警和优化。基于支持万人在线的直播课的总目标，最后确定新的直播工具主要的优化目标如下:

1. 优化聊天服务器。
2. 利用HTML5构建跨平台的统一化客户端。
3. 大房间直播在自建服务器集群基础上增加CDN分发。
4. 确定桌面共享方案。
5. 建立质量监控的指标体系。

下面将逐个阐述一下各个优化目标的实施情况。聊天服务器在优化之前，在发言人数较多的情况会导致带宽占用过高，消息丢失，消息同步延迟等问题。这里举一个具体的例子。比如单教室10000学生，同时10%用户发送文字聊天，相互转发给其他学生。每条文字按照平均100字节计算的话，产生的带宽高峰为：100 1000 10000 * 8 = 7629Mbps。这会导致服务器带宽拥堵，而拥堵导又将致服务器缓存成倍增加，拖垮服务器。为了提升用户体验，必须降低对带宽的占用，并在网络条件不理想或者系统负载过高情况采用降级服务的方案。当时制定的总体改造原则有四个:

• 原则1：确保老师和管理员的发言，所有人都收到。
• 原则2：来自学生的发言，在系统高负载的情况下，不保证转发。
• 原则3：对于单个用户，网络条件不理想时，不保证转发所有学生发言。
• 原则4：学生分群（500人一个频道），学生发言只在群在转发。

通过这些改造，基本达到了预期的目的。改造后万人课的峰值带宽: 100 50 500 20 8 = 400Mbps，极大的降低了对于带宽的占用。

在移动互联网时代，开发客户端软件，最大的问题在于需要做很多个版本以适配各个平台和操作系统，开发直播工具也存在类似的问题，传统客户端界面开发有如下痛点:

1. 每个平台有自己的开发语言，如网页有Flash、Windows有C++、iOS有Object-C、Android有Java。
2. 信令服务器为了支持多平台，需要处理的协议种类众多，比如RTMP、XMPP、HTTP及其他各类自定义协议。
3. UI表现力单一、复杂界面开发成本极高，比如MFC。
4. 白板等功能开发难度大、移植成本高。

为解决这些问题，平台最终采用了HTML5技术来构建跨平台的统一客户端，HTML5主要负责业务逻辑、交互逻辑、UI表现。 同时将基础功能组件化，将移植工作变为适配工作。

在自建媒体服务器集群时，遇到了不少问题，比如：课程集中在晚上导致服务器利用率低，运营维护成本高昂，覆盖死角问题突出，调度策略复杂等。当某些地区到自建媒体服务器所在机房网络差时，还很容易造成卡顿和延迟。从下图可以看出，带宽大部分时间处于空闲状态，总体来讲性价比是比较低的。

如何提高资源利用率，降低成本，减少卡顿，提升用户体验，是急需解决的问题。而这些问题在大房间直播（同时在线用户数高）时更为凸显。经过调研，针对大房间直播功能我们增加CDN分发的支持。CDN分发有几个明显的优势：

1. 增加CDN后，形成自有服务器集群和CDN服务器集群相互备份，增加服务可靠性。
2. 各厂商CDN媒体转发服务的标准化程度、可靠性越来越高。
3. 同时推送多个CDN厂商，客户端选择最佳的CDN节点，能减少下行的卡顿率。

在增加完CDN分发支持后，统计数据显示整体的下行卡顿人数下降了20%，整体的下行卡顿次数下降了30%。整体的效果是非常明显的。当然CDN分发也带来一些问题，首先因为链路环节增加，导致整体延迟增加，不太适合互动性强的场景。对于加速支持的协议也有限，仅支持RTMP和HLS。另外基于DNS的调度的精准度不够也可能导致卡顿问题的加剧。

桌面共享方案主要有两种，VNC共享和视频采集与传输，这两种方案各有优劣，具体的指标对比情况如下。

从上表可以看出，视频采集和传输方案在开发成本更小，服务更加稳定。虽然在画质方面发挥空间不大，但整体是能满足用户观看需求的，另外其对于带宽占用的要求也比较符合当前的国内实际的网络状况。

做完这些优化之后，如何去评估这些优化动作的成果？这就需要建立一个有效的质量监控的指标体系。一般分两个层面，运营监控和技术关键指标。运营层面主要监控每日的课程情况，及时掌握课程信息，学生报名、到课情况等；实时的服务器质量监控，包括服务器CPU、内存、带宽、连接数量等；每日带宽流量分布、汇总情况；重点课程的提前提醒以及课堂异常实时触发客服系统产生工单。而技术层面则需建立质量体系，确定重点监控指标。

在指标体系建立之后，如何利用指标体系来做好质量控制了？结合监控目标可以从下面几个维度进行质量控制:

1. 进行小流量测试，通过统计指标，来确定各种技术改进的效果。
2. 每日课堂维度的指标，能够准确反映每个老师的上课质量，客服人员依据此提供针对性的支持服务。
3. 通过每日的指标分析，及时发现服务器、CDN的分布和运行问题。
4. 通过连续的指标跟踪，来确定整体运营质量。

从上图的监控数据可以看出直播的下行卡顿时长是有明显的下降的。

小结

限于篇幅，本文仅概要阐述了跟谁学平台在做平台架构技术选型时的一些思考和在开发直播工具的过程中踩过的一些坑，做过的一些尝试，以及如何优化的实践经验。希望对大家能有所帮助。