谢谢大家，首先自我介绍一下，我来自tutorabc，也就是原vipabc。我今天分享的题目是《TutorMeet+：基于Docker的高品质云课堂》，这套系统也是我们过去大半年时间一直重点研发的项目，我们主要是基于Docker平台打造一个高品质的互动云课堂。在这里也简单介绍一下自己，我是99年毕业，先到了深圳三九集团做了两年中药智能化机器人，后来又到了上海，05年的时候加入英孚教育 （EF），11年加入沪江，组建了架构和基础平台团队，包括后期我们做CCtalk服务端研发、移动端研发等，15年开始在途牛负责自助游的研发，16年底加入了tutorabc。

今天的分享大概分几个部分，首先简单回顾一下我们音视频直播在教育领域的发展的过程，我做互联网教育时间也比较久了（超过10年），我们很早就用到了WebRTC的技术，但是由于我们是垂直领域的分享，所以不会介绍太多实时音视频方面专业的东西，主要介绍的内容是我们tutorabc的TutorMeet+的一些特点，还有我们架构相关的内容，以及未来发展的计划。

音视频直播在教育领域的发展

说到互动直播实际上时间也蛮久了，最早的时候完全可以追溯到“9158”的时期，我相信应该有很多人知道，其实我们今天看到的很多美女直播的模式实际上它是最早尝试的，在FMS时代它可以说是一个做的规模最大音视频“直播”公司，好像在10年前就号称营收可以达到“十个亿”，当然后期也有一些其他领域的一个外延扩张。在FMS之前的时代，对于音视频互动直播来说，主要的核心技术可能只掌握在一些巨头的手里，比如Polycom、WebEx等公司，像WebEx后期是被Cisco收购了，当时有条件做直播的可能只有相当有实力的星星点点的几家公司。

1.FMS时代

在Adobe推出Flash Media Server（FMS）之后，大大降低了音视频直播的门槛，很多的做娱乐、通讯、教育、甚至非互联网的其他方面的一些公司开始尝试在线课堂这样的新教学方式，其实再早以前也有一些尝试，但都不是特别理想，可能早期9158把FMS用的特别“充分”，当然后期也是做了一些定制化的服务端开发，所以可能同时在线规模就会做得比较大。但是FMS还是有一些先天问题，比如说它是基于TCP（RTMP）连接的，所以它对网络稳定性的要求会比较高；另外由于基于FMS，它对系统整体的容量是有一些要求的，像一个教室或者会场，当人数比较多的时候，我们曾经测试过，可能人数达到千人左右的时候，就会crash，对架构、运维会有蛮大的挑战。

2.巨头时代（QQ&YY）

在后期的发展中，我们发现一些巨头的身影就出现了，像腾讯它是从IM（即时通讯）逐步过渡到音视频直播领域，包括像YY它是从语音通讯的社区，或者说游戏的工会社区，逐步也开始涉足互动直播，甚至自己做了100教育。而QQ它有自己的腾讯课堂，他们也在往教育方面发展，后期的服务器越来越强壮，基本上是基于Linux系统、用C++开发的，但是很多音视频的Client端还是走Native的，用户要使用需要安装。

3.移动时代

再后来我们都知道移动时代到来了，可能巨头在弯道的时候会有些迟缓，有一些创新性的公司就涌现出来，比如像映客、花椒等等，伴随这波“移动直播”大潮我们进入到全民直播的时代。

4.云时代

再后面有一些创新的公司，为了降低整个直播的开发门槛，比如：七牛、声网，他们做了大量的工作，搭建了云服务，研发了SDK，让直播这件事变得更容易，让大家集成起来更容易，做了很多有益的事情；但是个性化和服务品质始终是“云服务”比较大的痛点。

5.痛点

尽管音视频直播发展的会比较快，但是事实上也是有蛮多挑战的，这是某个媒体做的调查，我们可以看到事实上还是有很多的痛点，最关键的一个就是互动性不够，还有如何在保证课堂质量的情况下降低成本，毕竟带宽也是蛮大的一块，此外还有大班课和小班课，当然我们通行的做法是小班课用来教学，大班课侧重于营销，甚至做一些相应的活动。

