1.背景介紹

隨著實(shí)時(shí)音視頻（RTC）技術(shù)在娛樂、教育、會(huì)議、游戲等領(lǐng)域的廣泛應(yīng)用，用戶對(duì)音視頻通話的核心功能需求不斷提升，同時(shí)也衍生出許多擴(kuò)展需求。這些擴(kuò)展功能在業(yè)務(wù)場(chǎng)景扮演著越來越重要的作用，已經(jīng)成為許多業(yè)務(wù)場(chǎng)景的核心路徑。例如：

• 轉(zhuǎn)推直播 - 將直播間主播連麥的視頻合流轉(zhuǎn)推到 CDN 可以供更多人觀看；
• 實(shí)時(shí)錄制 - 將在線課堂中老師的教學(xué)和互動(dòng)內(nèi)容錄制下來供學(xué)生課后回看；
• 實(shí)時(shí)字幕 - 在跨國(guó)視頻會(huì)議中可以幫助參會(huì)者打破語言的界限，使信息傳遞更加準(zhǔn)確順暢；
• 輸入在線媒體流 - 將體育賽事直播視頻輸入到 RTC 房間，實(shí)現(xiàn)邊看邊聊；
• 電話呼叫 - 將固話和手機(jī)用戶加入到 RTC 通話；
• SIP互通 - 將傳統(tǒng)視頻會(huì)議設(shè)備加入 RTC 視頻會(huì)議；

這些擴(kuò)展能力不僅能夠提升 RTC 的互動(dòng)體驗(yàn)，延伸 RTC 的通信邊界，還能夠促進(jìn)業(yè)務(wù)創(chuàng)新，為業(yè)務(wù)創(chuàng)造新的收入來源。

2.技術(shù)挑戰(zhàn)

為了支持上述這些功能，我們?cè)O(shè)計(jì)并實(shí)現(xiàn)了 RTC 實(shí)時(shí)媒體處理平臺(tái)，這套系統(tǒng)高效支撐了內(nèi)外部業(yè)務(wù)的快速增長(zhǎng)和功能迭代，但在系統(tǒng)落地和演進(jìn)的過程中，我們也遇到了很多技術(shù)挑戰(zhàn)，可以總結(jié)為三大類。

2.1 「架構(gòu)設(shè)計(jì)」

系統(tǒng)需要支持的業(yè)務(wù)場(chǎng)景多樣，不同業(yè)務(wù)場(chǎng)景的復(fù)雜度和規(guī)模也有差異，依賴和交互的模塊眾多，因此「如何設(shè)計(jì)出高內(nèi)聚低耦合的架構(gòu)，保證系統(tǒng)的可維護(hù)性和可擴(kuò)展性」，成為重點(diǎn)考慮的方向。其中系統(tǒng)設(shè)計(jì)的關(guān)鍵考量包括，如何對(duì)不同的業(yè)務(wù)場(chǎng)景施加統(tǒng)一的管理控制能力，如流量分發(fā)、業(yè)務(wù)配置、任務(wù)管理、資源調(diào)度、監(jiān)控診斷等；如何支持業(yè)務(wù)混部，實(shí)現(xiàn)業(yè)務(wù)錯(cuò)峰復(fù)用，提升資源利用率并降低成本；如何提升并發(fā)性能，支持百萬級(jí)任務(wù)的實(shí)時(shí)調(diào)度和穩(wěn)定運(yùn)行；如何建設(shè)系統(tǒng)的可觀測(cè)性，提升問題感知和診斷效率等。

2.2 「實(shí)時(shí)性和可靠性」

RTC 媒體處理類的任務(wù)對(duì)實(shí)時(shí)性和可靠性的要求非常高。例如，用戶啟用RTC通話錄制，系統(tǒng)必須能夠迅速響應(yīng)并立即啟動(dòng)錄制任務(wù)。鑒于音視頻流的實(shí)時(shí)性，任何啟動(dòng)延遲或失敗則導(dǎo)致不可逆的內(nèi)容缺失，如果是審核任務(wù)還會(huì)導(dǎo)致內(nèi)容漏審。同樣，旁路轉(zhuǎn)推任務(wù)的延遲可能導(dǎo)致直播切換時(shí)出現(xiàn)黑屏等體驗(yàn)問題。

另外，RTC媒體處理類任務(wù)都是有狀態(tài)的服務(wù)，并且持續(xù)時(shí)間比較長(zhǎng)，任務(wù)執(zhí)行強(qiáng)依賴上下文信息的及時(shí)和準(zhǔn)確。例如，合流任務(wù)必須實(shí)時(shí)感知房間內(nèi)的音視頻流狀態(tài)，并可靠地接受用戶指令以設(shè)置正確的視頻布局。任何狀態(tài)信息的丟失或指令的延遲都可能引起合流過程的異常。「只有確保系統(tǒng)的高可用性和低延時(shí)，任務(wù)才能快速且正確地執(zhí)行，從而為產(chǎn)品功能和用戶體驗(yàn)提供基本保障。」

