連麥互動直播方案全實踐 3：網易雲信連麥互動的實現方案

毫無疑問直播是當前移動互聯網最熱門的領域之一，在超強熱度的引導下直播領域也吸引了大量的商業資本。在各大直播應用萬花齊放的時刻，也正是直播應用面臨的真正風口。站在這個風口上，直播應用只把握好風向標，推出具有高用戶粘性的差別化功能，才能在這個不斷推陳出新的時代站穩腳跟，得到不可動搖的地位。
《連麥互動直播方案全實踐》系列文章基於網易雲信的摸索和實踐，從場景、流程到方案、架構，對直播體驗深度優化方案——「連麥互動直播」進行了全面的講解和介紹。

相關閱讀推薦：
連麥互動直播方案全實踐1：什麼是連麥互動直播？
連麥互動直播方案全實踐2：網易雲信連麥互動直播方案的演變過程

接下來咱們來看看網易雲信全新的連麥互動直播方案具體是怎麼實現的？咱們從架構圖中能夠看出，整個連麥互動直播主要由兩大模塊組成，實時音視頻系統和互動直播服務器系統。

實時音視頻系統

首先咱們來看一下實時音視頻系統。實時音視頻其實就是基於網絡的，可以進行音頻或者視頻，低延遲的雙人或者多人之間的實時通話。像 Skype， Facetime，微信，易信都提供了實時音視頻通話功能。在互動直播中，實時音視系統主要是爲了實現低延遲連麥功能。

咱們來看下實時音視頻的架構圖：

各平臺客戶端使用客戶端 SDK 接入實時音視頻系統，包括：iOS，Android，PC 和嵌入式設備。
客戶端與業務服務器集羣維持一條 APP 協議長鏈接，使用加密的 TCP 私有協議做爲交互協議，主要用於相關業務的發起、通知推送等等。業務服務器集羣包括用戶加速接入的邊緣鏈接服務器，包括用於爲用戶智能分配全球媒體服務器節點的分配服務器。客戶端經過 APP 協議從分配服務器得到媒體服務器地址之後，就進入實時音視頻的媒體和網絡流程。
爲了更直觀的說明，架構圖裏展現的是單向流程。左側是發送方，右側是接收方。發送方的編解碼進行音視頻採集、音視頻預處理，而後進行音視頻的編碼，隨後進入網絡層，在作完私有協議的封包、傳輸可靠性的保障之後，使用加密的 UDP 私有協議做爲傳輸層協議，將數據包發送到分配服務器根據智能算法分配的媒體服務器集羣。經過邊緣加速節點到達核心媒體中轉服務器，媒體中轉服務器負責將數據包轉發給同一會話的其餘用戶。
接着咱們來看接收方。接收方一樣使用加密 UDP 私有協議，接收方的網絡層收到媒體中轉服務器發過來的數據包，自底向上首先進行私有協議解包，而後作相關的網絡層 QoS 保障。網絡層處理結束之後將完整的音視頻編碼數據回調編解碼層。在編解碼層中，首先進行音視頻的解碼，而後相關音視頻後處理，最後將處理完的音頻進行播放，並在界面中繪製出視頻畫面。
這樣就完成了一次音視頻數據的單向交互，反向的流程一致。另外咱們看媒體服務器集羣中除了最關鍵的是中轉服務器。還有錄製存儲服務器用戶將通話過程當中的音頻和視頻錄製下來，並存儲到雲端。而統計分析服務器用於分析統計用戶的通話質量與系統的運行狀態，爲優化實時音視頻的通話效果頗有幫助，同時對於節點分配服務器的策略也有相應參考。
實現的這套實時音視頻系統的幾大技術要點，主要包括下面四個部分：網絡、音頻、視頻和適配。

有了上面實時音視頻部分的介紹，咱們就爲連麥互動直播的低延遲連麥打下堅實的基礎了。

互動直播服務器

互動直播服務器的功能主要是：

1. 進行互動直播中主播與連麥者的畫面合成；
2. 對接 CDN 流媒體服務器

互動直播服務器的要點主要是：融合實時系統與直播系統；實時處理視頻的合成；保證互動同步性以及高性能硬件。
下面咱們來簡單看一下互動直播服務器的多線程異步架構。