对于教育而言，它自身有一些多元化的属性，比如说教语言的和教理科的可能不太一样，而教理科的可能和比如技术类、或者软件方面、甚至设计方面这种互动性要求更高的课程又会有所差别，所以它是一个越来越复杂的过程，而且线上和线下本身就有蛮高的差异性，比如线下教学过程中交互和沟通很方便，可能一个眼神或者一个表情，对方就能领略到一些信息，但是线上往往在这些方面是比较薄弱的。怎么把这些问题能够解决得更好，这个才是教育领域中音视频互动直播的一个挑战。接下来我介绍的内容会部分涵盖这些问题。

WebRTC概述

我们先简单聊一下WebRTC，大家都知道它是Google在2010年花费六千多万美金收购音频领域非常厉害的GIPS引擎，结合自身的一些技术之后，把它开源了。在WebRTC之前其实很多技术还是掌握在巨头手里，而且很多的标准都不统一，但是WebRTC有点像打造我们比较熟悉的安卓系统一样，一旦把它开源之后，就形成了一个很强大的业界标准和生态系统，包括推动了整个浏览器平台的向前发展。

1.优点

这个是WebRTC常用的一张图，我们可以看到紫色的部分是给做应用的开发人员的，让我们如何去定制它，它提供了比较好的JavaScript的一些API，然后我们可以通过JS去实现一个复杂的音视频的过程。此外它还给浏览器厂商提供了比较好的开放接口，像音视频捕捉的实现，它又可以做相应的差异化实现，而且他把最难的部分，包括Codec、P2P，还有我们常用的像回音消除、噪音抑制等等这些最难的部分都封装起来，作为整个引擎提供的一个标准的API，所以它相当于把开发门槛拉低了一大块，也促进了整个行业的发展。

2.不足

当然它也有些不足的地方，比如首先它对于服务端的实现就比较薄弱，因为可能Google会认为，一旦涉及到实现服务端，你肯定要跟自己的应用和业务做紧密的耦合，他不愿意做这样的事情，毕竟定制的太死会抑制它的发展，所以服务器是需要我们自己研发的；此外它应该还是以P2P为主，也就是一对一的场景，或者人少的情况下，它的通讯才会比较好，一旦我们要做一个几十人上百人甚至成千上万人的大课，它本身的支持就不是特别好，这块也是需要我们自己去实现的。

而且Native的开发门槛还是比较高的，因为你要编译Engine，实际上至少要DownLaod 10G以上的代码，在Build之前还要“翻墙”，要做各种各样的很枯燥的操作，如果做过这个的人估计都会比较了解。还有就是在复杂的网络条件下，因为它基本上是设计在像国外网络环境比较好的情况下，点对点能够比较稳定可靠通讯，像国内会有一些网络互通的问题、运营商利益的问题以及各种各样的奇葩问题，可能在这块也是会遇到一些难题。

但是好在Google也提供了相应的一些调试工具，像强大的Chrome浏览器，在Chrome浏览器里我们简单的输入一些命令（chrome://webrtc-internals/）就可以调出它一些相应Debug信息，像这张图就有涉及到mediastream和peerconnection的一些标准的对象的信息，包括相应的码率、通讯的数据情况等等，具体的如果感兴趣想了解的话，可以在网上的搜一些文章，包括声网也有相应介绍的文章。

3.WebRTC的拓展

这张图不太清楚，是我取了几个vipabc或者tutorabc的字符，通过mediastream get本地摄像头，给我自己拍了一张字符照片，这个项目也是开源的，大家可以在网上可以Download到，我们就不做Demo了，很简单，大家回去可以自己尝试一下。它的目的呢，就是通过WebRTC让我们的页面能够活动起来，也就是说我的资源不再是二维的，不再是平面的文字或者是图片，而是一个立体的、可以运动的一个载体，包括字符都是动起来的，当然你也可以加入其他的滤镜，比如说我做一个图像识别、戴一个帽子或者其他的，实际很多东西都可以通过它的接口来实现。