2.3 「原子能力的抽象和復(fù)用」

無論是轉(zhuǎn)推、錄制還是音視頻審核等功能，都采用到一些相同的技術(shù)，例如都需要對(duì)音視頻數(shù)據(jù)進(jìn)行處理，會(huì)涉及到編解碼、格式轉(zhuǎn)換、音視頻編輯、音畫質(zhì)增強(qiáng)等操作，另外也都涉及到 RTC 系統(tǒng)跟其他系統(tǒng)之間的通信，如訪問直播、CDN、云存儲(chǔ)、第三方服務(wù)等，跟這些服務(wù)的通信也會(huì)使用到一些相同的傳輸協(xié)議，如 RTMP，HTTP，WebSocket等。「如何將這些技術(shù)和能力提煉和抽象成具備通用性的原子能力，并且通過統(tǒng)一的接口和框架可以被高效的編排和組合」，成為提高技術(shù)復(fù)用和研發(fā)效率的關(guān)鍵問題。

下面針對(duì)上述三方面的技術(shù)挑戰(zhàn)，我們逐一進(jìn)行深入探討。

3.系統(tǒng)架構(gòu)

系統(tǒng)建模主要圍繞 「“任務(wù)”」 這個(gè)核心概念，平臺(tái)支持的功能都以任務(wù)的形式提供服務(wù)，任務(wù)可以被看作是一個(gè)獨(dú)立的工作單元，它有明確的輸入、輸出和執(zhí)行流程。所有的用戶請(qǐng)求都會(huì)關(guān)聯(lián)到具體的任務(wù)，系統(tǒng)按照任務(wù)粒度執(zhí)行業(yè)務(wù)邏輯和資源分配，日志事件和監(jiān)控診斷等也以任務(wù)維度做全鏈路關(guān)聯(lián)。

系統(tǒng)整體架構(gòu)如上圖所示，主要分為三個(gè)部分。

1. 「接入層」 API 網(wǎng)關(guān)接受用戶請(qǐng)求，對(duì)請(qǐng)求進(jìn)行身份驗(yàn)證和授權(quán)，支持對(duì)請(qǐng)求的并發(fā)控制，避免因惡意請(qǐng)求或突發(fā)的高流量導(dǎo)致系統(tǒng)異常。作為所有請(qǐng)求的統(tǒng)一入口，接入層承擔(dān)著關(guān)鍵的流量調(diào)度功能，可以根據(jù)系統(tǒng)的實(shí)際運(yùn)行情況和業(yè)務(wù)需求，智能分配流量，確保資源的合理利用和業(yè)務(wù)的親和性。在下游故障時(shí)，可以自動(dòng)熔斷，及時(shí)切斷問題鏈路，防止故障的進(jìn)一步擴(kuò)散。同時(shí)也支持人工切量，滿足日常運(yùn)維和壓測(cè)管控等要求。
2. 「任務(wù)管理和調(diào)度」基于微服務(wù)架構(gòu)，作為控制面的主體，主要包括請(qǐng)求處理和資源調(diào)度。請(qǐng)求處理部分負(fù)責(zé)任務(wù)的啟停控制，管理任務(wù)的生命周期，同時(shí)監(jiān)控任務(wù)的執(zhí)行進(jìn)度和狀態(tài)，及時(shí)處理任務(wù)執(zhí)行過程中出現(xiàn)的異常，支持任務(wù)重啟、熱遷移、重新調(diào)度等異常處理策略。資源調(diào)度會(huì)綜合考慮任務(wù)屬性、業(yè)務(wù)配置以及資源負(fù)載等多方面因素，將任務(wù)精準(zhǔn)地分配給最合適的執(zhí)行器。調(diào)度模塊通過一系列的基礎(chǔ)調(diào)度算法，努力實(shí)現(xiàn)任務(wù)和資源的最優(yōu)匹配，這種匹配不僅僅是為了讓業(yè)務(wù)體驗(yàn)達(dá)到最佳，同時(shí)也是為了實(shí)現(xiàn)資源效率的最大化。
3. 「任務(wù)執(zhí)行」分布式部署的計(jì)算集群為任務(wù)執(zhí)行提供資源和環(huán)境。當(dāng)任務(wù)被成功分配到執(zhí)行器資源后，會(huì)啟動(dòng)新的容器實(shí)例來執(zhí)行業(yè)務(wù)邏輯，每個(gè)任務(wù)的容器實(shí)例是相互隔離的，任務(wù)結(jié)束后容器資源會(huì)被銷毀和回收。

