前言

隨著網絡基礎設施的提高，音視頻實時通信越來越成為人們日常生活和工作中必不可少的需求。2011年 WebRTC的出現，則更加速了這種需求變為現實的可能性。

熟悉 WebRTC 的同學應該都知道，WebRTC規范只定義了實時通信中客戶端的行為，而沒有規范服務端（包括哪些信令、數據如何流轉）的行為。所以，你可以使用WebRTC庫方便的實現 1:1 實時通信，但對于多人實時互動，光依靠 WebRTC庫顯然就無法完成要求了。

那我們該如何實現多人實時互動通信呢？

WebRTC 流媒體服務器

要想實現多人的實時互動，如音視頻會議、在線教育這類產品，我們必須使用 WebRTC + WebRTC流媒體服務器這種方案。

目前有很多比較有名的開源流媒體服務器，如 Janus、Medooze、Mediasoup、Licode(OWT)、Jitsi等等。這些流媒體服務器各有優缺點，下面我就對這幾種流媒體服務器作下簡要的介紹與比較。

通過本文，你將知道各 WebRTC 流媒體服務器的優缺點，并依俱它們的優缺點選擇出更適合你的那款WebRTC流媒體服務器。

Mediasoup

Mediasoup 整體結構

上圖是Mediasoup整體架構圖，通過該圖我們可以知道 Mediasoup 流媒體服務器是由 Nodejs 和 Mediasoup(C++) 兩部分組成。

• Nodejs，負責 Mediasoup 的信令接收與業務管理。如創建/消毀房間，創建/關閉生產者，創建/關閉消費者等。
• Mediasoup(C++)，這是一個單獨的程序，但該程序無法直接啟動。因為它在內部會判斷是否是 Nodejs 將它啟動起來了。只有在Nodejs 的 Mediasoup 管理模塊加載之后，再將 Mediasoup(C++)啟動起來，這樣它才能正常工作。

在眾多的 WebRTC 流媒體服務器中，Mediasoup 可以說是性能最優秀的WebRTC流媒體服務器。它使用 C++ 作為開發語言，底層使用 libuv 處理 I/O 事件。

有很多人對 Nodejs 比較詬病，認為 Nodejs 提拱不了高性能的流媒體服務器。實際上，如果按照傳輸的 Nodejs 應用開發出的流媒體服務器肯定是不能勝任這項工作的。但對于 Mediasoup 來講，它只不過使用 Nodejs 做 信令處理 及 業務的管理 工作，所以它的負擔并不重。對性能要求高的是媒體數據流的轉發工作，而這部分工作是由 Mediasoup(C++)部分實現的。Nodejs 與 Mediasoup之間通過管道進行通信。

嚴格意義上來說，Mediasoup是單進程的。但你不要以為這就影響了它的性能。實際上，它是使用單進程的方式將服務器上CPU某個 核 充分利用好，然后在業務層控制進程的個數。比如說你的服務器是個 8 核的CPU，那么在業務層你就該啟動 8 個Mediasoup進程。通過這種方式來達到對 CPU 的充分利用。

mediasoup結構圖

Mediasoup中的每個進程稱為一個 Worker, 你也可以把它理解為一個節點，在每個 Worker 中可以有多個 Router。對于 Router，你站在不同的解度可以有不同的理解。如果你占在應用層的角度，你可以把它理解為一個房間；如果你站在數據流轉的角度，可以把它理解為一個路由器，數據通過 路由器 轉發給目標用戶。

想了解更多Mediasoup的細節，可以觀看我的視頻課 《百萬級高并發WebRTC流媒體服務器設計與開發》，在這個視頻中我對 Mediasoup 源碼做了深入剖析。

Janus

Janus架構

上面這張圖是 Janus 的整體架構圖。在這張圖中我們可以看到， 從大的方面說 Janus 由 Janus CORE、Janus Plugin 以及信令接口三部分組成。

• 信令接口，Janus 支持的信令協議比較多，如 HTTP、WebSocket、RabbitMQ 等。這些信令協議使得 Janus 具有非常好的接入性。因為很多公司喜歡各種不同的協議，如有的喜歡 websocket，有的喜歡http，proto等。因此 Janus 在信令接入方面具有很大的優勢。
• Janus Plugin，Janus 的業務管理是按照 Plugin 的方式管理的，因此你可以在Janus中根據自己的需要實現自己的業務插件。實際上，對于一般性的需求 Janus 已經相關的插件。如：
  • VideoRoom，用于多人音視頻互動，像音視頻會議，在線教育都可以通過該插件來實現。
  • VideoCall，用于 1:1 的音視頻通信。
  • SIP，用于與傳統電話設備對接。
  • Streaming，用于廣播，也就是我們通常所說的一人共享，多人觀看的直播模式。
  • TextRoom，它是一個聊天室，通過它可以進行文本聊天。
  • RecordPlay，用于錄制和回放。