当然WebRTC也不仅仅是作用在直播方面，比如说像WebTorrent这个网站也挺有特点的，实际上它是利用了WebRTC的一些API实现了一个视频方面的P2P这样一个网站，在你浏览它首页的时候，就会发现在左边你Get的数据源是有多个的，它都是基于P2P网络的这样一些Node源，不是从固定的服务器来Get这个Video文件的，是蛮有意思的，而且它在也是Github上开源的，有兴趣的可以看一看它的代码是怎么实现的。

TutorMeet+ v1.0

下面我们就重点介绍一下TutorMeet+的一些相关的东西，我们还是以Chrome内核为主，因为前期团队人数有限，我也没有做太多的浏览器兼容方面的工作，主要还是把我们整个体系先做完整，当然我们也做了这个安卓和iOS的SDK。

1.浏览器端

基于浏览器有几个考虑，一个是我们看下来Chrome的市场占有率比较高，这是一个比较新的浏览器市场占有情况的报表，我们可以看到Chrome浏览器差不多已经占到60%的市场份额，而IE还应该会进一步下降，包括IE自己也在逐步的适配用Edge这些新型浏览器替换掉以前它一些比较老的机制或者模式。

一个好消息是苹果公司之前对WebRTC是比较抵触的，始终不是特别支持，前一阶段时间它终于第32个版本里把对WebRTC的支持加进去，这样的话包括微软、苹果和Firefox这几个浏览器巨头实际上全都支持了。

2.服务端

我们整个的Server端开发还是以C++和Go语言为主，为什么用Go语言呢？这个是要回到我们开发CCtalk服务端的时候，当时我们讨论最高效的方式是比如说用Python这类语言能够开发成一个比较好的数据访问层，或者是做一些很通用性的开发，需要C++的地方再用它开发，比如用C++来做音视频引擎方面的，这可以大大提升开发效率。但是当时因为Python本身的性能问题，而且它多核处理也不理想，所以我们没采用这个方案，但是非常想有这么一种语言既能解决C++开发效率的问题，同时能给我们有一个高性能的解决方案。

后来GO语言逐步成熟并且进入到我们视野，所以当我们开始构建TutorMeet+这个新的项目的时候，我们毫不犹豫的采用了以GO语言为主，C++做配合的模式来做开发，当然前端还是用JS。GO语言在我们整个项目里面担负了大量的控制、逻辑这方面的一些工作，表现还是非常出色。另一方面GO语言和C++之间天然的融合度还是比较好的，包括跟C语言之间，因为我们做音视频的C跟C++都要大量使用，而且GO语言的性能也确实非常好。我们做个简单的测试，比如像websocket的场景，我们当时是用一台很差的PC机，可能就只有两个核，在大概五千并发的时候可能还用不到一个核，大概也就用了零点几，性能是非常好的。

3.部署自动化

在整个项目的设计中，架构设计用到了大量的Docker，用Docker也给我们带来很多的好处，第一个好处就是我们整个运维和部署的成本大大降低，然后我们的发布里边很少出现在测试环境是OK的，然后到了生产环境就出现各种问题这类的情况，另外还有一点是用了Docker以后，我们整个的运维部署变得非常敏捷，之前我们做C++开发的时候可能有几十个服务，那时候要搭一套完整的系统出来的话可能要用几个小时，甚至一天都不止，现在可能几分钟就部署好了，很多的配置和发布都是自动化的，后面还会提到我们持续集成的一些东西。

4.音视频

对于音视频这块，因为我们用到WebRTC的技术，测试了一下，基本上在20%丢包甚至更高的情况下，仍然能保持比较好的音视频的流畅度，整体上还是表现非常不错的，我们的Codec用的VP8、VP9，甚至可以是H264，音频是AAC和OPUS。