在容器內(nèi)部，業(yè)務(wù)邏輯的主要執(zhí)行者是一個(gè) worker 程序，worker 的實(shí)現(xiàn)采用了單體架構(gòu)，它具備很強(qiáng)的通用性，支持平臺(tái)上所有的任務(wù)類型，通過不同的控制參數(shù)運(yùn)行不同類型的任務(wù)。worker 程序是基于 pipeline 的框架結(jié)構(gòu)，其中與音視頻處理相關(guān)的原子能力通過插件來實(shí)現(xiàn)，各任務(wù)類型通過創(chuàng)建 pipeline 和對(duì)插件進(jìn)行合理編排實(shí)現(xiàn)各自的業(yè)務(wù)功能。worker 還集成了 RTC SDK，通過虛擬用戶加入 RTC 房間，實(shí)現(xiàn)與 RTC 網(wǎng)絡(luò)的互通，同時(shí)它也集成了其他的功能組件實(shí)現(xiàn)與其他服務(wù)之間的交互和協(xié)作。

4.高可用設(shè)計(jì)

RTC 業(yè)務(wù)的實(shí)時(shí)性屬性要求系統(tǒng)具備高可用設(shè)計(jì)和容災(zāi)能力。當(dāng)前系統(tǒng)從層級(jí)關(guān)系可以分為控制面和數(shù)據(jù)面，控制面負(fù)責(zé)任務(wù)管理和邏輯控制，數(shù)據(jù)面負(fù)責(zé)任務(wù)的具體執(zhí)行，接下來我們討論一下在高可用設(shè)計(jì)中遇到的典型問題和解決思路。

4.1 控制面

為了保證用戶接入的穩(wěn)定性和接入體驗(yàn)，控制面服務(wù)做了全球多區(qū)域（Region）部署，區(qū)域內(nèi)做了多可用區(qū)（AZ）設(shè)計(jì)，同 AZ 內(nèi)的服務(wù)單元化部署，做到 AZ 內(nèi)部調(diào)用鏈閉環(huán)。各 AZ 之間也不是完全隔離的，任務(wù)元信息等數(shù)據(jù)仍然需要在 AZ 之間做實(shí)時(shí)同步來提供容災(zāi)能力。

具體實(shí)現(xiàn)路徑為，用戶請(qǐng)求通過公網(wǎng)動(dòng)態(tài)加速網(wǎng)絡(luò)連接到 AZ，AZ 在接入層做一致性哈希將任務(wù)轉(zhuǎn)發(fā)到歸屬 AZ，確保同一個(gè)任務(wù)的請(qǐng)求在單一 AZ 完成。存儲(chǔ)層通過實(shí)時(shí)同步機(jī)制獲取其他 AZ 的任務(wù)信息，這樣每個(gè) AZ 就擁有了全局的任務(wù)信息。在單個(gè) AZ 不可用時(shí)，能夠保證其他 AZ 也能夠處理針對(duì)故障 AZ 的存量任務(wù)請(qǐng)求。

單可用區(qū)內(nèi)部的高可用主要關(guān)注任務(wù)元信息的管理和存儲(chǔ)。由于存儲(chǔ)層訪問是請(qǐng)求處理的關(guān)鍵環(huán)節(jié)，其穩(wěn)定性至關(guān)重要，我們采用「存儲(chǔ)分層和存儲(chǔ)互備」來增強(qiáng)存儲(chǔ)的可靠性，這些措施也有助于實(shí)現(xiàn)高并發(fā)處理和降低響應(yīng)延遲。任務(wù)元信息的存儲(chǔ)會(huì)優(yōu)先使用 Redis，Redis 不可用時(shí)降級(jí)到 ByteNDB（公司自研的分布式數(shù)據(jù)庫(kù)，兼容MySQL，同時(shí)具有高并發(fā)高吞吐，獨(dú)立擴(kuò)縮容，存儲(chǔ)容量不受單機(jī)限制等優(yōu)點(diǎn)），都不可用時(shí)會(huì)采用本地內(nèi)存做兜底。任務(wù)元信息會(huì)通過消息隊(duì)列實(shí)時(shí)同步到其他 AZ，并達(dá)成在 DB 層的最終一致性和持久化。面對(duì)系統(tǒng)每天千萬級(jí)的新增任務(wù)量，我們采用了分片存儲(chǔ)技術(shù)以解決單一數(shù)據(jù)庫(kù)實(shí)例的性能和存儲(chǔ)容量方面的限制。

4.2 數(shù)據(jù)面