• Janus Core 是Janus的核心，其作用是處理流的轉發，各種協議的接入。以瀏覽器為例，要想讓瀏覽器接入到 WebRTC 流媒體服務器上，那流媒體服務器必須要支持 STUN、DTLS、SRTP、ICE 等協議。而 Janus Core 就是專門做這事兒的。

Janus 是由 C語言開發的，因此它的性能非常優秀。要說不足的話，janus 底層沒有使用 epoll 這類異步I/O事件處理機制，這應該說是它的一大缺陷；另外，Janus還使用 glib 庫，由于 glib 庫對于國內的很多開發同學來說用的比較少，所以會有一定的學習成本。

整體上看，Janus采用了插件的架構設計方案。這種方案非常適合于有多種業務模型或業務經常發生變化的公司或項目。另外 Janus 支持多種消息傳輸協議，這對于開發人員來說具有極大的吸引力。

Medooze

Medooze 架構.png

Medooze 的整體架構與 Mediasoup 類似，不過它的信令處理、業務管理以及媒體數據的轉發功能都是放在 Nodejs下進行統一管理的。實際上，這樣的管理方式也不會對性能造成什么影響，因為重的媒體流的轉發工作仍然是使用的 C++ 在 Nodejs 底層實現的。

Medooze 的業務功能要比 Mediasoup 強大，像服務端錄制、推流這些 Mediasoup 沒有的功能它都支持。但它性能沒有 Mediasoup 做的極致，在Medooze的底層使用的poll來處理I/O事件，poll與epoll性能相差距大。除此之外，Medooze的業務邏輯也沒有Mediasoup簡潔；另外與 Janus 相比，它的業務管理不如 Janus 靈活，Janus 的插件管理方式顯然要優于 Medooze 和 mediasoup。

但總的來說，Medooze還是一款非常不錯的 WebRTC 流媒體服務器。雖然有一些小的暇疵，但還是非常不錯的一款流媒體服務器。

想了解更多 Medooze 細節的同學可以看我的專欄 《從0打造音視頻直播系統》。

小結

通過上面的描述，我想你應該對目前主流的 WebRTC 流媒體服務器有了一個大體的了解。所以在選型上你可以按照自己團隊的能力進行評估到底該用那個流媒體服務器。

如果你團隊能力比較強，可以做底層開發，那么建議你使用 Mediasoup。因為 Mediasoup 不關心應用層，它關注的是底層數據如何高效的流轉，代碼簡潔、高效，性能極佳。

如果你們要做的業務種類比較多，變化比較快，那建議你選擇使用 Janus 作為流媒體服務器。將你的業務做成一個插件放到 Janus上很快就能實現你們的業務需求。

如果你們的業務變化不大，除了追求性能外，還需要錄制、推流之類的功能，那么你可以選擇使用Medooze，它可以很好的滿足你們的需求。

當然，除了上面我介紹到的幾款比較流行的 WebRTC 流媒體服務器外，還有一些其它的流媒體服務器，如 Licode、OWT、Jitsi等也可以選擇。

Licode 之所以名氣比較大，是因為它推出的時間比較早。而 OWT 是 Licode 的一個變種，它在 Licode上實現了 SFU 功能?？匆幌?Licode 代碼你就會發現，Licode 實現了一套完整的音視頻會議系統，對于這樣一套系統它的實現非常復雜。如果你的團隊沒有音視頻方面的開發人才的話，可以考慮Licode，將它搭建出來之后就可以直接使用了。但如果你有業務變化想修改它就太麻煩了。

Jitsi 上層是使用 Java 語言開發的，但底層也是使用的 C/C++ 語言。它通過 JNI 來實現Java與 C/C++之間的通信。在 2018 年有機構做過一次性能評測，當時 Jitsi 表現比較差強人意，不知現在是否已經有了改進。

以上就是對幾款 WebRTC流媒體服務器的比較，希望本文可以幫助你解決WebRTC流媒體服務器的選擇問題。

參考

• 《百萬級高并發WebRTC流媒體服務器設計與開發》
• 《從0打造音視頻直播系統》