關(guān)于CCtalk

CCtalk是滬江旗下的支持互動教育平臺，它提供網(wǎng)師服務(wù)，支持老師簽約入駐，擁有基于云，大數(shù)據(jù)和AI的個性化課程推薦，同時也支持社群化學習，可以通過課前預習，課后答疑和視頻回放等來沉淀學習用戶，而且還有非常豐富的教學工具，包括實時多向音視頻服務(wù)，雙向白板，屏幕分享，講義，教學小工具等等。

今天我會從五個方面來給大家介紹：

1，主流直播方案介紹

2，客戶端AV引擎

3，服務(wù)端架構(gòu)演進

4，錄制回顧以及旁路推流

5，高并發(fā)場景案例分析

1、主流直播方案

主流的直播方案，我把它分為四類：RTMP，HTTP-FLV，HLS和RTP

下面介紹一下各自的特點：

1）RTMP

RTMP的優(yōu)點是CDN加速成熟，成本低，可用的開源庫，以及開源工具比較多，延遲一般在2到5秒。

2）HTTP-FLV

HTTP-FLV的原理是服務(wù)器在響應(yīng)HTTP請求時候，不返回Content-length字段，它使用HTTP協(xié)議來實現(xiàn)，不容易被防火墻攔截，延遲略低于RTMP，但都是秒級的。

3）HLS

HLS的優(yōu)點是CDN分發(fā)容易，成本低，可以在HTML5頁面中直接打開觀看，但它延遲一般大于12秒。

4）RTP

RTP一般是各家自研，相比于傳統(tǒng)的直播方案來講，自研方案不支持CDN加速，且成本貴，延遲一般是200到800毫秒之間。

2、客戶端AV引擎

教育直播-CCtalk是基于RTP協(xié)議自主研發(fā)的，它的傳輸層支持UDP和TCP兩種方式，支持網(wǎng)師之間以及任意觀眾之間的連麥互動，連麥延遲和觀眾延遲都是毫秒級的，同時它支持PPT，白板筆，答題卡，文字等多種不同形式的教學互動。下面介紹CCtalk的軟件架構(gòu)圖：

從圖中可以看到，所有的客戶端與信令系統(tǒng)之間有一個TCP長連接，來實現(xiàn)PPT、白板筆、答題卡、文字聊天等等教學相關(guān)的小工具；所有的用戶與媒體服務(wù)之間有一路TCP或UDP的連接，實現(xiàn)老師與學生之間的雙向?qū)崟r音視頻互動，比如說老師上課的時候，將產(chǎn)生的實時音視頻數(shù)據(jù)發(fā)送到媒體系統(tǒng)，媒體系統(tǒng)按照一定的路徑將媒體數(shù)據(jù)發(fā)送到學生端；如果學生端也上麥了，那么學生端產(chǎn)生的音視頻數(shù)據(jù)也會經(jīng)過媒體系統(tǒng)轉(zhuǎn)發(fā)到老師端，這樣就完成了一個教學場景下的雙向音視頻互動。同時，媒體服務(wù)會旁路推流一路RTMP到CDN，學生端可以在HTML5網(wǎng)頁里直接觀看實時單向直播，這樣就滿足了在大型直播中網(wǎng)頁傳播的訴求。另外媒體服務(wù)器會將上課時產(chǎn)生的音視頻數(shù)據(jù)發(fā)送一路到錄制服務(wù)，同時信令系統(tǒng)會將上課時產(chǎn)生的PPT、白板筆以及文字聊天等內(nèi)容發(fā)送一份到錄制服務(wù)，錄制服務(wù)收到所有上課內(nèi)容后，將它們以元素的形式存儲下來，存儲下來的這個格式叫做OCS回顧，便于課后回顧。

因此教育直播架構(gòu)須具有的以下特性才能滿足需求：

而CCtalk就是這么一個支持多種教學工具的實時大規(guī)模并發(fā)教學平臺。在最開始實現(xiàn)這個平臺的時候，我們采用了一些開源方案，如webrtc，但后來發(fā)現(xiàn)直接使用開源方案無法為完全滿足教育直播的需求，因此我們自研發(fā)了一套客戶端AV引擎：

