大規模實時音視頻（RTC）是疫情時代火熱的在線課堂、直播、電話會議等的技術基礎，但對于多數工程師來說，自研 RTC 系統的架構設計在客戶端、服務端、運維、測試和質量監控上仍存在很多難點。因此我們整理了 QCon 全球軟件開發大會（2021）北京站上，聲網 Agora 行業架構師董海冰分享的三部分内容：RTC（實時音視頻）的基礎概念、場景及特點分析；自研 RTC 的架構設計和難點；展望 RTC 未來，幫你扣開實時音視頻系統架構設計的大門。以下為老師分享的正文。（下文以董海冰老師第一人稱叙述）

　　RTC（實時音視頻）的基礎概念、場景及特點分析 WebRTC 更側重于浏覽器端，擁有諸多成熟的音視頻解決方案，搭建成本低，便于初學者上手，今年起已成為 W3C 正式标準。

　　我們提及 RTC 多指 Native RTC。Native RTC 可用私有協議，需要 Native 客戶端支持，擁有更大的彈性和擴展空間。

　　實時音視頻 QE 的鐵三角為音畫質量、實時和流暢。音畫質量關注分辨率、幀率等，流暢關注卡頓、抖動、丢幀等，實時則關注首幀、音畫同步、延時等。這三者是動态平衡的，如高畫質必然影響實時和流暢。除此之外，可伸縮性和可用性也不容忽視。

　　實時音視頻的目标為動态條件下實時傳輸，需在客觀情況下尋求以上因素的最優解。其延時必須小于 1s，以 200 ms 或 300 ms 為佳。另外，需要及時交互的遠程控制和雲遊戲場景可能要求更高，在 100ms 左右，甚至低至幾十 ms。在如此短的延時下，要實現不同網絡中良好的音畫質量，挑戰不容小觑。

　　互聯網行業中大量成熟解決方案主要依賴三闆斧：緩存、異步、分布式。對于實時音視頻來說，他山之石，是否可以攻玉呢？

　　首先傳統的緩存，時間為秒級或分鐘級，難以達到毫秒級，因此在 RTC 上隻能小範圍應用。其次，即使實現了并行處理，但在迅速反饋最終結果上仍存在巨大挑戰。而對于分布式方案來說，傳統互聯網的 HTTP 協議很可能無狀态，即無法及時感知通訊期間的狀态變化和異常，因此難以滿足 RTC 的要求。因此以上三闆斧在 RTC 上難當大任。

　　RTC 教育功能模塊圖 實時音視頻在教育領域中應用廣泛，場景衆多，功能複雜，如下圖為某實時音視頻在教育領域中應用的實例。

　　如圖所示，老師端需實現實時音視頻、消息、互動白闆三種服務，學生端有連麥（即可實時互動）和近場（即可能選擇性訂閱的遊客）遠場（即用 CDN 轉播推流的超級大班課）三種情況；回看功能需将音視頻文件持久化在雲存儲或 OSS 中；監管問題方面需 AI 智能審核、掐斷不合法的音視頻流。

　　實現以上功能有許多問題，如成本、效率、人力等資源問題，客戶端、服務端等選型問題，跨平台、跨國、跨區域或運營商的網絡問題，弱網、Lastmile、3A 處理、終端适配等技術難點問題，以及質量監控和測試方面的問題。

　　RTC 教育場景技術架構圖 我們自研 TutorMeet 部署圖如下所示：

　　Configurator 是本系統的統一配置。學生端會先訪問靜态文件，通過 Configurator 取到合适的信令網關。随後 Room Server 負責管理房間或頻道的邏輯，如頻道中的人員、角色和彼此是否存在實時互動關系等。接着，Room Server 再通過 Allocator 搜索更近的 Media Server 網關。此處标準 WebRTC Gateway 和非标 RTC 的 Gateway 均可。最後，再接上 SFU、MCU 和一些圖中未表示的輔助系統（如精彩剪輯、推流服務等）即可。

　　此外，本系統通過 Consul 在不同的區域或機房部署基數節點，實現了統一的全球配置和動态增減，通過 Monitor 監控和預設算法自動 Kill 業務異常服務，保證新用戶不會訪問到有問題的服務。

　　自研 RTC 系統的架構設計和難點客戶端跨平台方案選型 目前主流跨平台方案如下所示：