數(shù)據(jù)面主要指具體的任務(wù)執(zhí)行邏輯。這部分的穩(wěn)定性主要從以下幾個(gè)方面考慮：

1. 「任務(wù)運(yùn)行環(huán)境隔離，避免互相影響。」 我們對(duì)所有任務(wù)類型做了容器化實(shí)現(xiàn)，通過為每個(gè)任務(wù)提供獨(dú)立的運(yùn)行環(huán)境來避免任務(wù)之間的互相干擾。容器化還提升了任務(wù)調(diào)度和代碼升級(jí)的便利，例如新代碼發(fā)布時(shí)，我們構(gòu)建出新版本的鏡像，通過將部分任務(wù)使用新鏡像，達(dá)到新代碼灰度發(fā)布的目的。
2. 「提升任務(wù)運(yùn)行環(huán)境的穩(wěn)定性。」 這里主要討論2個(gè)基礎(chǔ)依賴：磁盤和網(wǎng)絡(luò)。

1. 隨著機(jī)器長(zhǎng)時(shí)間運(yùn)行，磁盤老化引起的性能下降或者 IO 卡死等問題不可避免，解決方法主要采用兩個(gè)手段，一是周期性做 IO 健康度檢測(cè)，提前暴露風(fēng)險(xiǎn)，及時(shí)做替換和修復(fù)。二是代碼實(shí)現(xiàn)時(shí)降低對(duì)磁盤 IO 的依賴，例如錄制任務(wù)運(yùn)行過程需要寫文件，在磁盤訪問遇到問題時(shí)，會(huì)切換到網(wǎng)絡(luò)存儲(chǔ)；程序運(yùn)行中日志的打印也不能因?yàn)榇疟P IO 性能而影響主邏輯運(yùn)行。
2. 網(wǎng)絡(luò)問題主要考慮公網(wǎng)訪問的穩(wěn)定性。公網(wǎng)訪問時(shí)我們部署了正向代理和 NAT 作為互備方案。每個(gè)服務(wù)的機(jī)房出口連接了多家運(yùn)營(yíng)商的線路，確保即使單一運(yùn)營(yíng)商線路出現(xiàn)故障，也不會(huì)影響業(yè)務(wù)的正常運(yùn)行。此外我們也觀測(cè)到，在訪問特定的公有云存儲(chǔ)區(qū)域時(shí)，通過選擇特定的代理線路可以顯著提升數(shù)據(jù)傳輸?shù)馁|(zhì)量，我們也為這些場(chǎng)景配置了相應(yīng)的訪問策略，以確保傳輸過程的高效和穩(wěn)定。

3. 「任務(wù)運(yùn)行遇到故障時(shí)能夠快速恢復(fù)。」 這里的恢復(fù)手段分兩個(gè)維度：容器內(nèi)部和容器間。

1. 任務(wù)在容器內(nèi)運(yùn)行時(shí)主要有 2 個(gè)部分，executor 和 worker，executor 承擔(dān)了本地代理的角色，負(fù)責(zé)接收控制面的任務(wù)指令，同時(shí)也會(huì)收集本地任務(wù)的運(yùn)行狀態(tài)和數(shù)據(jù)指標(biāo)等并上報(bào)給控制面。worker 負(fù)責(zé)業(yè)務(wù)邏輯的執(zhí)行，包括推拉流、編解碼等計(jì)算。executor fork 出子進(jìn)程運(yùn)行 worker，在 worker 發(fā)生 crash 或者卡死等異常時(shí)會(huì)立即重啟 worker 進(jìn)程，同時(shí)在監(jiān)控到 worker 資源消耗超出配額時(shí)，則判斷是否是業(yè)務(wù)正常使用還是發(fā)生了異常，來決策是否要觸發(fā)業(yè)務(wù)降級(jí)降低資源消耗，或者實(shí)時(shí)增加該任務(wù)的資源配額。

2. 容器實(shí)例異常退出時(shí)，調(diào)度服務(wù)會(huì)創(chuàng)建一個(gè)新的實(shí)例來恢復(fù)和繼續(xù)當(dāng)前的任務(wù)，我們稱這種場(chǎng)景為重新調(diào)度，新任務(wù)實(shí)例會(huì)避開之前的機(jī)器節(jié)點(diǎn)和集群，減少二次失敗風(fēng)險(xiǎn)。在另外一些更嚴(yán)重的故障場(chǎng)景，如某個(gè)集群發(fā)生大面積故障時(shí)，我們支持對(duì)集群內(nèi)的存量任務(wù)做主動(dòng)遷移，通過將任務(wù)遷移到正常的集群來實(shí)現(xiàn)業(yè)務(wù)的更快速止損和恢復(fù)。

