摘要：連麥互動直播方案全實踐系列文章基于網易云信的摸索和實踐，從場景流程到方案架構，對直播體驗深度優化方案連麥互動直播進行了全面的講解和介紹。

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

相關閱讀推薦：
連麥互動直播方案全實踐 1：什么是連麥互動直播？
連麥互動直播方案全實踐 3：網易云信連麥互動的實現方案

《連麥互動直播方案全實踐》系列第一篇文章介紹了什么是連麥互動直播，現在我們來看一下網易云信在連麥互動直播方案的演變過程。我們從2015年年初就開始研究連麥互動直播技術，提出了一個在主播客戶端合流的方案。后來隨著移動端直播的快速興起，我們在老方案的基礎上，迭代推出了一個新方案，也就是服務端合流方案。
接下來我會為大家詳細闡述這兩個方案的具體實現方式，并且分析各自的優勢、劣勢以及適用的場景。

主播端合流方案

首先我們來看一下老方案，我們稱之為：主播端合流。

傳統的直播流程是：主播客戶端采集并編碼音視頻數據以后，直接使用RTMP協議推流到CDN，其它觀眾使用對應的拉流地址向CDN拉取音視頻流。
該方案我們不改變由主播來推流這個架構，只是在主播需要與觀眾連麥互動時使用實時音視頻系統來進行主播和觀眾的實時互動連麥，通過實時通話通道主播端收到觀眾端發送的音頻和視頻數據，主播端將自己的聲音和觀眾的聲音做混音，并將自己的畫面與觀眾的畫面做視頻合成，最后主播將混合的聲音和畫面推流到CDN流媒體服務器。通過這種方式就實現了觀眾與主播的連麥互動直播。

那么這個方案有什么優缺點呢？

由于上述兩個問題，該方案并不是移動端上連麥互動的最佳方案。
為了解決這兩個問題，我們團隊用3個月時間來做技術攻關，設計并開發了一個替代方案。

服務端合流方案

這個全新的連麥互動直播方案，作為優化替代方案，方案的關鍵是：主播不再直接推流到CDN流媒體服務器，而是基于實時音視頻通話系統，由實時音視頻的中轉服務器轉發給互動直播服務器，再由互動直播服務器處理后推流到 CDN 流媒體服務器，互動直播服務器是我們為方案二全新研發的一個服務器。
音視頻實時通話系統，可以實現多人的實時互動，而且多人模式下所有的數據包都是通過音視頻中轉服務器中轉。此時如果觀眾需要與主播連麥互動，只需要讓觀眾加入到實時音視頻的房間中，音視頻中轉服務器在轉發給房間中其他客戶端的同時，轉發一份到互動直播服務器，互動直播服務器對收到的語音進行混音，同時對視頻畫面做混合處理，處理完畢以后再推流到 CDN 流媒體服務器。
通過這種方案，將方案一中由主播端做的混音混合及推流操作，轉嫁由互動直播服務器來承擔。對于普通觀眾不需要其它額外的處理邏輯就能在原來的拉流地址上拉取到連麥互動的直播畫面。

那新方案有哪些優點？

簡單的提一下，有些 APP 使用不同與上述兩種方案的其它方案來實現連麥互動直播。也就是主播和連麥者分別發送一路 RTMP 流到 CDN 服務器，觀眾端通過分別拉取主播和連麥者的兩路流來實現連麥互動直播。
這個方案的問題是：RTMP 協議延遲很高，一般至少在3秒，主播和連麥者之間使用 RTMP 協議來做連麥互動，互動的實時性是不可接受的。同時普通觀眾要拉取兩路流，功能流程會變得復雜，同時還增加了普通觀眾的下行壓力。
由于這兩個問題，該方案不是一個合格可行的低延遲連麥互動方案。

那么網易云信全新的連麥互動直播方案具體是怎么實現的呢？《連麥互動直播方案全實踐》第三篇文章將會向大家詳細介紹。

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

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