　　QT 方案老骥伏枥，支持 GPL 協議，除支持普通平台之外還支持 Symbian 平台，開發難度大，庫也更豐富。

　　CEF 和 Electron 目前采用較多，存在親緣關系。Electron 可采用 JS 接口做 NATive 開發，其底層内核可以理解為 CEF。CEF 擁有更強的可定制性，Electron 可自動更新，而 CEF 需自己實現更新機制。Electron 是不支持 Windows XP 的，CEF 雖不太理想但可降級支持 Windows XP。

　　Flutter 作為 Dart 語言開發的新起之秀，支持較新的操作系統如 Google 的 Fuchsia。由于較新難免存在一些隐患。

　　其他平台除 Electron 外均使用 C 開發。這是因為 RTC 對延時要求達到了毫秒級，隻有 C 這類底層語言才能滿足其性能需求。不過，現在新語言如 Go、Rest 等也能實現較好效果。

　　綜合以上，從客戶端的選型來說，若團隊有 C 高手，我建議選用 CEF，但是若團隊偏 Web 前端，Native 開發較弱，則建議選用 Electron。

　　客戶端難點與挑戰 客戶端目前的挑戰分為音頻問題和弱網對抗問題。音頻問題主要包括無聲/聲音小，回聲和噪音/雜音三類。下圖為音頻客戶端的架構圖：

　　圖中底層視頻音頻引擎和傳輸均封裝了良好的外部接口。因此做 WebRTC 的音視頻研發并不需了解底層，從外部 API 入手即可。下圖是更詳細的 Native RTC 架構圖。

　　上圖流程為先通過 ADM 進行信号收集，用 APM 模塊（包括 3A 處理）将信号進行編解碼，再利用網絡發送信号，信号返回後合流、播放。3A 處理即 AEC、ANS、AGC。

　　無聲問題需依賴 AGC 做自動化處理。AGC 和設備及其具體參數息息相關，需在算法和底層機制上保持靈活性，面對不同設備種類使用不同的策略。

　　回聲問題需權衡 DTD 和 AEC。DTD 即雙講，要求多人發言時保留人聲的交互；AEC 即回音消除，需用線性濾波和非線性處理消除無用的信号。此外，雙講還需通過 CNG 舒适靜音生成使聽感更逼近真實情景。雙講和回音消除是一對矛盾，無論哪方面如果解決不好，都會非常影響體驗。特别在素質教育的一些場景下，例如：音樂課、樂器演奏課等，如果老師和學生一邊演奏、唱歌，一邊讨論教學，對音頻算法處理方面有非常大的挑戰，聲網目前在音樂教學的音頻優化方面有比較大的突破，對相關場景做了更好的優化。

　　噪音是采用 AI 去噪，需要一個包含典型噪音的特征庫進行篩選。然而，降噪模型數據過大會增加包體積，如何平衡好數據包大小和降噪精度也需要更好的工程經驗和進一步的方案優化。

　　弱網對抗能力亦不可或缺，目前的難點包括網絡發生變化時如何通過調整碼率和幀率緩解變化；在智能路由算法中如何實現最優路徑傳輸；抖動時如何進行緩沖以免網絡降級後一味調整延時時間；如何實現多維度質量的實時化評估，和動态調整形成一個閉環……

　　在弱網對抗中，WebRTC 可對抗 20%~30%的音視頻的丢包率，用戶體驗尚可接受。改造後的 Native RTC，在保證一些額外要求後可實現 70%~80%。

　　服務器的難點和挑戰 下圖為服務端的協議棧：

　　左側是信令通道協議，現在多采用 WebSocket。WebSocket 為雙工雙向的控制協議，通過 HTTP 請求進行首次訪問，可滿足大部分信令傳輸或即時消息的需求。

　　我們的媒體通道建立在 UDP 基礎上。這兩種協議大相徑庭，尤其是在高丢包或弱網的情況下，還是 UDP 會更合适。若雙通道分開控制在網絡比較惡劣的情況下，Websocket（TCP）已經斷掉了，但 UDP 還連着，即信令斷連，音視頻無問題，但做操作會受影響。未來我們希望借助類似 UDP 的協議解決信令通道的問題，提高一緻性。

　　下圖為服務端 NAT 穿透架構圖：