3. 
   

   「提升故障感知和決策能力。」 高質(zhì)量的決策依賴高質(zhì)量的信息輸入，故障恢復(fù)策略的執(zhí)行依賴故障信息判斷的可靠性和準(zhǔn)確性。我們重點(diǎn)優(yōu)化了兩類問題。

   
   

1. 「信息傳輸鏈路的可靠性」。控制面服務(wù)和計(jì)算集群獨(dú)立部署，并不強(qiáng)綁定在同一機(jī)房。控制面部署在中心機(jī)房，而計(jì)算集群分布在中心機(jī)房、匯聚機(jī)房和邊緣機(jī)房。控制面跟計(jì)算集群之間通過內(nèi)網(wǎng)專線、公網(wǎng)直連和公網(wǎng)加速等多種傳輸手段實(shí)現(xiàn)了多路徑傳輸，確保控制信令在專線故障和公網(wǎng)抖動(dòng)等異常下仍然實(shí)時(shí)可達(dá)。

2. 「故障信息的準(zhǔn)確性」。最典型的問題就是任務(wù)失聯(lián)，即控制面接受不到任務(wù)實(shí)例的保活信息。失聯(lián)原因多種多樣，包括任務(wù)實(shí)例的網(wǎng)絡(luò)異常、任務(wù)機(jī)房的網(wǎng)絡(luò)問題，或是控制面實(shí)例自身的問題。在保活失敗時(shí)，我們不僅采用重連重試等基礎(chǔ)措施，還會(huì)觸發(fā)機(jī)房?jī)?nèi)和機(jī)房間對(duì)故障任務(wù)的主動(dòng)問詢，來進(jìn)一步診斷失聯(lián)的具體原因。如果是任務(wù)實(shí)例問題則會(huì)觸發(fā)任務(wù)重調(diào)度，如果是集群故障可能會(huì)對(duì)整個(gè)集群做熔斷等。在做主動(dòng)問詢時(shí)，需要特別關(guān)注請(qǐng)求風(fēng)暴問題，尤其是集群網(wǎng)絡(luò)故障可能會(huì)導(dǎo)致大量任務(wù)保活失敗，瞬間觸發(fā)大量的探測(cè)請(qǐng)求，對(duì)服務(wù)造成巨大沖擊，我們采用頻控和聚集性判斷等策略來減少冗余請(qǐng)求。

3. 
   

   「精細(xì)化的調(diào)度策略。」 系統(tǒng)中任務(wù)種類繁多，每種任務(wù)對(duì)時(shí)延、音畫質(zhì)量以及其承載的規(guī)模各不相同。因此，調(diào)度服務(wù)在為任務(wù)分配集群時(shí)，引入了評(píng)分機(jī)制，綜合考慮負(fù)載、成本、位置、業(yè)務(wù)偏好和 QoS 指標(biāo)等多種因素，這個(gè)評(píng)分旨在衡量任務(wù)與集群之間的匹配度，同時(shí)考慮了任務(wù)需求和集群能力，而不是單方面評(píng)價(jià)集群。例如某個(gè)地區(qū)的推流節(jié)點(diǎn)故障導(dǎo)致轉(zhuǎn)推任務(wù)在某個(gè)集群異常，但這個(gè)集群的錄制任務(wù)是正常的，這時(shí)候轉(zhuǎn)推任務(wù)跟這個(gè)集群的匹配分低，但錄制任務(wù)跟這個(gè)集群的匹配是正常的，錄制任務(wù)還是可以繼續(xù)往這個(gè)集群調(diào)度。通過此類精細(xì)化的策略可以減少粗粒度的調(diào)度對(duì)集群資源和負(fù)載的沖擊，降低系統(tǒng)風(fēng)險(xiǎn)。

   
   

5.媒體處理框架

為了支持更多復(fù)雜的應(yīng)用場(chǎng)景，提升系統(tǒng)的靈活性和可擴(kuò)展性，媒體處理框架以模塊化和插件化為核心原則，將處理流程做了通用的抽象，整體上可以分為輸入、處理和輸出三個(gè)部分。

