2023年Q2用戶偏好榜：12+256G版本成新主流
3月份的性能榜、性價比榜和好評榜之后，就要輪到2023年的第二季度偏好榜了，上半年的新機潮已經(jīng)過去，最明顯的肯定就是大內(nèi)存和存儲的機型了，另外部分中端機也取消了屏幕塑料支架
隨著實時音視頻（RTC）技術(shù)在娛樂、教育、會議、游戲等領(lǐng)域的廣泛應(yīng)用，用戶對音視頻通話的核心功能需求不斷提升，同時也衍生出許多擴展需求。這些擴展功能在業(yè)務(wù)場景扮演著越來越重要的作用，已經(jīng)成為許多業(yè)務(wù)場景的核心路徑。例如：
這些擴展能力不僅能夠提升 RTC 的互動體驗，延伸 RTC 的通信邊界，還能夠促進業(yè)務(wù)創(chuàng)新，為業(yè)務(wù)創(chuàng)造新的收入來源。
為了支持上述這些功能，我們設(shè)計并實現(xiàn)了 RTC 實時媒體處理平臺，這套系統(tǒng)高效支撐了內(nèi)外部業(yè)務(wù)的快速增長和功能迭代，但在系統(tǒng)落地和演進的過程中，我們也遇到了很多技術(shù)挑戰(zhàn)，可以總結(jié)為三大類。
系統(tǒng)需要支持的業(yè)務(wù)場景多樣，不同業(yè)務(wù)場景的復(fù)雜度和規(guī)模也有差異，依賴和交互的模塊眾多，因此「如何設(shè)計出高內(nèi)聚低耦合的架構(gòu)，保證系統(tǒng)的可維護性和可擴展性」，成為重點考慮的方向。其中系統(tǒng)設(shè)計的關(guān)鍵考量包括，如何對不同的業(yè)務(wù)場景施加統(tǒng)一的管理控制能力，如流量分發(fā)、業(yè)務(wù)配置、任務(wù)管理、資源調(diào)度、監(jiān)控診斷等；如何支持業(yè)務(wù)混部，實現(xiàn)業(yè)務(wù)錯峰復(fù)用，提升資源利用率并降低成本；如何提升并發(fā)性能，支持百萬級任務(wù)的實時調(diào)度和穩(wěn)定運行；如何建設(shè)系統(tǒng)的可觀測性，提升問題感知和診斷效率等。
RTC 媒體處理類的任務(wù)對實時性和可靠性的要求非常高。例如，用戶啟用RTC通話錄制，系統(tǒng)必須能夠迅速響應(yīng)并立即啟動錄制任務(wù)。鑒于音視頻流的實時性，任何啟動延遲或失敗則導(dǎo)致不可逆的內(nèi)容缺失，如果是審核任務(wù)還會導(dǎo)致內(nèi)容漏審。同樣，旁路轉(zhuǎn)推任務(wù)的延遲可能導(dǎo)致直播切換時出現(xiàn)黑屏等體驗問題。
另外，RTC媒體處理類任務(wù)都是有狀態(tài)的服務(wù)，并且持續(xù)時間比較長，任務(wù)執(zhí)行強依賴上下文信息的及時和準(zhǔn)確。例如，合流任務(wù)必須實時感知房間內(nèi)的音視頻流狀態(tài)，并可靠地接受用戶指令以設(shè)置正確的視頻布局。任何狀態(tài)信息的丟失或指令的延遲都可能引起合流過程的異常。「只有確保系統(tǒng)的高可用性和低延時，任務(wù)才能快速且正確地執(zhí)行，從而為產(chǎn)品功能和用戶體驗提供基本保障。」
無論是轉(zhuǎn)推、錄制還是音視頻審核等功能，都采用到一些相同的技術(shù)，例如都需要對音視頻數(shù)據(jù)進行處理，會涉及到編解碼、格式轉(zhuǎn)換、音視頻編輯、音畫質(zhì)增強等操作，另外也都涉及到 RTC 系統(tǒng)跟其他系統(tǒng)之間的通信，如訪問直播、CDN、云存儲、第三方服務(wù)等，跟這些服務(wù)的通信也會使用到一些相同的傳輸協(xié)議，如 RTMP，HTTP，WebSocket等。「如何將這些技術(shù)和能力提煉和抽象成具備通用性的原子能力，并且通過統(tǒng)一的接口和框架可以被高效的編排和組合」，成為提高技術(shù)復(fù)用和研發(fā)效率的關(guān)鍵問題。
下面針對上述三方面的技術(shù)挑戰(zhàn)，我們逐一進行深入探討。
系統(tǒng)建模主要圍繞 「“任務(wù)”」 這個核心概念，平臺支持的功能都以任務(wù)的形式提供服務(wù)，任務(wù)可以被看作是一個獨立的工作單元，它有明確的輸入、輸出和執(zhí)行流程。所有的用戶請求都會關(guān)聯(lián)到具體的任務(wù)，系統(tǒng)按照任務(wù)粒度執(zhí)行業(yè)務(wù)邏輯和資源分配，日志事件和監(jiān)控診斷等也以任務(wù)維度做全鏈路關(guān)聯(lián)。
系統(tǒng)整體架構(gòu)如上圖所示，主要分為三個部分。
在容器內(nèi)部，業(yè)務(wù)邏輯的主要執(zhí)行者是一個 worker 程序，worker 的實現(xiàn)采用了單體架構(gòu)，它具備很強的通用性，支持平臺上所有的任務(wù)類型，通過不同的控制參數(shù)運行不同類型的任務(wù)。worker 程序是基于 pipeline 的框架結(jié)構(gòu)，其中與音視頻處理相關(guān)的原子能力通過插件來實現(xiàn)，各任務(wù)類型通過創(chuàng)建 pipeline 和對插件進行合理編排實現(xiàn)各自的業(yè)務(wù)功能。worker 還集成了 RTC SDK，通過虛擬用戶加入 RTC 房間，實現(xiàn)與 RTC 網(wǎng)絡(luò)的互通，同時它也集成了其他的功能組件實現(xiàn)與其他服務(wù)之間的交互和協(xié)作。
RTC 業(yè)務(wù)的實時性屬性要求系統(tǒng)具備高可用設(shè)計和容災(zāi)能力。當(dāng)前系統(tǒng)從層級關(guān)系可以分為控制面和數(shù)據(jù)面，控制面負責(zé)任務(wù)管理和邏輯控制，數(shù)據(jù)面負責(zé)任務(wù)的具體執(zhí)行，接下來我們討論一下在高可用設(shè)計中遇到的典型問題和解決思路。
為了保證用戶接入的穩(wěn)定性和接入體驗，控制面服務(wù)做了全球多區(qū)域（Region）部署，區(qū)域內(nèi)做了多可用區(qū)（AZ）設(shè)計，同 AZ 內(nèi)的服務(wù)單元化部署，做到 AZ 內(nèi)部調(diào)用鏈閉環(huán)。各 AZ 之間也不是完全隔離的，任務(wù)元信息等數(shù)據(jù)仍然需要在 AZ 之間做實時同步來提供容災(zāi)能力。
具體實現(xiàn)路徑為，用戶請求通過公網(wǎng)動態(tài)加速網(wǎng)絡(luò)連接到 AZ，AZ 在接入層做一致性哈希將任務(wù)轉(zhuǎn)發(fā)到歸屬 AZ，確保同一個任務(wù)的請求在單一 AZ 完成。存儲層通過實時同步機制獲取其他 AZ 的任務(wù)信息，這樣每個 AZ 就擁有了全局的任務(wù)信息。在單個 AZ 不可用時，能夠保證其他 AZ 也能夠處理針對故障 AZ 的存量任務(wù)請求。
單可用區(qū)內(nèi)部的高可用主要關(guān)注任務(wù)元信息的管理和存儲。由于存儲層訪問是請求處理的關(guān)鍵環(huán)節(jié)，其穩(wěn)定性至關(guān)重要，我們采用「存儲分層和存儲互備」來增強存儲的可靠性，這些措施也有助于實現(xiàn)高并發(fā)處理和降低響應(yīng)延遲。任務(wù)元信息的存儲會優(yōu)先使用 Redis，Redis 不可用時降級到 ByteNDB（公司自研的分布式數(shù)據(jù)庫，兼容MySQL，同時具有高并發(fā)高吞吐，獨立擴縮容，存儲容量不受單機限制等優(yōu)點），都不可用時會采用本地內(nèi)存做兜底。任務(wù)元信息會通過消息隊列實時同步到其他 AZ，并達成在 DB 層的最終一致性和持久化。面對系統(tǒng)每天千萬級的新增任務(wù)量，我們采用了分片存儲技術(shù)以解決單一數(shù)據(jù)庫實例的性能和存儲容量方面的限制。
數(shù)據(jù)面主要指具體的任務(wù)執(zhí)行邏輯。這部分的穩(wěn)定性主要從以下幾個方面考慮：
任務(wù)在容器內(nèi)運行時主要有 2 個部分，executor 和 worker，executor 承擔(dān)了本地代理的角色，負責(zé)接收控制面的任務(wù)指令，同時也會收集本地任務(wù)的運行狀態(tài)和數(shù)據(jù)指標(biāo)等并上報給控制面。worker 負責(zé)業(yè)務(wù)邏輯的執(zhí)行，包括推拉流、編解碼等計算。executor fork 出子進程運行 worker，在 worker 發(fā)生 crash 或者卡死等異常時會立即重啟 worker 進程，同時在監(jiān)控到 worker 資源消耗超出配額時，則判斷是否是業(yè)務(wù)正常使用還是發(fā)生了異常，來決策是否要觸發(fā)業(yè)務(wù)降級降低資源消耗，或者實時增加該任務(wù)的資源配額。
容器實例異常退出時，調(diào)度服務(wù)會創(chuàng)建一個新的實例來恢復(fù)和繼續(xù)當(dāng)前的任務(wù)，我們稱這種場景為重新調(diào)度，新任務(wù)實例會避開之前的機器節(jié)點和集群，減少二次失敗風(fēng)險。在另外一些更嚴(yán)重的故障場景，如某個集群發(fā)生大面積故障時，我們支持對集群內(nèi)的存量任務(wù)做主動遷移，通過將任務(wù)遷移到正常的集群來實現(xiàn)業(yè)務(wù)的更快速止損和恢復(fù)。
「提升故障感知和決策能力。」 高質(zhì)量的決策依賴高質(zhì)量的信息輸入，故障恢復(fù)策略的執(zhí)行依賴故障信息判斷的可靠性和準(zhǔn)確性。我們重點優(yōu)化了兩類問題。
「信息傳輸鏈路的可靠性」。控制面服務(wù)和計算集群獨立部署，并不強綁定在同一機房。控制面部署在中心機房，而計算集群分布在中心機房、匯聚機房和邊緣機房。控制面跟計算集群之間通過內(nèi)網(wǎng)專線、公網(wǎng)直連和公網(wǎng)加速等多種傳輸手段實現(xiàn)了多路徑傳輸，確保控制信令在專線故障和公網(wǎng)抖動等異常下仍然實時可達。
「故障信息的準(zhǔn)確性」。最典型的問題就是任務(wù)失聯(lián)，即控制面接受不到任務(wù)實例的保活信息。失聯(lián)原因多種多樣，包括任務(wù)實例的網(wǎng)絡(luò)異常、任務(wù)機房的網(wǎng)絡(luò)問題，或是控制面實例自身的問題。在保活失敗時，我們不僅采用重連重試等基礎(chǔ)措施，還會觸發(fā)機房內(nèi)和機房間對故障任務(wù)的主動問詢，來進一步診斷失聯(lián)的具體原因。如果是任務(wù)實例問題則會觸發(fā)任務(wù)重調(diào)度，如果是集群故障可能會對整個集群做熔斷等。在做主動問詢時，需要特別關(guān)注請求風(fēng)暴問題，尤其是集群網(wǎng)絡(luò)故障可能會導(dǎo)致大量任務(wù)保活失敗，瞬間觸發(fā)大量的探測請求，對服務(wù)造成巨大沖擊，我們采用頻控和聚集性判斷等策略來減少冗余請求。
「精細化的調(diào)度策略。」 系統(tǒng)中任務(wù)種類繁多，每種任務(wù)對時延、音畫質(zhì)量以及其承載的規(guī)模各不相同。因此，調(diào)度服務(wù)在為任務(wù)分配集群時，引入了評分機制，綜合考慮負載、成本、位置、業(yè)務(wù)偏好和 QoS 指標(biāo)等多種因素，這個評分旨在衡量任務(wù)與集群之間的匹配度，同時考慮了任務(wù)需求和集群能力，而不是單方面評價集群。例如某個地區(qū)的推流節(jié)點故障導(dǎo)致轉(zhuǎn)推任務(wù)在某個集群異常，但這個集群的錄制任務(wù)是正常的，這時候轉(zhuǎn)推任務(wù)跟這個集群的匹配分低，但錄制任務(wù)跟這個集群的匹配是正常的，錄制任務(wù)還是可以繼續(xù)往這個集群調(diào)度。通過此類精細化的策略可以減少粗粒度的調(diào)度對集群資源和負載的沖擊，降低系統(tǒng)風(fēng)險。
為了支持更多復(fù)雜的應(yīng)用場景，提升系統(tǒng)的靈活性和可擴展性，媒體處理框架以模塊化和插件化為核心原則，將處理流程做了通用的抽象，整體上可以分為輸入、處理和輸出三個部分。
當(dāng)前這套框架已經(jīng)實現(xiàn)了豐富的模塊和插件能力，這些插件可以通過框架層進行組合和串聯(lián)，構(gòu)成一個媒體應(yīng)用，目前支持了 RTC 近十種業(yè)務(wù)。同時支持一些基礎(chǔ)功能進行二次組合，提供更高層的原子能力。如下圖所示，轉(zhuǎn)推直播與實時錄制的主要區(qū)別僅在于媒體流的最終去向，將轉(zhuǎn)推直播的輸出模塊替換為錄制存儲模塊，系統(tǒng)便可快速實現(xiàn)錄制功能。
用戶向云端發(fā)起錄制請求后，錄制任務(wù)通過 RTC SDK 加入房間，拉取需要錄制的音視頻流，然后以單流或合流的方式對音視頻流做編碼封裝，最后錄制文件存儲到用戶指定的存儲平臺，用戶在請求中可以指定訂閱用戶的媒體流類型、設(shè)置合圖布局樣式、設(shè)置錄制結(jié)果通知，設(shè)置編碼參數(shù)等。
針對用戶非常關(guān)心的「錄制文件的可靠性問題」，我們采取多種手段保障在斷電斷網(wǎng)等異常情況下文件不丟失。
在錄制文件的音視頻質(zhì)量方面，我們利用公司在行業(yè)領(lǐng)先的編碼器能力，能夠做到同等畫質(zhì)下生成的錄制文件的體積更小，節(jié)省了錄制存儲，為用戶節(jié)省成本。
字幕任務(wù)啟動后，會訂閱房間里所有發(fā)布者的音頻流，接下來會經(jīng)過有效語音檢測、語音識別、內(nèi)容翻譯、內(nèi)容合規(guī)、字幕平滑等步驟，最終將語音識別的結(jié)果分發(fā)出去。系統(tǒng)支持火山引擎和第三方語音識別和內(nèi)容翻譯服務(wù)。同時，在字幕內(nèi)容分發(fā)上，有多種方式選擇：
前三種是基于 RTC 系統(tǒng)的分發(fā)方式，無論是端到端延時還是分發(fā)規(guī)模都能夠滿足主要場景的業(yè)務(wù)需求，也是我們更推薦的方式。
字幕功能已經(jīng)被大規(guī)模應(yīng)用在互娛社交、在線教學(xué)、視頻會議等 RTC 業(yè)務(wù)場景，其在抖音語聊房上線后，各項業(yè)務(wù)指標(biāo)都表明能夠顯著提升用戶的互動沉浸感和在房間內(nèi)的停留時長，業(yè)務(wù)收益顯著。
在視頻會議場景，基于 RTC 技術(shù)的云服務(wù)視頻會議已經(jīng)成為主流，但企業(yè)對已經(jīng)購買的傳統(tǒng) SIP 終端利舊的需求也非常強烈，所以需要打通 RTC 終端和 SIP 會議硬件。與只有 RTC 終端參與通話的其他場景相比，SIP 會議網(wǎng)關(guān)在技術(shù)架構(gòu)上引入了 2 個額外的模塊：「SIP access」 用來接受 SIP 終端注冊和 SIP 通話的呼入呼出，「SIP gateway」 負責(zé) SIP 會話管理以及 SIP 和 RTC 之間的媒體協(xié)議轉(zhuǎn)換。SIP 會議網(wǎng)關(guān)服務(wù)支持以下能力：
SIP 網(wǎng)關(guān)服務(wù)當(dāng)前已經(jīng)在應(yīng)用在飛書視頻會議，每天支撐數(shù)萬臺 SIP 設(shè)備的日常會議請求。
暫時無法在飛書文檔外展示此內(nèi)容
我們對 SIP 網(wǎng)關(guān)服務(wù)進行了擴展，增加了 PSTN 呼叫功能，打通了 RTC 終端和電話終端，為呼叫中心等業(yè)務(wù)場景提供了云端呼叫能力。
該功能已經(jīng)在飛書視頻會議和抖音客服等業(yè)務(wù)落地。抖音客服平臺采用了該方案后，將傳統(tǒng)的話機坐席替換成集成了 RTC 客戶端的軟件坐席，不僅提高了運營效率，還為用戶帶來了更好的通話體驗，用戶滿意度也顯著提升。
作為定位于支撐更多 RTC 業(yè)務(wù)場景的應(yīng)用平臺，我們希望能夠針對 RTC 業(yè)務(wù)領(lǐng)域的特點，提供更多原子能力和場景化解決方案，支撐客戶更加便捷的接入和搭建自己的業(yè)務(wù)，持續(xù)提升業(yè)務(wù)質(zhì)量，降低客戶使用成本。我們會在以下方面做更長期的投入。
本文鏈接：http://m.www897cc.com/showinfo-26-101701-0.html火山引擎 RTC 實時媒體處理平臺的技術(shù)實踐
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Python 十個高階函數(shù)
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號