游望秋-火山引擎veRTC場景下高可用云邊通信實踐.pdf

《游望秋-火山引擎veRTC場景下高可用云邊通信實踐.pdf》由會員分享，可在線閱讀，更多相關《游望秋-火山引擎veRTC場景下高可用云邊通信實踐.pdf（33頁珍藏版）》請在三個皮匠報告上搜索。

1、引擎veRTC場景下可云邊通信實踐字節跳動/游望秋綱veRTC云邊協同場景 veRTC云邊協同的特點和挑戰 veRTC可云邊通信架構介紹veRTC業務場景直播連視頻會議互動課堂游戲語云游戲物聯veRTCReal Time Communication實時視頻特點全球范圍內的實時視頻互動veRTC全球化架構全球實時視頻云1.邊緣全球下沉，戶就近接2.全球實時流媒體傳輸3.全球實時信令傳輸4.邊緣計算，云邊協同1.戶就近接，進推流4.戶就近接邊緣從云端獲取流信息，進拉流2.業務邏輯邊緣本地處理3.信令數據從邊同步到云端在云端進全球同步5.媒體流傳輸邊緣服務器云端數據中邊緣就近接云端戶就近接SDN絡云

2、端veRTC全球化架構中的云邊協同云邊協同場景 1.房間、戶、流信息的上報和推送2.控制信令傳輸3.媒體節點信息上報4.流媒體絡帶外控制1.戶就近接，進推流4.戶就近接邊緣從云端獲取流信息，進拉流2.業務邏輯邊緣本地處理3.信令數據從邊同步到云端在云端進全球同步5.媒體流傳輸邊緣服務器云端數據中邊緣就近接云端戶就近接SDN絡云端綱veRTC云邊協同場景 veRTC云邊協同的特點和挑戰 veRTC可云邊通信架構介紹veRTC云邊協同的特點-可靠性可靠性要求 信令系統依賴中作為超級腦，邊緣法治 媒體絡依賴云邊通信做帶外控制 下線邊緣會對戶體驗產嚴重影響信息上報信息上報推送推送建通話云邊通信異?？赡?/p>

3、會導致 戶通話法建 邊緣失聯導致戶斷開重連，導致卡頓屏 媒體絡避障異常，導致通話失敗媒體傳輸veRTC云邊協同的特點-實時性信息上報信息上報推送推送建通話實時性要求 各類實時互動的業務場景對控制信令的實時性要求云邊消息延遲上升100ms會導致3s/5s 進房成功率下降3%幀延遲上升600msveRTC云邊協同的特點-成本信息上報信息上報推送推送建通話帶寬消耗 只來傳輸控制信令、不傳輸媒體流 每100w PCU 云邊通信帶寬 2Gbps1.邊緣分布下沉，故障率部分節點法建設專線公的可靠性不2.云機房故障法避免，影響veRTC云邊通信的挑戰-基建邊緣云端中間 鏈路云邊通信 故障 邊緣出故障 DNS

4、故障 云端出故障 4/7層LB故障 地區絡故障 云邊專線故障 動態加速故障當有多個云機房存在，邊緣該如何連接？veRTC云邊通信的挑戰-延遲、容災與容量地區A云端DC1地區B云端DC2地區C云端DC3邊緣1邊緣2邊緣3地區A云端DC1地區B云端DC2地區C云端DC3邊緣1邊緣2邊緣3正常場景邊緣就近接故障場景邊緣分流到其他云端DC80%20%業界常的云邊通信案基于公構建VPN隧道OpenYurt/Raven基于連接KubeEdge業界常的云邊通信案業界案提供了1.基于公構建對業務透明的云邊絡通信能2.持通過QUIC等協議提云邊通道的可靠性3.提供了云原管理能應到veRTC的場景，沒有解決的問題

5、：1.云邊鏈路單，故障時如何容災容錯2.如何盡可能降低云邊通信延遲3.多中架構中邊緣到中的流量調度綱veRTC云邊協同場景 veRTC云邊協同的特點和挑戰 veRTC可云邊通信架構介紹veRTC云邊通道架構演進v1 各服務基于連接實現v2 中化關架構v3 去中化格架構v1 各服務基于連接實現的云邊通道Edge Clusteredge nodeservice Aservice B各個服務通過grpc/ws連接實現云邊雙向通信存在的問題：1.每個服務需要單獨做運維配置2.量冗余開發作3.可能缺，且各個服務不致Cloudservice Aservice Bgrpcwebsocketv2 中化關版本E

6、dge Clusteredge nodeserviceSDKserviceSDKmultiPath Transport邊緣端 邊緣服務集成SDK接云端 中化關服務cloud gateway，于管理連接以及轉發云到邊和邊到云的數據傳輸通道MultiPath Transport：基于邊緣和中?；罱M異構鏈路的連接實現的可通道Cloudserviceserviceservicecloud gatewayMultipath Transport 如何保證可 我們曾經遇到的故障 云端關服務故障 云端LB 硬件故障 云端運營商線路故障 云邊專線故障 域名DNS故障，法解析 域名配置變更時誤配置，導致域名不可

7、區域性絡故障，如新疆/內蒙古區域到北京故障，但是從深圳繞可以連通 邊緣機房出故障，三線機房，單個運營商出故障引多種類型（10+）的異構鏈路各種故障場景下，總能夠保證有鏈路可以連到中EdgeCloudLBLB專線直連（如有）動態加速公域名直連多個供應商動態加速域名區域匯聚點區域匯聚點專線轉發公專線中LB冗余運營商出1LB運營商出2邊緣出異構NAT中直連邊緣Multipath Transport 如何保證可-異構鏈路異構鏈路帶來的優勢 當鏈路故障發時，可以進鏈路切換，及時避障 常發送消息時，可以選擇延遲最低的鏈路進發送，降低延遲 邊緣論是否有專線覆蓋都能充分利鏈路資源EdgeCloudLBLB專線