5.录像回放

录像这块，因为我们的每堂课都是需要建立“录影档”的，考虑到这个量比较大，而且用户还需要回放，需要进一步的网络访问，我们做了比较精细的一个拆分：比如说老师的视频头像和音频，我们把它单独作为录影文件来存放，像其他PPT、IM等我们采用的是EvetLog这种方式做事件回放，这样就比较好的节省了我们存储的成本，还降低了用户的网络带宽。

6.桌面分享

桌面分享，实际上也是WebRTC本身提供的相应插件可以支持的，我们进一步改进了这个插件，在桌面分享的机制里面采用了P2P的技术，这样可以防止大数据量的东西，对服务器带宽产生比较大的挑战，当然这个功能还是在测试阶段，我们也在逐步完善，编码采用了H264和vp9。

7.万人在线大课堂

这是我们实现的一个大课堂，我们在一些云课堂的项目或者其他的一些公开课的项目里面一般不会设定很少的人数观看限制，我们通常会设定一个很大的课堂，让更多的人有机会来体验我们的课程、参与到我们课程之中，因此设计了这类的课程。

这张图片是一家小学，他们每个教室都有几十名学生，有多个教室同时上这种大课：老师在上海，学生在一个边远的地区或者师资教育资源不太发达的地区，我们可以给它提供在线课堂的服务。我们实现方式也是采用了一个旁路推流的方式，它不会对服务器产生比较大的负载，走的是另一条链路，可以通过CDN进行加速，也支持RTMP和HLS两种协议。

8.监控体系

当然如果要提供高品质的服务肯定是要有比较好的监控系统，和容易定位问题的一些手段，我们的数据跟踪也是分几个层次的，一方面我们会采集用户的实时网络状况的数据，另一方面我们对整个机器系统，包括Docker本身、我们的组件、服务API，都有比较详细的监控，这些数据都会被采集到我们系统里面实时的做分析，一旦有一些状况或者说有一些问题的话，我们会马上采取措施做及时修复，因为我们对用户有高品质的承诺，如果因为我们的技术问题，比如说一些系统打不开，或者是进不了教室，导致这个用户上不了课，假设超过5分钟，我们可能就会有经济损失要给用户退费之类各种的服务处理，正因为有这个承诺在，所以我们在这块也是投入了大量的精力，做了很多相应的系统。

9.全球部署

部署方面得益于我们这些年一直在线教育和音视频方面的一些积累，特别是我们的GIS部门投入了大量的人力和精力一直在寻找一个稳定、可靠，而且高品质的全球网络部署的方案，我们有一个可以联通全球的专用的网络，我们TutorMeet+也会架设在这样的网络上面，所以它的品质是有保证的。

10.支持混合云

同时还有一个特点，就是因为我们的部署非常敏捷，所以我们是既可以支持公有云，也可以支持私有云的。在我们的系统里面，我甚至可以把它设置成几个独立的系统，相互之间不产生任何影响，为了解决我们高峰时段某些课程会海量增加的用户，我还可以采用一些公有云的方案来做弹性的扩展，这些都是支持的。

TutorMeet+ v1.0架构

1.服务端开源架构

下面我们就聊一下架构方面，刚刚有讲到WebRTC的Server端没有提供一个标准的解决方案，虽然Google它有一个Demo站点-APPRTC.com，那个里面提供了一个可以做Demo的一个东西，当然那个东西是没法产品化的，所以我们也关注了一些目前开源的一些解决方案，包括JANUS、Licode、Kurento和Jitsi，这几个开源项目实际上各有特点，但是每一种都不太适合产品化，那我们也是采用了各方面的一些长处，然后综合搭建自己的系统，比如说像Kurento它有比较严重的内存泄露，它的承载能力也不是特别的理想；像JANUS它的设计者Simon Pietro Romano ，他也是《Real-Time Communication with WebRTC》这本书的作者，它也是意大利一个大学的教授，他们的架构设计是蛮好的，但是比较遗憾的是后端的实现会偏弱，功能也比较少，它基本上就设计成一个网关；还有像Licode的模块划分和MCU做得都蛮有特点。