下面我會針對引擎的網(wǎng)絡(luò)部分做一個簡單的介紹，主要介紹用到的幾個關(guān)鍵的技術(shù)。首先思考一個問題：當客戶端在使用媒體引擎的服務(wù)時，需要做的第一件事是什么呢？

答：需要找一個網(wǎng)絡(luò)質(zhì)量較高的邊緣節(jié)點接入。

如上圖所示，假如我們有一百個邊緣節(jié)點，用戶需要從這一百個里面選一個到他的網(wǎng)絡(luò)質(zhì)量較高，那么該如何選擇呢？可能你首先想到的是DNS解析，但其實只靠DNS解析是不夠的，我們還需要一套自動尋路機制，如下圖所示：

以小網(wǎng)絡(luò)為例，它的每次DNS解析的結(jié)果可能是變化的，我們無法保證它尋到的結(jié)果一定是最優(yōu)的。當用戶接入到邊緣節(jié)點之后，在使用過程中，用戶的網(wǎng)絡(luò)在不斷變化的，因此我們還需要有一個動態(tài)檢測的機制，如果引擎檢測到網(wǎng)絡(luò)波動較大的情況，那么需要再次啟動自動尋路機制，再給它找一個網(wǎng)絡(luò)質(zhì)量較高的邊緣節(jié)點接入。此外，由于網(wǎng)絡(luò)一直在變化，為了適應(yīng)這種不斷變化的網(wǎng)絡(luò)，我們還需要一套擁塞控制機制，在這里我推薦Google的GCC擁塞控制算法：

這個擁塞控制可以分為發(fā)送端基于丟包的網(wǎng)絡(luò)估計，以及接收端基于延遲的網(wǎng)絡(luò)估計兩部分，總結(jié)下來，就是根據(jù)丟包率以及延遲控制發(fā)送端的碼率。除此之外，當我們的碼率開始降低的時候，是不能一直降低下去的，因為碼率降低意味著音視頻質(zhì)量的下降。我們還需要另外一套補充機制，叫做消峰處理：

消峰處理的原理是將比較大的數(shù)據(jù)分成若干個包，在一定時間內(nèi)發(fā)送出去。但這會帶來延時的增大，因此需要控制發(fā)包的間隔大小。最后，當數(shù)據(jù)在傳輸當中由于誤碼等因素導致丟包時，我們還需要丟包重傳的機制來進一步的提升網(wǎng)絡(luò)的質(zhì)量。總結(jié)下來，其實整個客戶端引擎的網(wǎng)絡(luò)部分，其實就是在做一件事：在實時性與質(zhì)量之間權(quán)衡，而且這個權(quán)衡具有一定的自適應(yīng)能力。

3、服務(wù)端架構(gòu)演進

這張圖的上半部分在前面已經(jīng)介紹過了，就是客戶端的引擎部分，下半部分是對應(yīng)的媒體服務(wù)器的一些功能。最初的CCtalk服務(wù)系統(tǒng)是由第三方提供的，開發(fā)簡單，成本低，但確實存在一些問題。后來我們自主研發(fā)了一套服務(wù)端體系，架構(gòu)如下：

這個架構(gòu)分為兩大部分：信令系統(tǒng)和媒體系統(tǒng)，整個架構(gòu)中的所有服務(wù)設(shè)計功能單一、結(jié)構(gòu)簡單，并且所有節(jié)點支持線性擴展，理論上它能承載的人數(shù)是沒有上限的，你只要加機器就可以了，所有的節(jié)點支持失效自動轉(zhuǎn)移，這套系統(tǒng)我們用了很長一段時間，但在使用的過程中還是發(fā)現(xiàn)了一些問題，以媒體系統(tǒng)為例，首先一個是問題是存在中心節(jié)點，這就意味著所有的數(shù)據(jù)都要先經(jīng)過代理節(jié)點轉(zhuǎn)發(fā)到中心節(jié)點，再發(fā)送到代理節(jié)點，最后發(fā)送到學生端，并且這個路徑是固定的，所有的數(shù)據(jù)都要走這么長的路徑，此外，系統(tǒng)之間有一定的耦合。為了解決這些問題，重新設(shè)計了新的媒體架構(gòu)：

