火山引擎 RTC 實時媒體處理平臺的技術實踐
1.背景介紹
隨著實時音視頻（RTC）技術在娛樂、教育、會議、游戲等領域的廣泛應用，用戶對音視頻通話的核心功能需求不斷提升，同時也衍生出許多擴展需求。這些擴展功能在業務場景扮演著越來越重要的作用，已經成為許多業務場景的核心路徑。例如：
- 轉推直播 - 將直播間主播連麥的視頻合流轉推到 CDN 可以供更多人觀看；
- 實時錄制 - 將在線課堂中老師的教學和互動內容錄制下來供學生課后回看；
- 實時字幕 - 在跨國視頻會議中可以幫助參會者打破語言的界限，使信息傳遞更加準確順暢；
- 輸入在線媒體流 - 將體育賽事直播視頻輸入到 RTC 房間，實現邊看邊聊；
- 電話呼叫 - 將固話和手機用戶加入到 RTC 通話；
- SIP互通 - 將傳統視頻會議設備加入 RTC 視頻會議；
這些擴展能力不僅能夠提升 RTC 的互動體驗，延伸 RTC 的通信邊界，還能夠促進業務創新，為業務創造新的收入來源。
2.技術挑戰
為了支持上述這些功能，我們設計并實現了 RTC 實時媒體處理平臺，這套系統高效支撐了內外部業務的快速增長和功能迭代，但在系統落地和演進的過程中，我們也遇到了很多技術挑戰，可以總結為三大類。
2.1 「架構設計」
系統需要支持的業務場景多樣，不同業務場景的復雜度和規模也有差異，依賴和交互的模塊眾多，因此「如何設計出高內聚低耦合的架構，保證系統的可維護性和可擴展性」，成為重點考慮的方向。其中系統設計的關鍵考量包括，如何對不同的業務場景施加統一的管理控制能力，如流量分發、業務配置、任務管理、資源調度、監控診斷等；如何支持業務混部，實現業務錯峰復用，提升資源利用率并降低成本；如何提升并發性能，支持百萬級任務的實時調度和穩定運行；如何建設系統的可觀測性，提升問題感知和診斷效率等。
2.2 「實時性和可靠性」
RTC 媒體處理類的任務對實時性和可靠性的要求非常高。例如，用戶啟用RTC通話錄制，系統必須能夠迅速響應并立即啟動錄制任務。鑒于音視頻流的實時性，任何啟動延遲或失敗則導致不可逆的內容缺失，如果是審核任務還會導致內容漏審。同樣，旁路轉推任務的延遲可能導致直播切換時出現黑屏等體驗問題。
另外，RTC媒體處理類任務都是有狀態的服務，并且持續時間比較長，任務執行強依賴上下文信息的及時和準確。例如，合流任務必須實時感知房間內的音視頻流狀態，并可靠地接受用戶指令以設置正確的視頻布局。任何狀態信息的丟失或指令的延遲都可能引起合流過程的異常。「只有確保系統的高可用性和低延時，任務才能快速且正確地執行，從而為產品功能和用戶體驗提供基本保障?！?/strong>
2.3 「原子能力的抽象和復用」
無論是轉推、錄制還是音視頻審核等功能，都采用到一些相同的技術，例如都需要對音視頻數據進行處理，會涉及到編解碼、格式轉換、音視頻編輯、音畫質增強等操作，另外也都涉及到 RTC 系統跟其他系統之間的通信，如訪問直播、CDN、云存儲、第三方服務等，跟這些服務的通信也會使用到一些相同的傳輸協議，如 RTMP，HTTP，WebSocket等。「如何將這些技術和能力提煉和抽象成具備通用性的原子能力，并且通過統一的接口和框架可以被高效的編排和組合」，成為提高技術復用和研發效率的關鍵問題。
下面針對上述三方面的技術挑戰，我們逐一進行深入探討。
3.系統架構
系統建模主要圍繞 「“任務”」 這個核心概念，平臺支持的功能都以任務的形式提供服務，任務可以被看作是一個獨立的工作單元，它有明確的輸入、輸出和執行流程。所有的用戶請求都會關聯到具體的任務，系統按照任務粒度執行業務邏輯和資源分配，日志事件和監控診斷等也以任務維度做全鏈路關聯。
系統整體架構如上圖所示，主要分為三個部分。
- 「接入層」 API 網關接受用戶請求，對請求進行身份驗證和授權，支持對請求的并發控制，避免因惡意請求或突發的高流量導致系統異常。作為所有請求的統一入口，接入層承擔著關鍵的流量調度功能，可以根據系統的實際運行情況和業務需求，智能分配流量，確保資源的合理利用和業務的親和性。在下游故障時，可以自動熔斷，及時切斷問題鏈路，防止故障的進一步擴散。同時也支持人工切量，滿足日常運維和壓測管控等要求。
- 「任務管理和調度」基于微服務架構，作為控制面的主體，主要包括請求處理和資源調度。請求處理部分負責任務的啟?？刂疲芾砣蝿盏纳芷?，同時監控任務的執行進度和狀態，及時處理任務執行過程中出現的異常，支持任務重啟、熱遷移、重新調度等異常處理策略。資源調度會綜合考慮任務屬性、業務配置以及資源負載等多方面因素，將任務精準地分配給最合適的執行器。調度模塊通過一系列的基礎調度算法，努力實現任務和資源的最優匹配，這種匹配不僅僅是為了讓業務體驗達到最佳，同時也是為了實現資源效率的最大化。
- 「任務執行」分布式部署的計算集群為任務執行提供資源和環境。當任務被成功分配到執行器資源后，會啟動新的容器實例來執行業務邏輯，每個任務的容器實例是相互隔離的，任務結束后容器資源會被銷毀和回收。
在容器內部，業務邏輯的主要執行者是一個 worker 程序，worker 的實現采用了單體架構，它具備很強的通用性，支持平臺上所有的任務類型，通過不同的控制參數運行不同類型的任務。worker 程序是基于 pipeline 的框架結構，其中與音視頻處理相關的原子能力通過插件來實現，各任務類型通過創建 pipeline 和對插件進行合理編排實現各自的業務功能。worker 還集成了 RTC SDK，通過虛擬用戶加入 RTC 房間，實現與 RTC 網絡的互通，同時它也集成了其他的功能組件實現與其他服務之間的交互和協作。
4.高可用設計
RTC 業務的實時性屬性要求系統具備高可用設計和容災能力。當前系統從層級關系可以分為控制面和數據面，控制面負責任務管理和邏輯控制，數據面負責任務的具體執行，接下來我們討論一下在高可用設計中遇到的典型問題和解決思路。
4.1 控制面
為了保證用戶接入的穩定性和接入體驗，控制面服務做了全球多區域（Region）部署，區域內做了多可用區（AZ）設計，同 AZ 內的服務單元化部署，做到 AZ 內部調用鏈閉環。各 AZ 之間也不是完全隔離的，任務元信息等數據仍然需要在 AZ 之間做實時同步來提供容災能力。
具體實現路徑為，用戶請求通過公網動態加速網絡連接到 AZ，AZ 在接入層做一致性哈希將任務轉發到歸屬 AZ，確保同一個任務的請求在單一 AZ 完成。存儲層通過實時同步機制獲取其他 AZ 的任務信息，這樣每個 AZ 就擁有了全局的任務信息。在單個 AZ 不可用時，能夠保證其他 AZ 也能夠處理針對故障 AZ 的存量任務請求。
單可用區內部的高可用主要關注任務元信息的管理和存儲。由于存儲層訪問是請求處理的關鍵環節，其穩定性至關重要，我們采用「存儲分層和存儲互備」來增強存儲的可靠性，這些措施也有助于實現高并發處理和降低響應延遲。任務元信息的存儲會優先使用 Redis，Redis 不可用時降級到 ByteNDB（公司自研的分布式數據庫，兼容MySQL，同時具有高并發高吞吐，獨立擴縮容，存儲容量不受單機限制等優點），都不可用時會采用本地內存做兜底。任務元信息會通過消息隊列實時同步到其他 AZ，并達成在 DB 層的最終一致性和持久化。面對系統每天千萬級的新增任務量，我們采用了分片存儲技術以解決單一數據庫實例的性能和存儲容量方面的限制。
4.2 數據面
數據面主要指具體的任務執行邏輯。這部分的穩定性主要從以下幾個方面考慮：
- 「任務運行環境隔離，避免互相影響?！?/strong> 我們對所有任務類型做了容器化實現，通過為每個任務提供獨立的運行環境來避免任務之間的互相干擾。容器化還提升了任務調度和代碼升級的便利，例如新代碼發布時，我們構建出新版本的鏡像，通過將部分任務使用新鏡像，達到新代碼灰度發布的目的。
- 「提升任務運行環境的穩定性。」 這里主要討論2個基礎依賴：磁盤和網絡。
- 隨著機器長時間運行，磁盤老化引起的性能下降或者 IO 卡死等問題不可避免，解決方法主要采用兩個手段，一是周期性做 IO 健康度檢測，提前暴露風險，及時做替換和修復。二是代碼實現時降低對磁盤 IO 的依賴，例如錄制任務運行過程需要寫文件，在磁盤訪問遇到問題時，會切換到網絡存儲；程序運行中日志的打印也不能因為磁盤 IO 性能而影響主邏輯運行。
- 網絡問題主要考慮公網訪問的穩定性。公網訪問時我們部署了正向代理和 NAT 作為互備方案。每個服務的機房出口連接了多家運營商的線路，確保即使單一運營商線路出現故障，也不會影響業務的正常運行。此外我們也觀測到，在訪問特定的公有云存儲區域時，通過選擇特定的代理線路可以顯著提升數據傳輸的質量，我們也為這些場景配置了相應的訪問策略，以確保傳輸過程的高效和穩定。
- 「任務運行遇到故障時能夠快速恢復?！?/strong> 這里的恢復手段分兩個維度：容器內部和容器間。
任務在容器內運行時主要有 2 個部分，executor 和 worker，executor 承擔了本地代理的角色，負責接收控制面的任務指令，同時也會收集本地任務的運行狀態和數據指標等并上報給控制面。worker 負責業務邏輯的執行，包括推拉流、編解碼等計算。executor fork 出子進程運行 worker，在 worker 發生 crash 或者卡死等異常時會立即重啟 worker 進程，同時在監控到 worker 資源消耗超出配額時，則判斷是否是業務正常使用還是發生了異常，來決策是否要觸發業務降級降低資源消耗，或者實時增加該任務的資源配額。
容器實例異常退出時，調度服務會創建一個新的實例來恢復和繼續當前的任務，我們稱這種場景為重新調度，新任務實例會避開之前的機器節點和集群，減少二次失敗風險。在另外一些更嚴重的故障場景，如某個集群發生大面積故障時，我們支持對集群內的存量任務做主動遷移，通過將任務遷移到正常的集群來實現業務的更快速止損和恢復。
「提升故障感知和決策能力。」 高質量的決策依賴高質量的信息輸入，故障恢復策略的執行依賴故障信息判斷的可靠性和準確性。我們重點優化了兩類問題。
「信息傳輸鏈路的可靠性」?？刂泼娣蘸陀嬎慵邯毩⒉渴?，并不強綁定在同一機房。控制面部署在中心機房，而計算集群分布在中心機房、匯聚機房和邊緣機房。控制面跟計算集群之間通過內網專線、公網直連和公網加速等多種傳輸手段實現了多路徑傳輸，確?？刂菩帕钤趯＞€故障和公網抖動等異常下仍然實時可達。
「故障信息的準確性」。最典型的問題就是任務失聯，即控制面接受不到任務實例的?；钚畔ⅰＪ撛蚨喾N多樣，包括任務實例的網絡異常、任務機房的網絡問題，或是控制面實例自身的問題。在?；钍r，我們不僅采用重連重試等基礎措施，還會觸發機房內和機房間對故障任務的主動問詢，來進一步診斷失聯的具體原因。如果是任務實例問題則會觸發任務重調度，如果是集群故障可能會對整個集群做熔斷等。在做主動問詢時，需要特別關注請求風暴問題，尤其是集群網絡故障可能會導致大量任務?；钍?，瞬間觸發大量的探測請求，對服務造成巨大沖擊，我們采用頻控和聚集性判斷等策略來減少冗余請求。
「精細化的調度策略?！?/strong> 系統中任務種類繁多，每種任務對時延、音畫質量以及其承載的規模各不相同。因此，調度服務在為任務分配集群時，引入了評分機制，綜合考慮負載、成本、位置、業務偏好和 QoS 指標等多種因素，這個評分旨在衡量任務與集群之間的匹配度，同時考慮了任務需求和集群能力，而不是單方面評價集群。例如某個地區的推流節點故障導致轉推任務在某個集群異常，但這個集群的錄制任務是正常的，這時候轉推任務跟這個集群的匹配分低，但錄制任務跟這個集群的匹配是正常的，錄制任務還是可以繼續往這個集群調度。通過此類精細化的策略可以減少粗粒度的調度對集群資源和負載的沖擊，降低系統風險。
5.媒體處理框架
為了支持更多復雜的應用場景，提升系統的靈活性和可擴展性，媒體處理框架以模塊化和插件化為核心原則，將處理流程做了通用的抽象，整體上可以分為輸入、處理和輸出三個部分。
- 「輸入模塊」 負責媒體流的獲取。因為大多數功能都需要從 RTC 系統拉流，我們對 RTC 流的訂閱管理和數據回調進行了抽象和封裝，并適配多家主流 RTC 廠商接口，能夠非常方便的支持融合類的業務。同時，我們還實現了云端播放器功能，支持直播流和點播文件的輸入，并封裝文件讀取、時間戳同步、錯誤處理等復雜工作，進而對下游輸出可供直接渲染和播放的幀數據。
- 「處理模塊」 通過將原子能力抽象成獨立的插件，屏蔽內部實現細節，以實現媒體處理能力的可組合、可復用、可替換。這里面的模塊既包括音視頻處理相關的，如編解碼，視頻編輯，畫質增強等，也包括一些應用能力的模塊化，如 ASR，TTS，GPT等，有的能力是本地計算完成的，有的是通過調用其他遠程服務實現的，各插件通過靈活組合和搭配，構建適應不同場景需求的媒體處理 pipeline。
- 「輸出模塊」 完成處理結果的最終流向。涉及到的技術點主要是媒體封裝和傳輸，支持多種輸出形式。RTC 流的輸出仍然是通過 RTC SDK 發布到 RTC 系統，直播流會基于客戶指定的協議和參數推流到發布點，點播支持多種存儲協議和廠商，還有的場景需要將處理結果回調給客戶的業務服務器，如媒體流的審核結果、AI 識別結果等。
當前這套框架已經實現了豐富的模塊和插件能力，這些插件可以通過框架層進行組合和串聯，構成一個媒體應用，目前支持了 RTC 近十種業務。同時支持一些基礎功能進行二次組合，提供更高層的原子能力。如下圖所示，轉推直播與實時錄制的主要區別僅在于媒體流的最終去向，將轉推直播的輸出模塊替換為錄制存儲模塊，系統便可快速實現錄制功能。
6.應用舉例
6.1 云端錄制
用戶向云端發起錄制請求后，錄制任務通過 RTC SDK 加入房間，拉取需要錄制的音視頻流，然后以單流或合流的方式對音視頻流做編碼封裝，最后錄制文件存儲到用戶指定的存儲平臺，用戶在請求中可以指定訂閱用戶的媒體流類型、設置合圖布局樣式、設置錄制結果通知，設置編碼參數等。
針對用戶非常關心的「錄制文件的可靠性問題」，我們采取多種手段保障在斷電斷網等異常情況下文件不丟失。
- 首先，錄制過程中會實時分片，每隔數秒生成一個分片文件，并實時上傳到內部的暫存空間，保證在任務實例主機異常時最多丟失一個分片時長的視頻片段。
- 對于對數據丟失零容忍的用戶，我們支持實時雙錄，用戶發起一次請求，系統內部會啟動兩個完全獨立的任務，并且通過調度策略保證運行在不同的機房，當其中一個任務異常時，另外一個任務作為熱備。
- 如果訪問用戶指定的第三方存儲失敗或第三方存儲自身發生故障時，我們也會將錄制文件暫存到內部的存儲系統，保證文件不會丟失。
在錄制文件的音視頻質量方面，我們利用公司在行業領先的編碼器能力，能夠做到同等畫質下生成的錄制文件的體積更小，節省了錄制存儲，為用戶節省成本。
6.2 實時字幕
字幕任務啟動后，會訂閱房間里所有發布者的音頻流，接下來會經過有效語音檢測、語音識別、內容翻譯、內容合規、字幕平滑等步驟，最終將語音識別的結果分發出去。系統支持火山引擎和第三方語音識別和內容翻譯服務。同時，在字幕內容分發上，有多種方式選擇：
- 「RTS 點對點發送」 通過 RTC 支持的實時消息功能（RTS）將語音識別的結果發送給房間內需要的用戶；
- 「RTS 廣播」 通過 RTS 廣播方式將說話者的結果發送給房間內的所有用戶；
- 「視頻 SEI 發送」 語音識別結果通過 RTS 發送給說話者，說話者發布的視頻 SEI 中攜帶字幕內容；
- 「業務服務器分發」 字幕任務將語音識別結果回調給業務服務器，業務通過自己的業務邏輯做字幕分發；
前三種是基于 RTC 系統的分發方式，無論是端到端延時還是分發規模都能夠滿足主要場景的業務需求，也是我們更推薦的方式。
字幕功能已經被大規模應用在互娛社交、在線教學、視頻會議等 RTC 業務場景，其在抖音語聊房上線后，各項業務指標都表明能夠顯著提升用戶的互動沉浸感和在房間內的停留時長，業務收益顯著。
6.3 SIP會議網關
在視頻會議場景，基于 RTC 技術的云服務視頻會議已經成為主流，但企業對已經購買的傳統 SIP 終端利舊的需求也非常強烈，所以需要打通 RTC 終端和 SIP 會議硬件。與只有 RTC 終端參與通話的其他場景相比，SIP 會議網關在技術架構上引入了 2 個額外的模塊：「SIP access」 用來接受 SIP 終端注冊和 SIP 通話的呼入呼出，「SIP gateway」 負責 SIP 會話管理以及 SIP 和 RTC 之間的媒體協議轉換。SIP 會議網關服務支持以下能力：
- 「容災能力」：接入服務器和轉碼服務器都具有熱備功能，在服務器宕機時，系統能在 10 秒內自動切換，用戶無需手動操作，視頻會議可以繼續進行；
- 「布局樣式」：支持參會者姓名、頭像、靜音狀態等元素的繪制，支持演講者視圖、畫廊視圖、縮略視圖等多種布局，用戶可以在 SIP 終端通過 DTMF 按鍵實時切換布局；
- 「弱網對抗」：支持帶寬自適應，在弱網環境下能動態調整視頻和輔流的分辨率和幀率，針對 Cisco、Polycom、華為等廠商的 SIP 設備在 QoS 策略上的私有實現，我們也進行了適配，能夠提供更加流暢的會議體驗；
SIP 網關服務當前已經在應用在飛書視頻會議，每天支撐數萬臺 SIP 設備的日常會議請求。
6.4 呼叫中心
暫時無法在飛書文檔外展示此內容
我們對 SIP 網關服務進行了擴展，增加了 PSTN 呼叫功能，打通了 RTC 終端和電話終端，為呼叫中心等業務場景提供了云端呼叫能力。
- 通過 SIP trunking 方式對接運營商的 PSTN 網關，實現了跟 PSTN 電話網絡的信令互通，能夠向 PSTN 網絡發起電話外呼，也能夠從 PSTN 網絡接受呼入請求；
- IVR 引擎，業務可以選擇基于按鍵的傳統 IVR 和基于語音識別的智能 IVR，IVR 流支持放音收號、菜單交互、條件判斷等功能節點，可以基于不同的業務流程對 IVR 流靈活定義和編輯；
- 音頻降噪，針對呼叫中心坐席人員工位密集，說話互相有干擾，背景聲嘈雜等特點，我們對音頻 AI 降噪算法做了專門的模型訓練和優化適配，提升了通話音質；
該功能已經在飛書視頻會議和抖音客服等業務落地。抖音客服平臺采用了該方案后，將傳統的話機坐席替換成集成了 RTC 客戶端的軟件坐席，不僅提高了運營效率，還為用戶帶來了更好的通話體驗，用戶滿意度也顯著提升。
7.技術展望
作為定位于支撐更多 RTC 業務場景的應用平臺，我們希望能夠針對 RTC 業務領域的特點，提供更多原子能力和場景化解決方案，支撐客戶更加便捷的接入和搭建自己的業務，持續提升業務質量，降低客戶使用成本。我們會在以下方面做更長期的投入。
- 「原子能力更加豐富，框架更加靈活」：將基礎能力和組件按照單一職責做更合理的拆解，并且創建和引入更多的原子能力，這些能力可以來自公司內部，也可以來自公司外第三方，可以是工程能力，也可以是算法能力。原子能力與業務邏輯的實現和迭代解耦，平臺提供框架底座，業務通過對原子能力做靈活組裝和調度，在平臺上以插件化的形式進行開發。
- 「更好的業務性能，更低的資源成本：」 在并發性能、處理延遲和視頻畫質等方向提升產品能力上限。優化視頻編輯、視頻分析、視頻編碼、高清音質等場景下的算法性能。引入更多異構資源，包括不同類型的 CPU，GPU，FPGA，ARM等，根據不同任務的特點和需求最優化資源分配。探索算網融合，將計算和網絡緊密結合，降低數據傳輸成本，減少數據傳輸延遲，提升業務體驗。
- 「泛化平臺能力，推動業務創新和多元化」：將平臺構建起的一整套應用能力和解決方案泛化到其他相近的業務場景中，擴大業務的規模和多樣性。隨著生成式人工智能技術的突飛猛進，大模型已經能夠與用戶直接進行音視頻互動，端到端的實時多模態交互已經成為趨勢，RTC 的實時互動技術跟大模型的結合必將為各行各業帶來更多的可能性和創新機會，我們也希望抓住這個機遇為客戶帶來更多的業務價值。
