随著(zhe)網絡基礎設施的提高，音視頻實時通信越來越成(chéng)爲人們日常生活和工作中必不可少的需求。2011年 WebRTC的出現，則更加速了這(zhè)種(zhǒng)需求變爲現實的可能(néng)性。
熟悉 WebRTC 的同學(xué)應該都(dōu)知道(dào)，WebRTC規範隻定義了實時通信中客戶端的行爲，而沒(méi)有規範服務端（包括哪些信令、數據如何流轉）的行爲。所以，你可以使用WebRTC庫方便的實現 1:1 實時通信，但對(duì)于多人實時互動，光依靠 WebRTC庫顯然就無法完成(chéng)要求了。
那我們該如何實現多人實時互動通信呢？
要想實現多人的實時互動，如音視頻會(huì)議、在線教育這(zhè)類産品，我們必須使用 WebRTC + WebRTC流媒體服務器這(zhè)種(zhǒng)方案。
目前有很多比較有名的開(kāi)源流媒體服務器，如 Janus、Medooze、Mediasoup、Licode(OWT)、Jitsi等等。這(zhè)些流媒體服務器各有優缺點，下面(miàn)我就對(duì)這(zhè)幾種(zhǒng)流媒體服務器作下簡要的介紹與比較。
通過(guò)本文，你將(jiāng)知道(dào)各 WebRTC 流媒體服務器的優缺點，并依俱它們的優缺點選擇出更适合你的那款WebRTC流媒體服務器。
上圖是Mediasoup整體架構圖，通過(guò)該圖我們可以知道(dào) Mediasoup 流媒體服務器是由 Nodejs 和 Mediasoup(C++) 兩(liǎng)部分組成(chéng)。
在衆多的 WebRTC 流媒體服務器中，Mediasoup 可以說是性能(néng)最優秀的WebRTC流媒體服務器。它使用 C++ 作爲開(kāi)發(fā)語言，底層使用 libuv 處理 I/O 事(shì)件。
有很多人對(duì) Nodejs 比較诟病，認爲 Nodejs 提拱不了高性能(néng)的流媒體服務器。實際上，如果按照傳輸的 Nodejs 應用開(kāi)發(fā)出的流媒體服務器肯定是不能(néng)勝任這(zhè)項工作的。但對(duì)于 Mediasoup 來講，它隻不過(guò)使用 Nodejs 做 信令處理 及 業務的管理 工作，所以它的負擔并不重。對(duì)性能(néng)要求高的是媒體數據流的轉發(fā)工作，而這(zhè)部分工作是由 Mediasoup(C++)部分實現的。Nodejs 與 Mediasoup之間通過(guò)管道(dào)進(jìn)行通信。
嚴格意義上來說，Mediasoup是單進(jìn)程的。但你不要以爲這(zhè)就影響了它的性能(néng)。實際上，它是使用單進(jìn)程的方式將(jiāng)服務器上CPU某個 核 充分利用好(hǎo)，然後(hòu)在業務層控制進(jìn)程的個數。比如說你的服務器是個 8 核的CPU，那麼(me)在業務層你就該啓動 8 個Mediasoup進(jìn)程。通過(guò)這(zhè)種(zhǒng)方式來達到對(duì) CPU 的充分利用。
Mediasoup中的每個進(jìn)程稱爲一個 Worker, 你也可以把它理解爲一個節點，在每個 Worker 中可以有多個 Router。對(duì)于 Router，你站在不同的解度可以有不同的理解。如果你占在應用層的角度，你可以把它理解爲一個房間；如果你站在數據流轉的角度，可以把它理解爲一個路由器，數據通過(guò) 路由器 轉發(fā)給目标用戶。
想了解更多Mediasoup的細節，可以觀看我的視頻課 《百萬級高并發(fā)WebRTC流媒體服務器設計與開(kāi)發(fā)》，在這(zhè)個視頻中我對(duì) Mediasoup 源碼做了深入剖析。
上面(miàn)這(zhè)張圖是 Janus 的整體架構圖。在這(zhè)張圖中我們可以看到， 從大的方面(miàn)說 Janus 由 Janus CORE、Janus Plugin 以及信令接口三部分組成(chéng)。
Janus 是由 C語言開(kāi)發(fā)的，因此它的性能(néng)非常優秀。要說不足的話，janus 底層沒(méi)有使用 epoll 這(zhè)類異步I/O事(shì)件處理機制，這(zhè)應該說是它的一大缺陷；另外，Janus還(hái)使用 glib 庫，由于 glib 庫對(duì)于國(guó)内的很多開(kāi)發(fā)同學(xué)來說用的比較少，所以會(huì)有一定的學(xué)習成(chéng)本。
整體上看，Janus采用了插件的架構設計方案。這(zhè)種(zhǒng)方案非常适合于有多種(zhǒng)業務模型或業務經(jīng)常發(fā)生變化的公司或項目。另外 Janus 支持多種(zhǒng)消息傳輸協議，這(zhè)對(duì)于開(kāi)發(fā)人員來說具有極大的吸引力。
Medooze 的整體架構與 Mediasoup 類似，不過(guò)它的信令處理、業務管理以及媒體數據的轉發(fā)功能(néng)都(dōu)是放在 Nodejs下進(jìn)行統一管理的。實際上，這(zhè)樣(yàng)的管理方式也不會(huì)對(duì)性能(néng)造成(chéng)什麼(me)影響，因爲重的媒體流的轉發(fā)工作仍然是使用的 C++ 在 Nodejs 底層實現的。
Medooze 的業務功能(néng)要比 Mediasoup 強大，像服務端錄制、推流這(zhè)些 Mediasoup 沒(méi)有的功能(néng)它都(dōu)支持。但它性能(néng)沒(méi)有 Mediasoup 做的極緻，在Medooze的底層使用的poll來處理I/O事(shì)件，poll與epoll性能(néng)相差距大。除此之外，Medooze的業務邏輯也沒(méi)有Mediasoup簡潔；另外與 Janus 相比，它的業務管理不如 Janus 靈活，Janus 的插件管理方式顯然要優于 Medooze 和 mediasoup。
但總的來說，Medooze還(hái)是一款非常不錯的 WebRTC 流媒體服務器。雖然有一些小的暇疵，但還(hái)是非常不錯的一款流媒體服務器。
想了解更多 Medooze 細節的同學(xué)可以看我的專欄 《從0打造音視頻直播系統》。
通過(guò)上面(miàn)的描述，我想你應該對(duì)目前主流的 WebRTC 流媒體服務器有了一個大體的了解。所以在選型上你可以按照自己團隊的能(néng)力進(jìn)行評估到底該用那個流媒體服務器。
如果你團隊能(néng)力比較強，可以做底層開(kāi)發(fā)，那麼(me)建議你使用 Mediasoup。因爲 Mediasoup 不關心應用層，它關注的是底層數據如何高效的流轉，代碼簡潔、高效，性能(néng)極佳。
如果你們要做的業務種(zhǒng)類比較多，變化比較快，那建議你選擇使用 Janus 作爲流媒體服務器。將(jiāng)你的業務做成(chéng)一個插件放到 Janus上很快就能(néng)實現你們的業務需求。
如果你們的業務變化不大，除了追求性能(néng)外，還(hái)需要錄制、推流之類的功能(néng)，那麼(me)你可以選擇使用Medooze，它可以很好(hǎo)的滿足你們的需求。
當然，除了上面(miàn)我介紹到的幾款比較流行的 WebRTC 流媒體服務器外，還(hái)有一些其它的流媒體服務器，如 Licode、OWT、Jitsi等也可以選擇。
Licode 之所以名氣比較大，是因爲它推出的時間比較早。而 OWT 是 Licode 的一個變種(zhǒng)，它在 Licode上實現了 SFU 功能(néng)。看一下 Licode 代碼你就會(huì)發(fā)現，Licode 實現了一套完整的音視頻會(huì)議系統，對(duì)于這(zhè)樣(yàng)一套系統它的實現非常複雜。如果你的團隊沒(méi)有音視頻方面(miàn)的開(kāi)發(fā)人才的話，可以考慮Licode，將(jiāng)它搭建出來之後(hòu)就可以直接使用了。但如果你有業務變化想修改它就太麻煩了。
Jitsi 上層是使用 Java 語言開(kāi)發(fā)的，但底層也是使用的 C/C++ 語言。它通過(guò) JNI 來實現Java與 C/C++之間的通信。在 2018 年有機構做過(guò)一次性能(néng)評測，當時 Jitsi 表現比較差強人意，不知現在是否已經(jīng)有了改進(jìn)。
以上就是對(duì)幾款 WebRTC流媒體服務器的比較，希望本文可以幫助你解決WebRTC流媒體服務器的選擇問題。
發(fā)表評論 取消回複