• 「輸入模塊」 負(fù)責(zé)媒體流的獲取。因?yàn)榇蠖鄶?shù)功能都需要從 RTC 系統(tǒng)拉流，我們對(duì) RTC 流的訂閱管理和數(shù)據(jù)回調(diào)進(jìn)行了抽象和封裝，并適配多家主流 RTC 廠商接口，能夠非常方便的支持融合類的業(yè)務(wù)。同時(shí)，我們還實(shí)現(xiàn)了云端播放器功能，支持直播流和點(diǎn)播文件的輸入，并封裝文件讀取、時(shí)間戳同步、錯(cuò)誤處理等復(fù)雜工作，進(jìn)而對(duì)下游輸出可供直接渲染和播放的幀數(shù)據(jù)。
• 「處理模塊」 通過將原子能力抽象成獨(dú)立的插件，屏蔽內(nèi)部實(shí)現(xiàn)細(xì)節(jié)，以實(shí)現(xiàn)媒體處理能力的可組合、可復(fù)用、可替換。這里面的模塊既包括音視頻處理相關(guān)的，如編解碼，視頻編輯，畫質(zhì)增強(qiáng)等，也包括一些應(yīng)用能力的模塊化，如 ASR，TTS，GPT等，有的能力是本地計(jì)算完成的，有的是通過調(diào)用其他遠(yuǎn)程服務(wù)實(shí)現(xiàn)的，各插件通過靈活組合和搭配，構(gòu)建適應(yīng)不同場(chǎng)景需求的媒體處理 pipeline。
• 「輸出模塊」 完成處理結(jié)果的最終流向。涉及到的技術(shù)點(diǎn)主要是媒體封裝和傳輸，支持多種輸出形式。RTC 流的輸出仍然是通過 RTC SDK 發(fā)布到 RTC 系統(tǒng)，直播流會(huì)基于客戶指定的協(xié)議和參數(shù)推流到發(fā)布點(diǎn)，點(diǎn)播支持多種存儲(chǔ)協(xié)議和廠商，還有的場(chǎng)景需要將處理結(jié)果回調(diào)給客戶的業(yè)務(wù)服務(wù)器，如媒體流的審核結(jié)果、AI 識(shí)別結(jié)果等。

當(dāng)前這套框架已經(jīng)實(shí)現(xiàn)了豐富的模塊和插件能力，這些插件可以通過框架層進(jìn)行組合和串聯(lián)，構(gòu)成一個(gè)媒體應(yīng)用，目前支持了 RTC 近十種業(yè)務(wù)。同時(shí)支持一些基礎(chǔ)功能進(jìn)行二次組合，提供更高層的原子能力。如下圖所示，轉(zhuǎn)推直播與實(shí)時(shí)錄制的主要區(qū)別僅在于媒體流的最終去向，將轉(zhuǎn)推直播的輸出模塊替換為錄制存儲(chǔ)模塊，系統(tǒng)便可快速實(shí)現(xiàn)錄制功能。

6.應(yīng)用舉例

6.1 云端錄制

用戶向云端發(fā)起錄制請(qǐng)求后，錄制任務(wù)通過 RTC SDK 加入房間，拉取需要錄制的音視頻流，然后以單流或合流的方式對(duì)音視頻流做編碼封裝，最后錄制文件存儲(chǔ)到用戶指定的存儲(chǔ)平臺(tái)，用戶在請(qǐng)求中可以指定訂閱用戶的媒體流類型、設(shè)置合圖布局樣式、設(shè)置錄制結(jié)果通知，設(shè)置編碼參數(shù)等。

針對(duì)用戶非常關(guān)心的「錄制文件的可靠性問題」，我們采取多種手段保障在斷電斷網(wǎng)等異常情況下文件不丟失。

• 首先，錄制過程中會(huì)實(shí)時(shí)分片，每隔數(shù)秒生成一個(gè)分片文件，并實(shí)時(shí)上傳到內(nèi)部的暫存空間，保證在任務(wù)實(shí)例主機(jī)異常時(shí)最多丟失一個(gè)分片時(shí)長(zhǎng)的視頻片段。
• 對(duì)于對(duì)數(shù)據(jù)丟失零容忍的用戶，我們支持實(shí)時(shí)雙錄，用戶發(fā)起一次請(qǐng)求，系統(tǒng)內(nèi)部會(huì)啟動(dòng)兩個(gè)完全獨(dú)立的任務(wù)，并且通過調(diào)度策略保證運(yùn)行在不同的機(jī)房，當(dāng)其中一個(gè)任務(wù)異常時(shí)，另外一個(gè)任務(wù)作為熱備。
• 如果訪問用戶指定的第三方存儲(chǔ)失敗或第三方存儲(chǔ)自身發(fā)生故障時(shí)，我們也會(huì)將錄制文件暫存到內(nèi)部的存儲(chǔ)系統(tǒng)，保證文件不會(huì)丟失。

在錄制文件的音視頻質(zhì)量方面，我們利用公司在行業(yè)領(lǐng)先的編碼器能力，能夠做到同等畫質(zhì)下生成的錄制文件的體積更小，節(jié)省了錄制存儲(chǔ)，為用戶節(jié)省成本。

6.2 實(shí)時(shí)字幕

