某网校媒体后台实现猜测

疫情期间陪儿子上网课 顺道猜测了下后台的大概架构

先上张网校截图，我标注了界面上大概的功能分区

 

从界面分析，后台大概的数据分为以下几种

1 主流 一般是代课老师的摄像头流

2 辅助流 一般是带课老师电脑上课区的截屏 ，

3 聊天区 

4 跨房价PK区

5 其他富媒体 包括各种小游戏

6 连麦 现在实现的连麦 只有音频连麦功能 完全能满足这种场景的需求

7 答题

 网校这个课的特点是，老师一带多  一个老师可以带多个房间 具体分析为

1）主流 辅助流  连麦  本身没有房间的概念 是跨房间存在的

2）聊天不跨房间 学员只能看到本班级所在的房间的信息 但是 老师可以看到所有房间的聊天 这个不知道怎么做到的

3）答题 跨房间 统计结果也是跨房间存在的

4）各种富媒体 小游戏 也是跨房间的

总结下来 就是出来班级聊天有房间的概念 其他数据基本淡化了房间之间的划分

我大概画了下可能存在的后台架构图

说明下这个图

1）整个架构 分为四个服务集群 配置服务  统计服务 媒体服务 聊天服务

2）配置服务的功能是把流信息和房间信息做配对 在直播开始前 由后台配置好哪个房间获取那些流 在学生登陆后 获取这些信息然后拉取对应的流

3）媒体服务器 媒体服务器负责所有媒体流信息的交换 包括直播主流 辅助流 连麦流

4）聊天服务器 辅助各个房间的聊天信息 房间的概念 只存在于这个集群中

5）统计服务 辅助从聊天信息中统计答题结果 并发送给各个房间服务器

 现在不太能确定是以下几个方面

1）连麦功能是怎么实现的 有以下几种猜想

    服务器在收到学生和老师音频后混音发出  相当的复杂 估计不是这样的

   不混音 学生端都拉取参与连麦的音频 然后本机混音    太简单  耗费流量  而且同步性难于保证

   老师拉取参与连麦的学生的音频 然后在老师端负责混音发送  实现简单 同步性可以保证 唯一的卡点就是对老师端的电脑 带宽要求比较高  但这个可控

2）答题这条路 还没搞清楚 猜测如下

  应该是走特定的聊天信息，然后这个特殊信息在统一发送到统计服务

 基本分析就是这样的 。以前在VIPKID的时候 开发过小班课这种形式 当时一直比较困惑的是老师怎么跨房间代课，这次通过分析网校的课 给了一中新的思路