首先，我們把信令系統(tǒng)與媒體系統(tǒng)之間解耦，也就是說他們之間相關(guān)的操作如加入房間，建立房間，全部放在客戶端的AV引擎去實現(xiàn)；另外，我們?nèi)サ袅酥行墓?jié)點，加入了轉(zhuǎn)發(fā)節(jié)點的概念，所有的轉(zhuǎn)發(fā)節(jié)點都是對等的，并且轉(zhuǎn)發(fā)節(jié)點會將收到的音視頻數(shù)據(jù)通過一個智能尋路算法自動找一條最優(yōu)的路徑。

整個媒體系統(tǒng)設(shè)計原則有兩點：一是盡最大的可能找一條最優(yōu)的路徑，將數(shù)據(jù)盡快的發(fā)送到對端；二是在服務(wù)出現(xiàn)問題的時候，盡量的保證服務(wù)的可用性，并且讓用戶沒有感知。

4、錄制回顧以及旁路推流

下面講一下錄制回顧以及旁路推流，架構(gòu)如下：

具體如下，當 Server收到指令以及數(shù)據(jù)時，會將音視頻數(shù)據(jù)發(fā)送到服務(wù)端的音視頻引擎，服務(wù)端的音視頻引擎會對這些數(shù)據(jù)做一些處理，壓縮成一個大視頻，將大視頻存成MP4，并保存到云端，同時，將這個實時的視頻流以RTMP的形式推到CDN，這樣，HTML5頁面就可以在線觀看實時的網(wǎng)頁直播；同時媒體錄制服務(wù)器會將上課時產(chǎn)生的所有內(nèi)容以元素集合的形式存儲一份，我們把這個存儲格式叫做OCS。下面就是直播或錄播的流程圖：

錄制OCS回顧視頻過程如下：

我們還有一套專門的OCS編輯器來幫助對OCS回顧進行二次編輯，編輯器可以將編輯之后的結(jié)果再次傳到云端，這樣學生就可以觀看編輯之后的內(nèi)容。

在這個過程中，我們使用的轉(zhuǎn)碼服務(wù)，前期用戶量不大的情況下，我們使用CPU轉(zhuǎn)碼，單臺16核的機器的并發(fā)數(shù)量可以達到40路，后面隨著業(yè)務(wù)增長，對于轉(zhuǎn)碼集群的要求不斷增大，所以我們改用了GPU轉(zhuǎn)碼，并發(fā)情況如下：

5、高并發(fā)場景案例分析

高并發(fā)場景的案例分析，這一部分與實際的音視頻沒有太大的關(guān)系，但卻存在教育場景當中不得不面對的一些問題，我首先舉個例子，希望能夠?qū)Υ蠹矣幸欢ǖ膯l(fā)。我們來想一個問題：同一個教室里，有20萬人同時在聽課，我們會遇到哪些問題，我們該如何解決這些問題？假設(shè)有20萬人在同一個房間，每個人攜帶的數(shù)據(jù)量是30字節(jié)（例如：用戶列表、用戶ID、昵稱等等），假設(shè)每臺網(wǎng)關(guān)承載三千人，那么至少需要66臺網(wǎng)關(guān)，正常情況下，假設(shè)每秒有800人進出房間，那么負載到每個網(wǎng)關(guān)上就是12人每秒的瞬間吞吐，所以算下來當有一個用戶進房間，那么他拉取的這個數(shù)據(jù)量就是45Mb，他進房間的這一瞬間需要拉這么多的數(shù)據(jù)，每臺網(wǎng)關(guān)承載的實時的吞吐量是554Mb，當出現(xiàn)異常時，比如說某臺網(wǎng)關(guān)宕機或者脫離了核心服務(wù)，我們的負載均衡服務(wù)會將出現(xiàn)的問題的至少三千人負載到剩余的64臺服務(wù)上，此時的網(wǎng)關(guān)負載增量是46.8人，異常時的網(wǎng)關(guān)瞬間流量是2Gb?？偨Y(jié)下來存在的問題如下：

1）客戶端帶寬消耗太大

2）進入教室慢

3）服務(wù)并發(fā)處理量太大

那么，我們的應(yīng)對策略是：

1）精簡信息+詳細信息

2）提供數(shù)據(jù)的版本機制，在一定范圍內(nèi)，只處理變化的數(shù)據(jù)。