字幕任務(wù)啟動(dòng)后，會(huì)訂閱房間里所有發(fā)布者的音頻流，接下來會(huì)經(jīng)過有效語音檢測(cè)、語音識(shí)別、內(nèi)容翻譯、內(nèi)容合規(guī)、字幕平滑等步驟，最終將語音識(shí)別的結(jié)果分發(fā)出去。系統(tǒng)支持火山引擎和第三方語音識(shí)別和內(nèi)容翻譯服務(wù)。同時(shí)，在字幕內(nèi)容分發(fā)上，有多種方式選擇：

• 「RTS 點(diǎn)對(duì)點(diǎn)發(fā)送」 通過 RTC 支持的實(shí)時(shí)消息功能（RTS）將語音識(shí)別的結(jié)果發(fā)送給房間內(nèi)需要的用戶；
• 「RTS 廣播」 通過 RTS 廣播方式將說話者的結(jié)果發(fā)送給房間內(nèi)的所有用戶；
• 「視頻 SEI 發(fā)送」 語音識(shí)別結(jié)果通過 RTS 發(fā)送給說話者，說話者發(fā)布的視頻 SEI 中攜帶字幕內(nèi)容；
• 「業(yè)務(wù)服務(wù)器分發(fā)」 字幕任務(wù)將語音識(shí)別結(jié)果回調(diào)給業(yè)務(wù)服務(wù)器，業(yè)務(wù)通過自己的業(yè)務(wù)邏輯做字幕分發(fā)；

前三種是基于 RTC 系統(tǒng)的分發(fā)方式，無論是端到端延時(shí)還是分發(fā)規(guī)模都能夠滿足主要場(chǎng)景的業(yè)務(wù)需求，也是我們更推薦的方式。

字幕功能已經(jīng)被大規(guī)模應(yīng)用在互娛社交、在線教學(xué)、視頻會(huì)議等 RTC 業(yè)務(wù)場(chǎng)景，其在抖音語聊房上線后，各項(xiàng)業(yè)務(wù)指標(biāo)都表明能夠顯著提升用戶的互動(dòng)沉浸感和在房間內(nèi)的停留時(shí)長(zhǎng)，業(yè)務(wù)收益顯著。

6.3 SIP會(huì)議網(wǎng)關(guān)

在視頻會(huì)議場(chǎng)景，基于 RTC 技術(shù)的云服務(wù)視頻會(huì)議已經(jīng)成為主流，但企業(yè)對(duì)已經(jīng)購(gòu)買的傳統(tǒng) SIP 終端利舊的需求也非常強(qiáng)烈，所以需要打通 RTC 終端和 SIP 會(huì)議硬件。與只有 RTC 終端參與通話的其他場(chǎng)景相比，SIP 會(huì)議網(wǎng)關(guān)在技術(shù)架構(gòu)上引入了 2 個(gè)額外的模塊：「SIP access」 用來接受 SIP 終端注冊(cè)和 SIP 通話的呼入呼出，「SIP gateway」 負(fù)責(zé) SIP 會(huì)話管理以及 SIP 和 RTC 之間的媒體協(xié)議轉(zhuǎn)換。SIP 會(huì)議網(wǎng)關(guān)服務(wù)支持以下能力：

• 「容災(zāi)能力」：接入服務(wù)器和轉(zhuǎn)碼服務(wù)器都具有熱備功能，在服務(wù)器宕機(jī)時(shí)，系統(tǒng)能在 10 秒內(nèi)自動(dòng)切換，用戶無需手動(dòng)操作，視頻會(huì)議可以繼續(xù)進(jìn)行；
• 「布局樣式」：支持參會(huì)者姓名、頭像、靜音狀態(tài)等元素的繪制，支持演講者視圖、畫廊視圖、縮略視圖等多種布局，用戶可以在 SIP 終端通過 DTMF 按鍵實(shí)時(shí)切換布局；
• 「弱網(wǎng)對(duì)抗」：支持帶寬自適應(yīng)，在弱網(wǎng)環(huán)境下能動(dòng)態(tài)調(diào)整視頻和輔流的分辨率和幀率，針對(duì) Cisco、Polycom、華為等廠商的 SIP 設(shè)備在 QoS 策略上的私有實(shí)現(xiàn)，我們也進(jìn)行了適配，能夠提供更加流暢的會(huì)議體驗(yàn)；

SIP 網(wǎng)關(guān)服務(wù)當(dāng)前已經(jīng)在應(yīng)用在飛書視頻會(huì)議，每天支撐數(shù)萬臺(tái) SIP 設(shè)備的日常會(huì)議請(qǐng)求。

6.4 呼叫中心

暫時(shí)無法在飛書文檔外展示此內(nèi)容

