文章目錄
選擇開源 WebRTC 媒體服務器架構的十二條建議
您有在 github 上搜索您需要的 WebRTC 相關資料的經歷嗎？之前的資料特別少，可是今天您再去搜一下，上面關於 WebRTC 的資料就和現在 WebRTC 在 LinkedIn 上面的簡介一樣多，下面這幅圖是 WebRTC 這幾年來在 github 上使用的走勢圖
從開源項目的一些倉庫使用的案例來看，有的使用量確實非常之高，下面這幅圖是我搜索 github 之後的一些例子
當您在 github 上搜索 WebRTC，並讓它默認爲您選擇最佳匹配時，您會得到 PubNub 的列子，使用 PubNub 作爲您使用 WebRTC 進行簡單的一對一視頻通話的信令。有趣的是，它已經不能再繼續工作了。因爲它使用了舊的 PubNub WebRTC SDK，這是一個不需要您花太多精力的領域(發送信令)。
假設您確實找到了一個您喜歡的 WebRTC 開源媒體服務器(當然是在 github 上)。您怎麼知道它有什麼好處? 這裏有 10 種不同的建議，您可以用來參考一下做出好的選擇。
您是否理解代碼
如果您打算爲 WebRTC 項目採用開源媒體服務器，那麼需要每隔一段時間就深入研究一下該項目的 WebRTC 業務相關代碼。
有幾件事情您必須要做，第一讓這個該死的媒體服務器運行起來，修復其中的 BUG、調整設置、修改其中的插件或者擴展以及爲媒體服務器改名。
在我看到的許多情況下，當供應商依賴於一個開源的 WebRTC 媒體服務器框架時，他們最終不得不深入挖掘它的代碼，有時甚至達到完全擁有它的程度，並完全改變項目的結構。
爲了確保您做出了正確的決定 —— 首先檢查一下您是否理解了自己要做的事情，並嘗試先研究一下代碼。
我自己的個人偏好是代碼中包含註釋，不能脫離代碼按自己的想法理解。所以一定要檢查那些不明顯的部分(比如帶寬估計，RTP 處理，STUN 或者 TURN 協議處理) 是否正確註釋了。
代碼是否持續維護
蘋果也是最近幾年纔開始在瀏覽器中啓用 WebRTC，SDK 中的 WKWebView 目前還在內測中，暫時不能使用，當然了我們還是非常高興的。
但現在我們都需要將焦點轉移到 H.264 上。包括您計劃使用的 WebRTC 媒體服務器。
谷歌呢? 他們剛剛宣佈將緩慢地從 PlanB 遷移到 UnifiedPlan。不要擔心細節 —— 它只是改變了處理多個流的方式。
自從 WebRTC 的規範草案最終確定了正確的定義以來，getstats() API最近發生了很多次變化，這與它的 Chrome 實現不同。
實際問題呢？一兩年前編寫的代碼在實際運行時存在嚴重的問題，甚至不談論升級、更新、安全補丁等等。只是基本的一個能讓它工作的東西。
當您檢查您計劃採用的 WebRTC 媒體服務器的 github 頁面時，請確保查看它最後一次更新的時間。如果您檢查更新是關於什麼的以及更新發生的頻率，就會得到額外的參考標準。
有人使用嗎
沒有什麼比犯別人正在犯的同樣的錯誤更好的了。(錯誤描述)
您想要的是一個流行的開源 WebRTC 媒體服務器。任何其他的東西都有它存在的理由，而這個理由不會是您發現了一顆未經雕琢的鑽石。
使用流行的框架，一個是久經考驗的，最好是名人使用，在生產環境中，在商業產品中，這些都是是參考標準
爲什麼？因爲他給了您需要的兩件事
- 驗證和有效性
- 生態
它會讓您確認這個東西是有價值的 —— 其他人已經用過它了。
它給您一個知識和經驗的生態系統（因爲有很多人使用，很多相關的示例和文檔）。有時可以利用這一點來找到一些已經使用過它的自由職業者，或者從社區中更多的人那裏獲得幫助，我不會僅僅根據流行程度來選擇一個平臺，但我會將它作爲一個強有力的參考標準。
該項目有文檔嗎
WebRTC 的媒體框架就像一個引擎，需要將其集成到您整個項目中。要實現這一點，您需要以某種方式與它集成 —— 或者通過它的 api，或者通過 REST api(或者GraphQL，等等)。
要做到這一點，您需要知道哪些 API 接口是適合您的，哪些不適合，比如那些寫出來的東西或者文檔。
當涉及到開放源碼框架時，文檔並不能保證具有特定的質量 —— 它會因項目的不同而有很大的差異，只要確保您所使用的文檔達到了可以理解的程度就可以了。
如果可能，請檢查文件是否包括:
- 一些介紹性材料的組成和架構的項目說明
- 一些 API 參考示例
- 一些演示如何使用這個東西的例子
- 一些關於安裝，配置，維護，可擴展文檔，…
文檔越多，一年之後您的情況就越好。
它是否是 Debuggable 的
WebRTC是實時的，實時很難調試。
如果您需要關注的不是信號部分(或者音視頻信令部分)，而是媒體部分，那就更難了。
我知道您只是喜歡在 c++ 代碼中添加您自己的 printf 和 cout 語句，並嘗試復現那個煩人的 bug。更有聖者，收集 PCAP （TCP Dump）文件，然後……呃……閱讀它們（估計您會瘋的）。
如果能夠提供一些日誌記錄、調試等功能，而不必總是將這些語句添加到代碼中，那就太好了。甚至可能有一個具有不同日誌級別的機制，並在日誌中寫入合理的信息，這樣就可以減少查找 bug 所需的時間。
另外，要確保將監控系統集成到您將要使用的媒體服務器中是非常方便的。如果在生產中沒有簡單的方法來測試這個東西的健康狀況，那麼它要麼沒有在生產中使用，要麼需要進行一些修改才能實現。我想您應該不想陷入那種困境。
同時 —— 確保代碼本身有良好的文檔記錄。沒有什麼比自我解釋的代碼概念更令人沮喪(也更愚蠢)了。人 —— 代碼不能解釋它自己 —— 自己做自己的事情。我知道那個寫媒體服務器的人是上帝的化身，但我們其他人不是。您們的程序員很優秀，但是相信我 —— 不是那麼好。選擇一些易於維護 —— 這是不言自明的，因爲有人花時間在代碼的棘手部分寫了一些非常好的註釋，我知道這也是摸索代碼的一部分，但它很重要 —— 檢查兩次。
對我來說，更快地調試、排除故障和發現問題的能力通常對我自己的業務至關重要。
是否易於服務橫向擴展
媒體服務器佔用了大量的資源，比如內存、CPU、帶寬（甚至是 GPU）
這意味着，如果您的業務以任何方式獲得成功，您將需要更多的媒體服務器來規模化運行。
您可以從在亞馬遜 AWS 上搜索一下從 m4.large 到 m4.16xlarge（這是機器名稱哦）看看您就知道了那是多麼昂貴了。最終，媒體服務器的橫向擴展歸結爲增加更多的機器，這很好理解，直到您開始使用羣組音視頻通話時您就明白了
下面是一個列子
- 假設一臺機器可以處理 100 個參與者，可以分成任何類型的測試小組(這裏只是一個簡化)
- 每一個音視頻電話平均有 10 個參與者
- 每組呼叫可以有2個參與者，最多 50 個參與者
現在我們考慮一下如何橫向擴展我們的音視頻服務能力呢?
我們需要投入多少臺機器? 我們什麼時候決定不向正在運行的機器增加新的音視頻呼叫進入? 這些機器人員都滿了，我們要把它們級聯起來嗎? 丟掉該音視頻的呼入並嘗試將它們轉移到其他機器上?
我不知道，但您應該知道。至少您是認真對待您的產品的。
您可能無法在開源 WebRTC 媒體服務器的文檔中找到這個問題的答案，但至少應該確保您有一些關於如何大規模運用和部署它的合理文檔，而不是作爲一次性實例。
該媒體服務器使用什麼語言開發的
他們是用 Kotlin 寫的哦。因爲這是有史以來最偉大的語言，谷歌甚至將其成立爲 Android 的官方版本。
如果我們使用 Kotlin 開發媒體服務器有問題嗎？我在使用的語言中尋找兩件事:
- 音視頻媒體服務最終的結果都是支持高性能的音視頻接入，記住，我們在這裏要處理的是一個資源浪費的問題，所有我們要考慮得長遠一點，一個詞：優化
- 我必須知道如何使用它，並且我的開發人員也要必須精通此事
其中有一些媒體服務器是基於 Node.js 的，而另一些是用 Java 編寫的。您的開發人員更喜歡哪一個? 哪一個更適合您公司未來 5 年的技術計劃?
如果您需要在兩個媒體服務器之間做出選擇，而它們之間的主要區別在於語言，那麼選擇對您的組織更有效的語言。
它是否符合您的信令模式
您的 WebRTC 產品需要三樣東西:
- 信令服務
- STUN/TURN 服務
- 媒體服務器
第三條不是強制性的，但如果您正在讀這篇文章，它是強制性的。該媒體服務器需要與信令服務器和 STUN/TURN 服務器交互。
當然，您可以使用媒體服務器的信令功能，但它們並不是真正的信令功能，我的建議是不要將媒體服務器公開用於任何事情 —— 在您的服務中對其進行內部控制。
因此，您需要讓它與您的信令服務器進行交互。檢查它們是否共享相似的範例和概念，否則，這本身就是一件很頭疼和混亂的事情，否則調試測試時您會瘋掉的。
檢查一下您要選擇的媒體服務器架構是否有很容易集成的 STUN/TURN 開源服務器供您選擇
開源許可證對您合適嗎
BSD? MIT? APL? GPL? AGPL?
這個開源的 WebRTC 媒體服務器框架到底附帶什麼許可證?
有趣的是，有些項目在這個過程中會轉換它們的許可證。Jitsi 是在被 Atlassian 收購之後這麼做的 —— 從 LGPL 轉移到一個更寬鬆的 APL。
您的業務模式的方式，以及您計劃部署服務的方式將會影響您想要的開源許可的類型，並將能夠在您的服務中採用。
您挑選和使用的每段代碼都需要遵守這些許可證內部要求和約束，這也包括媒體服務器本身。既然媒體服務器不像一個用過的電池那樣可以隨時更換，我的建議是選擇一個帶有開放源碼許可的東西 —— 或者選擇一個商業產品(它會讓您付出代價，但會解決這個煩人的問題)。
我以前寫過關於開放源碼許可的文章——也可以去看看。
有人爲此提供付費支持嗎
我知道，您使用開源來避免支付任何費用。然而，如果您查看許多成功且維護良好的開源項目 —— 特別是中小型項目，您將看到它們背後的業務模式。爲那些在 IT 上投入時間的人提供了一種謀生的方式。在許多情況下，業務模型是支持和定製開發的。
選擇付費支持意味着兩件事:
- 有些人願意承擔責任並改進這件事，他把它當作日常工作來做，而不是當作業餘愛好
- 如果您需要幫助儘快 —— 您可以隨時支付得到它
如果沒有人提供任何付費支持，那麼誰來維護這些代碼，目的是什麼? 怎樣才能鼓勵他們繼續投入時間開發呢? 他們會在下個月決定停止投入開發嗎? 上個月嗎? 明年嗎?
現在流行開源媒體服務器預覽
Jitsi Platform
Jitsi不僅是WebRTC媒體服務器，而且還有一個完整的平臺。 Jitsi系列產品包括Jitsi Videobridge（媒體中繼，SFU），Jitsi Meet（會議網絡客戶端），Jicofo（Jitsi Conference Focus），Jigasi（Jitsi Gateway to SIP）和Jitsi SIP Phone。藉助Jitsi我們能在幾個小時之內迅速搭建一個完整可用的通信平臺。 它還使用Jingle（XMPP）和功能齊全的Web界面實現自己的信令控制。 然而，令人遺憾的是，它對於媒體錄製沒有提供穩定易用的解決方案。
Kurento Media Server
這是最通用的解決方案之一。 它不僅是一個媒體服務器，而且是一個開發工具包。Kurento的主要優勢在於其多功能性，引入了媒體工作流的概念，允許在代碼中定義媒體流的方式和位置。 這允許WebRTC開發者組合和集成非常有趣的特徵，例如增強現實，AR計算機視覺（例如識別QR碼，面部檢測），實時媒體修改和與RTP（VoIP）服務互操作。Kurento可以配置爲SFU或MCU，或兩者兼備。
Janus WebRTC Gateway
雖然它的描述在任何地方都沒有提到“媒體服務器”，但Janus可以很容易地設置爲SFU。 其最顯着的特徵之一是其插件架構，可以增強服務的核心功能。有一些有趣的Janus用例，例如SIP Gateway，屏幕共享等。
mediasoup
這是一個相對較新而且有趣的媒體服務器，它與其他媒體服務器的不同之處在於它被設計成一個用於Node的開發庫，這允許它可以被容易的集成到更大的應用程序中。
licode
底層基於 c++ 進行開發，內部使用 WebRTC 部分 P2P 源碼，健壯性比較強，信令和業務控制通過 nodejs 做橋接方便調用，使用方便，結構設計合理
做出決定
考慮需求和約束，理解總是存在未知和部分信息。然後從中提煉出一個決定，決定性的選擇。
在 Gustavo Garcia 編寫的這個偉大的彙編中，您可以找到更多關於媒體服務器的技術信息。