【轉】SFU級聯解決方案——Licode

文章目錄

• • 1. 引言
  • 2. SFU
  • • 2.1 SFU簡介
    • 2.2 單SFU問題
    • • 2.2.1 人數限制
      • 2.2.2 地理分布，就近接入
    • 2.3 解決方案：級聯SFU
    • • 2.3.1 解決人數限制
      • 2.3.2 解決地理分布與就近接入問題
  • 3. Licode
  • 4. 基于Licode級聯實作
  • • 4.1 單節點Docker化
    • 4.2 級聯間去加密
    • 4.3 其他級聯優化
    • 4.4 全球化
  • 5. 參考資料

1. 引言

随着線上教育行業的興起， 許多人把目光投向了國外市場，而如何搭建全球化的音視訊網絡就成為了其中的關鍵問題。百家雲研發工程師陳聰詳細介紹了如何利用Licode 開源伺服器搭建全球分布式架構以解決常見的教育場景的問題。

Licode的WebRTC全球分布式架構相關的技術分享。之是以想為大家介紹這個架構，是因為我在使用WebRTC開源伺服器時發現WebRTC并沒有提供類似于分布式或叢集的整體解決方案，希望在此領域的探索能為大家帶來有價值的幫助。

2. SFU

2.1 SFU簡介

SFU全稱為Selective Forwarding Unit，我們可以将其原理簡單了解為将一條流推給多個端并且在整個過程中不對視訊進行編解碼處理。相對于其他傳統的需要重新編解碼的解決方案而言，其優點在于低延遲、低消耗。當然，單SFU的缺點也顯而易見。

2.2 單SFU問題

2.2.1 人數限制

單SFU面臨的第一個問題是人數限制，主要出現在像“雙師課堂”這種較為常見的教育場景中。在此場景中，一位老師為多名學生教學，多名學生接收由老師端發送的流。有時在“雙師課堂”中容易出現老師端碼率較高的情況，以1080p、30FPS的情形為例，此時一位學生所需帶寬為3.5MB；如果有兩百位學生線上觀看則單個伺服器的出口帶寬就會達到700MB左右，并且随着學生人數的增加，所需出口帶寬越來越多；而單個SFU的帶寬是有限制的，如我們常用的阿裡雲、騰訊雲的帶寬在300～500MB左右。由于單個伺服器的帶寬限制，單節課同時線上人數便無法達到一個較為理想的規模。

2.2.2 地理分布，就近接入

地理分布與就近接入是我們在探索單SFU中面臨的第二大問題，此問題主要出現在“小班課”的教育場景。雖然與“雙師課堂”相比“小班課”在人數上沒有那麼大的規模，一般情況下一節課線上人數為6～15人，但由于在此場景中老師與學生的地理跨度較大，也許分布在世界各地。這就使得我們必須選擇品質高擴充廣的伺服器作為接入點。可由于單SFU的原因，我們隻能選用相對于所有使用者較好的伺服器，如上圖我們選用上海的伺服器。但這也導緻距離伺服器較遠位置的使用者相對于伺服器所在地的使用者其感受到的延遲更為明顯。

如果将使用者拓展到全球範圍來看的話，那麼由其造成的延遲問題就更為明顯。如上圖情況，學生在中國而老師在美國的話，學生看老師就會增加2倍的跨洲延遲。同時，高延遲除了造成視訊的卡頓、丢包，還會造成流量的浪費。如果不解決這些問題，我們便無法部署一個性能優異的全球化分布式網絡架構，那麼如何解決這些問題呢？

2.3 解決方案：級聯SFU

我們的思路是通過級聯SFU而非單SFU解決上述問題，也就是将SFU互相級聯後，使用戶端釋出的流經過另一個SFU轉發，其它用戶端再從另一個SFU訂閱。

2.3.1 解決人數限制

級聯SFU解決的第一項問題是人數限制，受單伺服器的出口帶寬所限，如果線上人數達到一定規模那麼學生就無法成功訂閱來自老師的視訊。此時如果通過級聯SFU把來自老師端的流通過下一層伺服器進行轉發和路由，不僅可解決人數限制的問題，還可增加動态擴充的功能，也就是根據新加入學生的人數動态擴建伺服器，進而實作節省資源的目的。

2.3.2 解決地理分布與就近接入問題

單伺服器造成的跨地域使用者延遲問題，可通過級聯伺服器解決。通過對每位使用者的IP進行解析，系統就可獲知此使用者所在地理位置并根據地理位置資訊為使用者就近配置設定可用伺服器節點，進而盡可能降低由于地理跨度帶來的視訊延遲。

而對于全球化來部署來說，由于一個洲所擁有的一般為一整個伺服器叢集，有可能此伺服器叢集下有多個SFU進行多層級聯，這就便于我們搭建起一個簡單的全球化分布式網絡架構。

3. Licode