我們對(duì) SIP 網(wǎng)關(guān)服務(wù)進(jìn)行了擴(kuò)展，增加了 PSTN 呼叫功能，打通了 RTC 終端和電話終端，為呼叫中心等業(yè)務(wù)場(chǎng)景提供了云端呼叫能力。

• 通過 SIP trunking 方式對(duì)接運(yùn)營(yíng)商的 PSTN 網(wǎng)關(guān)，實(shí)現(xiàn)了跟 PSTN 電話網(wǎng)絡(luò)的信令互通，能夠向 PSTN 網(wǎng)絡(luò)發(fā)起電話外呼，也能夠從 PSTN 網(wǎng)絡(luò)接受呼入請(qǐng)求；
• IVR 引擎，業(yè)務(wù)可以選擇基于按鍵的傳統(tǒng) IVR 和基于語音識(shí)別的智能 IVR，IVR 流支持放音收號(hào)、菜單交互、條件判斷等功能節(jié)點(diǎn)，可以基于不同的業(yè)務(wù)流程對(duì) IVR 流靈活定義和編輯；
• 音頻降噪，針對(duì)呼叫中心坐席人員工位密集，說話互相有干擾，背景聲嘈雜等特點(diǎn)，我們對(duì)音頻 AI 降噪算法做了專門的模型訓(xùn)練和優(yōu)化適配，提升了通話音質(zhì)；

該功能已經(jīng)在飛書視頻會(huì)議和抖音客服等業(yè)務(wù)落地。抖音客服平臺(tái)采用了該方案后，將傳統(tǒng)的話機(jī)坐席替換成集成了 RTC 客戶端的軟件坐席，不僅提高了運(yùn)營(yíng)效率，還為用戶帶來了更好的通話體驗(yàn)，用戶滿意度也顯著提升。

7.技術(shù)展望

作為定位于支撐更多 RTC 業(yè)務(wù)場(chǎng)景的應(yīng)用平臺(tái)，我們希望能夠針對(duì) RTC 業(yè)務(wù)領(lǐng)域的特點(diǎn)，提供更多原子能力和場(chǎng)景化解決方案，支撐客戶更加便捷的接入和搭建自己的業(yè)務(wù)，持續(xù)提升業(yè)務(wù)質(zhì)量，降低客戶使用成本。我們會(huì)在以下方面做更長(zhǎng)期的投入。

• 「原子能力更加豐富，框架更加靈活」：將基礎(chǔ)能力和組件按照單一職責(zé)做更合理的拆解，并且創(chuàng)建和引入更多的原子能力，這些能力可以來自公司內(nèi)部，也可以來自公司外第三方，可以是工程能力，也可以是算法能力。原子能力與業(yè)務(wù)邏輯的實(shí)現(xiàn)和迭代解耦，平臺(tái)提供框架底座，業(yè)務(wù)通過對(duì)原子能力做靈活組裝和調(diào)度，在平臺(tái)上以插件化的形式進(jìn)行開發(fā)。
• 「更好的業(yè)務(wù)性能，更低的資源成本：」 在并發(fā)性能、處理延遲和視頻畫質(zhì)等方向提升產(chǎn)品能力上限。優(yōu)化視頻編輯、視頻分析、視頻編碼、高清音質(zhì)等場(chǎng)景下的算法性能。引入更多異構(gòu)資源，包括不同類型的 CPU，GPU，F(xiàn)PGA，ARM等，根據(jù)不同任務(wù)的特點(diǎn)和需求最優(yōu)化資源分配。探索算網(wǎng)融合，將計(jì)算和網(wǎng)絡(luò)緊密結(jié)合，降低數(shù)據(jù)傳輸成本，減少數(shù)據(jù)傳輸延遲，提升業(yè)務(wù)體驗(yàn)。
• 「泛化平臺(tái)能力，推動(dòng)業(yè)務(wù)創(chuàng)新和多元化」：將平臺(tái)構(gòu)建起的一整套應(yīng)用能力和解決方案泛化到其他相近的業(yè)務(wù)場(chǎng)景中，擴(kuò)大業(yè)務(wù)的規(guī)模和多樣性。隨著生成式人工智能技術(shù)的突飛猛進(jìn)，大模型已經(jīng)能夠與用戶直接進(jìn)行音視頻互動(dòng)，端到端的實(shí)時(shí)多模態(tài)交互已經(jīng)成為趨勢(shì)，RTC 的實(shí)時(shí)互動(dòng)技術(shù)跟大模型的結(jié)合必將為各行各業(yè)帶來更多的可能性和創(chuàng)新機(jī)會(huì)，我們也希望抓住這個(gè)機(jī)遇為客戶帶來更多的業(yè)務(wù)價(jià)值。