这张图就是这几个项目的发展趋势，供大家参考一下，像Jitsi我没有仔细研究过，但是从图上大家可以看出来它项目的时间很长，但现在也是逐步向下走的一个趋势，当然它的功能还是蛮完善的。

这张图是Kurento的系统架构图，基本上分两个部分，左边是核心的媒体服务器，它基本上是基于GStreamer进行开发的，它的性能方面就会有些重，右边可以是NodeJS、可以是Java，它基本上做一些信令控制，还有包括像进出房间的这种控制性的放在这边，这个是Kurento的架构。

这张图是Licode的，不过这个不太好，是因为它本身画的图是动态的，如果感兴趣可以去看它的主页，会更清晰一些，它的架构大体上也分四个模块，其中一个跟Kurento很类似，它是负责媒体方面的，此外有的是负责建立房间、鉴权这种信令的，其他的可能是做控制的。

2.TutorMeet+架构

这个是我们的架构图，主要特点是我们大部分都是用GO实现的，在Load Balance里边，我们用到OpenResty做动态的负载平衡。下层我们把媒体服务和控制服务绑定成一个Unit，我们在整个系统里面可以划分不同的Unit，也就是不同的这种控制单元，我们在整个的外部做负载均衡，底层是依赖一些公用的服务模块，包括搜索、存储、MySQL，基本上是这么一个方案，然后外部可能有一些API访问进来，还有我们依赖外边的一些API，我们把它整体划分成一个API层，这块主要也是用GO实现的。

这个是我们内部的一套监控系统，我们认为如果要提供高品质的音视频服务，在这部分肯定需要更多的投入，所以公司设置了相应的部门专门负责点对点的，甚至端对端的对客户做技术支持和服务，这个也是我们高品质的有利的保障。从技术角度，我们则是要提供更多的智能化的，这种可控制的一些组件、平台，他们就可以通过这样的东西对用户的服务做各种各样的操作，比方说帮他远程转一下网络，或者调整一下音量等等。

这张图是我们部署的一个简单的拓扑，后面是我们的（监控）图，前面是我找的一个“假”的图，它比较简单，主要是为了说明问题，我们通过比较好的监控一些指标的设定，然后我们可以在整个拓扑里面很容易找到哪个节点出了问题，这样在复杂的系统里面，我们定位问题就会比较快。

这个主要是持续集成方面的，因为都是基于Docker的，比如说代码基于是GitLab，然后通过这个基础镜像Build之后再把它发布出去，大体上流程全都是自动化的，所以我们的发布会非常快，部署也会相应的比较敏捷。

未来发展计划

这是我们以后的一些发展思路，像我们现在用的容器越来越多，将来会逐步的采用比较通用型的容器编排，或者容器管理的一些东西，包括像K8s、Swarm这些技术我们也在逐步的去摸索，搭建符合自己要求的内部系统。还有就是我们也在尝试建一些轻量的客户端，防止有一些人可能就是比较排斥Chrome，不愿意装其他浏览器，方便我们来解决这种问题；此外还有WeChat，我觉得在移动端的浏览器里边，微信端的浏览器占了蛮高的市场份额，所以我们逐步的也要支持它；最后就是一些前端的升级改造，其实前端的工作量也非常巨大，毕竟是音视频通讯的东西，不是一般简单的页面渲染、动态的效果，它对前端的要求是比较高的，所以前端采用的框架和技术，我们也是做了大量重新梳理或者是重构的工作，都是用“万”（行）来计算的代码数量。

最后，我们基于了很多开源的技术，也是非常感谢开源社区，让我们能够集中精力做真正教育领域内的事情，然后我们也是希望在有了一定余力之后逐步的回馈开源，把我们的一些东西也可以逐步反哺给开源社区。以上我讲的内容就结束了，感谢大家！