接下來我将為大家介紹Licode，上圖展示的是部分Licode官方介紹。Licode相當于一個部分基于WebRTC源代碼但完全相容WebRTC的開源SFU伺服器，具有簡單可用易伸縮的優點，也支援視訊會議，推流和錄制等功能。

從底層到上層，我們來看一下Licode的各個子產品。最底層的Erizo子產品實作WebRTC的基本協定如（ICE，SDP，DTLS等），實作WebRTC協定棧後Licode就可和浏覽器進行通訊并把浏覽器的視訊流上傳至伺服器；再上一層是ErizoAPI，相當于一層封裝，通過NodeJS的封裝層封裝C++使得上層可通過NodeJS調用相應子產品；ErizoAPI上一層是Erizo Controller，這部分通過JS實作的代碼相當于封裝下一層的調用，開發者可通過JS對其進行快速開發并實作特殊邏輯如房間邏輯、釋出者邏輯、訂閱者邏輯等或實作類似于（Token）驗證等功能；最頂層的Nuve則主要用于通過API調用多項功能如API建立房間，API管理使用者等等。

上圖展示的是Licode子產品的整體架構。由上至下，第一層的CustomServerApp通過建立的Port3000調用Nuve API，而資料則通過MogonDB存儲；第二層的RabbitMQ會處理相應的信令并分布式；圖中紅框标示的部分是ErizoJS與WebRTC，此部分代碼使用JS進行封裝，這個子產品主要封裝了釋出者、訂閱者等邏輯。開發者可通過這裡的代碼直接建立一個釋出者或訂閱者進而實作與前端浏覽器之間的通訊。

4. 基于Licode級聯實作

百家雲将Licode ErizoJS 子產品單獨提取并使其直接與信令通訊，這裡給大家較長的描述一下流程。信令會和ErizoJS與用戶端連接配接，信令會根據用戶端的ip，給用戶端選擇就近的ErizoJS，同時将視訊流釋出至此伺服器上；假若此時有一位于上海的用戶端接入而視訊流來自北京，那麼信令就可偵測到二者不在同一區域，就會把北京的視訊流推至上海的ErizoJS；與此同時，我們也會在上海的伺服器端建立一個Router，此Router同樣也是Publisher，上海的客戶就可以使用這個Publisher 建立一個 Subscriber 來訂閱視訊。

4.1 單節點Docker化

除了實作Licode級聯，百家雲也對Licode部分代碼進行了優化，首先是單節點Docker化。這裡的ErizoJS相當于一個SFU伺服器，我們所做的就是将此子產品Docker化進而組成一個新的子產品，此Docker化的子產品可實作動态擴充、快速部署等功能。由于教育場景下，在某些時間段，如工作日晚6點至9點或周末部分時段出現流量與視訊流的高并發現象，同樣在淩晨時段通路量較少，一直開着一定數量的伺服器并不是經濟實惠的選擇。Docker化之後根據需求動态調動部署伺服器，既達到動态擴容的效果又節省了流量和開銷，可謂兩全其美。

4.2 級聯間去加密

百家雲在細節上的優化也值得分享，比如說級聯之間去加密。大家應該知道WebRTC本身是基于加密傳輸，其會實作一層DTLS SRTP加密，而此加密對于伺服器和伺服器直接傳輸來說是不必要的，是以我們取消了這一層代碼并重新實作了Licode：：Transpore類，實作ICE傳輸。因為DTLS SRTP加密之前本身會有一個（握手）過程，如果我們去掉此加密層就會加快連接配接速度，同時也節省了加密計算的資源。

4.3 其他級聯優化

其他的一些優化如ICE也必不可少。因為Licode基于Libnice開發，而Libnice本身存在一個全局鎖問題。我們在開發的過程中發現當并發或流量達到一定高度時就會出現嚴重的丢包阻塞問題。我們的解決方案相是自己重新實作ICE并替換原來的Libnice資料包。除了ICE，我們還進行了Simulcast、FEC、NACK等優化。由于Licode本身是用戶端與伺服器之間的通信，并沒有實作伺服器與伺服器之間的功能。我們在此基礎上進行優化進而實作了伺服器與伺服器之間的傳輸。

4.4 全球化

最後我想為大家簡單介紹一下教育場景全球化部署執行個體。我們主要針對三個區域進行全球化部署：東南亞、美國與歐洲。為了保障東南亞國家如菲律賓等的接入穩定，會選擇從香港或新加坡接入，有時出于優化網絡的目的還需拉專線或通過就近營運商接入優；而對于美國，由于其網絡品質相對于東南亞國家更好，與中國連接配接的線路相對于中歐或東南亞的條件更好，是以不需要花費太多時間進行優化；中東歐國家一般通過國内常用的位于法蘭克福的節點進行傳輸，再通過愛爾蘭、英國等國家與地區接入進而盡可能優化網絡品質。

5. 參考資料

• 基于Licode的WebRTC全球分布式架構

  https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/86127347