8、直連（如有）動態加速公域名直連多個供應商動態加速域名區域匯聚點區域匯聚點專線轉發公專線中LB冗余運營商出1LB運營商出2邊緣出異構NAT中直連邊緣問題故障發后進鏈路切換，仍然導致云邊通信短暫受損。中LB、區域匯聚點出現故障時可能會導致短暫的積受損如何將可靠性做到更加極致？Multipath Transport 如何保證可-多徑veRTC 云邊消息的特點主要是控制信令，帶寬消耗，優先級，天然適合多徑冗余發送多徑發送流程 對所有鏈路進探測，選擇最好的兩條鏈路發送消息 中關收到消息后進去重，去重后轉發到下游業務 單鏈路故障業務感知，多鏈路故障秒級恢復Edge區域匯聚點Cloud公直連Multipat

9、h Transport 如何保證可-協議MultiPathTransport 在多個鏈路的冗余發送的基礎上實現了類似TCP的ACK重傳機制。持保序、動重傳MultiPath Transportid=6id=5id=4id=3id=2id=1發送隊列連接池active鏈路1active鏈路2recv ackID=3sendid=1,2,3,3sendid=3ackID=3如何去重？如何效去重異構鏈路的情況下，每個鏈路 LB都有的負載均衡策略，LB可能會將連接路由到不同的中關實例，增加去重難度Cloudcloud gateway pod1LBLBEdgecloud gateway pod2clou

10、d gateway pod3serviceserviceserviceservice如何效去重-v1 基于Redis實現去重問題：1.增加消息處理延遲，降低并發2.引強依賴，降低可靠性cloud gateway pod1cloud gateway pod2servicepodCloudLB鏈路1 消息消息重復丟棄鏈路2 消息不重復消息投遞如何效去重-v2 TLB致性Hash去重LB是否可以直接將消息投遞到同個云端關實例？Yes！通過對于同個邊緣的連接，配置相同的hash策略Cloudcloud gateway pod1LBLBEdge1cloud gateway pod2Cloudcloud

11、gateway pod1LBLBEdgecloud gateway pod2cloud gateway pod3hash_key=edge1hash_key=edge1hash_key=edge1問題：擴容、云關升級場景，hash環會發變化，各個LB實例的感知速度不樣，會出現結果不致，導致消息重復如何效去重-v3 Converge Routing最終案：定制LB關，將連接過程拆分成短鏈和鏈兩步 邊緣啟動時通過短鏈請求中控制分配關實例地址，控制引redis保證致性 邊緣創建連接時帶上中分配的地址，LB根據地址將連接打到指定地址的關實例上 cloud gateway在內存中完成消息去重，最后轉發到

12、下游業務實例Edge區域匯聚點Cloudcloud gateway pod1LB通過短鏈分配關地址LB鏈路1鏈路2鏈路3內部去重創建連接時帶上upstreamservice pod通過redis 保證致性cloud gateway pod2cloud gateway pod3轉發消息到下游業務實例如何降低連接?；畹拈_銷？解決案：短鏈探測，探測通道與消息通道分離 鏈路分級，按需?；?，降低80%的?；铋_銷 活躍鏈路和活躍鏈路實時轉化，保證容災能所有鏈路 數量15activeactivekeepalivestandbystandbystandby 鏈路數量12不?；钸B接standbystandbya

13、ctive+keepalive 鏈路*3 ?；钸B接可于云端push每1000個邊緣節點-750K個?；畹倪B接1000個邊緣*5個邊緣服務*15個鏈路*10個連接轉化中化架構存在的問題Edge Clusteredge nodeserviceSDKedge nodeserviceSDKmultiPath TransportCloudserviceserviceservicecloud gateway1.多個service共cloud gateway集群，資源法隔離2.cloud gateway本身是有狀態服務，實現平滑升級依賴裸機部署，運維復雜度3.cloud gateway 成為業務核鏈路上的強

14、依賴，出問題時影響很能否去掉cloud gateway服務？v3 去中化格架構-控制轉發分離控制 分配服務實例地址 連接信息管理 邊緣流量調度Edge Clusteredge nodeCloudservice podagentservice podagentservice podagentserviceSDKedge nodeserviceSDKcontrol_plane短鏈請求分配業務實例地址同步連接元信息multiPath Transport內部轉發數據鏈路質量探測連接?；钤七厰祿鬏?.業務資源完全隔離2.需單獨考慮關的平滑升級3.去除單點強依賴4.減少關 業務實例的調開銷v3 去中化格

15、架構 云端故障容錯單實例故障 控制：狀態服務，動切換實例 數據 邊緣上報故障到控制，控制重新分配實例，秒級切換 如時間法恢復，動切換到其他互備云上機房 云端機房規模故障 控制下發切流操作，持從多個云端機房下發操作，保證操作定能夠成功 EdgeCloud DC1service pod1service pod2control_planecontrol_planeCloud DC2service pod1control_plane控制實例切換數據實例切換數據云端機房切換控制實例故障數據實例故障控制下發切流指令異地多活場景下的云邊流量調度云端異地多活場景挑戰：云端機房容量不對等，容災時需要綜合考慮延遲+容量，否則云端機房容量被打滿策略：控制感知云端機房容量信息，綜合云邊延遲進流量調度地區A云端DC地區B云端DC地區C云端DC云端多機房 異地多活控制地區A Edge地區C Edge地區B Edge容量信息上報調度策略下發調度策略下發調度策略下發容災切換云邊通道穩定性數據（2023年）避障次數25次 均減少故障時75分鐘年事故數量0次MTTR5s