疫情期間陪兒子上網課 順道猜測了下後臺的大概架構
先上張網校截圖，我標註了界面上大概的功能分區
從界面分析，後臺大概的數據分爲以下幾種
1 主流 一般是代課老師的攝像頭流
2 輔助流 一般是帶課老師電腦上課區的截屏 ，
3 聊天區
4 跨房價PK區
5 其他富媒體 包括各種小遊戲
6 連麥 現在實現的連麥 只有音頻連麥功能 完全能滿足這種場景的需求
7 答題
網校這個課的特點是，老師一帶多 一個老師可以帶多個房間 具體分析爲
1）主流 輔助流 連麥 本身沒有房間的概念 是跨房間存在的
2）聊天不跨房間 學員只能看到本班級所在的房間的信息 但是 老師可以看到所有房間的聊天 這個不知道怎麼做到的
3）答題 跨房間 統計結果也是跨房間存在的
4）各種富媒體 小遊戲 也是跨房間的
總結下來 就是出來班級聊天有房間的概念 其他數據基本淡化了房間之間的劃分
我大概畫了下可能存在的後臺架構圖
說明下這個圖
1）整個架構 分爲四個服務集羣 配置服務 統計服務 媒體服務 聊天服務
2）配置服務的功能是把流信息和房間信息做配對 在直播開始前 由後臺配置好哪個房間獲取那些流 在學生登陸後 獲取這些信息然後拉取對應的流
3）媒體服務器 媒體服務器負責所有媒體流信息的交換 包括直播主流 輔助流 連麥流
4）聊天服務器 輔助各個房間的聊天信息 房間的概念 只存在於這個集羣中
5）統計服務 輔助從聊天信息中統計答題結果 併發送給各個房間服務器
現在不太能確定是以下幾個方面
1）連麥功能是怎麼實現的 有以下幾種猜想
服務器在收到學生和老師音頻後混音發出 相當的複雜 估計不是這樣的
不混音 學生端都拉取參與連麥的音頻 然後本機混音 太簡單 耗費流量 而且同步性難於保證
老師拉取參與連麥的學生的音頻 然後在老師端負責混音發送 實現簡單 同步性可以保證 唯一的卡點就是對老師端的電腦 帶寬要求比較高 但這個可控
2）答題這條路 還沒搞清楚 猜測如下
應該是走特定的聊天信息，然後這個特殊信息在統一發送到統計服務
基本分析就是這樣的 。以前在VIPKID的時候 開發過小班課這種形式 當時一直比較困惑的是老師怎麼跨房間代課，這次通過分析網校的課 給了一中新的思路