互動直播服務器主要由一個 IO 主線程、多個工做子線程和多個推流線程池組成。
IO 主線程負責建立 UDP 監聽 fd，並註冊可讀事件到 eventloop 事件循環中。中轉服務器將音視頻數據轉發到主線程監聽的端口上，eventloop 可讀事件回調，IO 主線程負責讀取內核UDP緩存中的將數據包，並根據哈希算法放入到與工做子線程一一對應的臨時隊列中。當內核緩存被讀空之後，IO 主線程會觸發 eventloop 監聽在 eventfd 可讀事件的各個工做子線程。而後經過閉包的方式將各個主線程臨時隊列裏的數據派發到相應的工做子線程中處理。
工做子線程從隊列中依次取出數據包，對數據進行協議解包，進入協議分發器，進行業業務邏輯的拆分，對於音頻數據進行丟包處理，而後會由 jitterbuffer 算法來平滑抖動並解碼成 pcm 數據；對於視頻會一樣會進行丟包處理，而後進行視頻解碼成 yuv 數據，視頻部分還會作一步和音頻的同步操做。以後會進行每一個房間的多路音頻 pcm 數據的混音和多路視頻 yuv 的混合。混音結束之後會將 pcm 數據再編碼爲 aac 而後調用 aac 推流，視頻 yuv 數據編碼爲 H264 之後調用 H264 的推流。
推流線程池負責講 aac 和 h264 的裸數據按照 FLV 的格式進行封裝，而後使用推流網絡IO將音視頻包使用使用 RTMP 協議推送到 CDN 流媒體服務器。
普通觀衆可使用 RTMP 拉流地址向 CDN 流媒體服務器拉取音視頻流完成連麥互動直播的收看。
咱們看到咱們只有一個 IO 線程來處理 IO 讀操做，這樣作的目的主要是保證咱們的 IO 不受音視頻編解碼的影響，咱們會把 IO 線程綁定在特定的 CPU 上。
工做子線程也會綁定對應的 CPU 核心，這麼作也是爲了提升性能。綁定之後，性能大概能夠提升20%。主要是由於工做子線程是超高計算密集型的，對 CPU 的壓力很大，若是不綁定，線程就有可能在不一樣的核心上切換，致使相應的性能損失。

服務器部署和智能分配

講完了上面兩大系統各自的功能和實現細節之後，咱們還缺乏什麼呢？
咱們的服務是要部署在咱們服務器上，而服務器的部署和分配在連麥互動直播裏相當重要，那咱們接下來就來看服務器部署和智能分配方面有哪些要點。
首先爲了可以爲全球的用戶提供優質服務，全球範圍的節點部署是必不可少的。以網易雲信的經驗，依賴網易在全球的機房，咱們在國內部署多個 BGP 機房和三線機房，對於海外咱們部署了海外節點，特別爲了優化跨國聊天，咱們還使用跨國代理的光纖專線。
第二，在有了這麼多節點之後，就須要由一個節點的智能分配策略。須要根據用戶的地理位置、用戶的運營商 ISP 類型爲用戶分配最佳接入的節點。固然分配的時候還須要考慮服務節點的實時負載狀況和實時的網絡情況。
第三，單純的服務端的節點分配是不夠的，客戶端還須要配合使用智能選路策略。根據各鏈路的丟包和時延，智能選擇最佳鏈路。同時當某條鏈路中斷後，還會切換到另外一條鏈路上。鏈路的切換是透明的，對上層用戶無感知，也就是通話不會受到影響。
第四，爲了保證整個實時音視頻服務的高可用，咱們的全部服務器均使用高可用的架構部署，因爲音視頻服務器對網卡是高需求，咱們 80% 的服務器使用了配備萬兆網卡的高性能物理機。同時對於服務器宕機、網絡切斷，都使用了相應的恢復和策略切換，全部這些都爲了咱們實時音視頻服務的高可用。

以上就是網易雲信全新連麥互動直播方案的具體實現方法，歡迎你們留言，與咱們互動交流。

---

隨着即時通信以及音頻處理和壓縮技術的不斷髮展，效果更好、適用範圍更廣、性能更高的算法和新的技術必將不斷涌現，若是你有好的技術或者分享，歡迎關注網易雲信官方博客和 GitHub：

關注更多技術乾貨內容： 網易雲信博客
歡迎關注 網易雲信 GitHub
歡迎關注 網易雲信官網