　　NAT 網絡種類繁多。為節省 IP，用戶常在内網中使用内網 IP。此類設備的 RTC 需穿透 NAT。常規情況下，STUN Server 即可解決問題，但某些 NAT 網絡無法打通，則需要一個中繼：Relay Server。開源的 Server coturn 能同時實現上述兩種功能。

　　開源服務端方案比較 開源的服務器方案衆多，按時間排序如下圖所示。

　　Jitsl 是用 Java 寫的，支持 Apache 協議，非常活躍。Kurento 支持 Apache 協議，它提出了一個新的項目——OpenVidu。OpenVidu 部分代碼也是 Java 寫的，試圖降低開源的 Server 的接入門檻。Licode 項目由英特爾做了很多的貢獻，性能優異但二次改造成本高。

　　我用過 Kurento 和 Janus。Kurento 的功能和文檔都相當出衆，文檔尤佳，功能介紹極其透徹。Janus 則實為 C 語言開發的 WebRTC 網關，支持 GPR 協議，GitHub Star 數較多，性能也非常好。

　　此外，Go 語言開發的 Pion 相對較新，結構及模塊均清晰明了，新用戶采用較多，Star 數也增長很快。

　　下圖是 2018 年，以上方案的早期版本的測試報告：

　　如圖所示，Jitsi 壓到約 200 個即出現異常；Janus 較正常，壓到了 500；Medooze 較好； mediasoup 的圖波動比較，或存在某些問題。

　　下圖為以上各方案面對壓力的性能情況。

　　運維的難點與挑戰

　　我們做了公有雲和自建機房的多活，通過自己的路由 Router 将一個物理的空間分成多個區，每個區相對獨立，依賴于底層的基礎服務。在不同的物理空間之内通過 Update 數據同步實現多活。

　　以上設計還可以實現一些附加功能，如從容發版，發版時将某個區的流量切走即可；和在某幾個特定區做 A/B Test；如果有異常情況，可以從容切換、回滾等。

　　除此之外，我們還做了容器化部署、自動化運維、監控工具、發布工具、日志系統、全球網絡挑戰及 Lastmile 策略等。

　　Lastmile 是由網絡複雜性造成的，如家庭 Wi-Fi 2.4G 連接多個設備信道的占用、網絡擁塞問題；小區網絡運營商限速或跨運營商等問題。此時，可使用 NACK（丢包重傳）、FEC（前向糾錯） GCC（Google 擁賽控制）以及 PACER 等策略。

　　質量和自動化測試 自動化測試我們使用的是類似 KITE 的方法。質量指标分為 QoS 和 QoE 兩類。QoE 指标分為兩類，有參考客觀評價方法和無參考客觀評價方法。這兩類指标都需對照類似 MOS 分的标準質量體系，驗證其準确性。

　　展望 RTC 的未來，如何擁抱變化持續創新 Metaverse（元宇宙）的概念目前火熱：即和現實世界平行的虛拟世界，人們可以在其中體驗另一種全新的“角色”。有人說 Metaverse 的三大技術基礎為 AI、VR/AR/MR 和區塊鍊，但 RTC 也是不可或缺的一環。元宇宙從虛拟走向真實，必須依靠更逼真炫酷的體驗和更實時的交互為基礎。而 RTC（或者 RTE）作為實時數據的傳輸的通道，一端連接真實世界的“實體”數字化轉型，一端連接虛拟世界的 Metaverse。

　　在 ROBLOX 遊戲中，玩家也可以自行定制開發各種形式的遊戲場景。為了提升遊戲的沉浸感和仿真度，此時所需的高質量交互體驗即為 RTC 未來的發展方向，VRCHAT 同理。

　　總之，作為 RTC 的自研團隊，不能閉門造車，需緊跟時代脈搏和行業發展趨勢，乘着時代的東風才能航行得更遠、更穩。

　　嘉賓介紹

　　董海冰，現任聲網 Agora 行業架構師，曾先後就職于平安好學、途牛、滬江等互聯網公司，主要負責實時音視頻系統架構，基礎平台建設，運維監控 & DevOps 等工作。對大型互聯網系統的架構設計、分布式、RTC 與 SRE 等都有較深入的理解。

　　外部鍊接

　　coturn:htt

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!