作者：即構科技

由 51 CTO 主辦的“WOT 全球技術創(chuàng)新大會 2023·深圳站”于 11 月 24 日 - 25 日召開，即構科技后臺技術總監(jiān)肖瀟以“邊緣容器在全球音視頻場景的探索與實踐”為主題進行分享。 邊緣計算作為中心云計算的補充，通過邊緣容器架構和云邊協同，為音視頻、云游戲、元宇宙等場景帶來了更好的用戶體驗和業(yè)務價值。

講師現場風采

肖瀟提到，即構這種實時互動的業(yè)務場景，天然就是邊緣計算很契合的方式，原因就是邊緣計算在降低時延、成本優(yōu)化、提升并發(fā)、降低故障影響等方面有十分明顯的優(yōu)勢。即構科技基于在實時互動領域的多年技術積累與實踐，落地了云邊協同的全球音視頻云架構：多云基礎設施、邊緣容器、全球多中心、MSDN （Massive Serial Data Network）海量有序數據網絡全球傳輸網絡。這也幫助即構建立了 “生于云、長于云”的云原生音視頻云服務，提升實時音視頻云服務質量和運維效率，通過多云 serverless 做好容災， 并進一步優(yōu)化成本。

下面是肖瀟在現場演講的內容回顧：

邊緣計算遇到的問題及落地挑戰(zhàn)

即構使用邊緣計算多年，在最開始我們的主要策略是租賃全球各種大規(guī)模的虛擬機和物理機。不同業(yè)務、不同的客戶集群各自獨占邊緣算力，進行自己系統(tǒng)內部的資源冗余，導致邊緣整體的利用率不高，成本壓力大。其次，面向邊緣沒有統(tǒng)一的運維體系，各業(yè)務建設自己的業(yè)務支持系統(tǒng)，容量管理、擴縮容不統(tǒng)一效率比較低下。另外，中心部署的服務已經全面云原生化，運維團隊在管理中心和邊緣的服務需要在兩種思維方式以及在兩套運維設施中切換，這很割裂，期待有一些新的變化。

我們希望云原生的邊緣容器能帶來三方面的變化：

• 通過底層計算資源復用最大化的利用算力和帶寬實現成本的極致優(yōu)化；
• 通過云原生的彈性伸縮、多容器管理、版本更新機制大幅提升運維效率和可靠性；
• 通過邊緣容器的落地，構建一個統(tǒng)一的云邊一體化的云原生基礎設施。

然而，企業(yè)在落地邊緣容器時會面臨諸多挑戰(zhàn)，首先，業(yè)界沒有統(tǒng)一的邊緣容器標準，從產品維度，他們都擁有相同的產品關鍵字：云邊協同、邊緣自治、單元化部署。我們預研梳理落地邊緣容器的一些挑戰(zhàn)，例如，音視頻業(yè)務是強有狀態(tài)服務，如何云原生化？不同服務規(guī)格差異較大，如何調度？音視頻服務經常是兩個進程協同完成工作，如何做到 pod 多進程完全獨立的灰度發(fā)布？云邊網絡中斷業(yè)務如何處理？云邊通信的流量成本能否降到很低？如何提升運維效率等等挑戰(zhàn)。

實時互動業(yè)務的落地實踐

帶著這些挑戰(zhàn)進行思考，即構基于在實時互動領域的多年技術積累與實踐，落地了云邊協同的全球音視頻云架構：多云基礎設施、邊緣容器、全球多中心、MSDN 全球傳輸網絡。即構沒有做成完全分布式去中心化的架構，是因為我們的業(yè)務是全球實時互動場景，500+ 機房之間 full mesh 進行同步效率太低，有中心的參與能大幅提升信息同步效率。

云邊協同的全球音視頻云架構

1、音視頻服務云原生化

音視頻服務是強有狀態(tài)業(yè)務

音視頻服務有點類似游戲服務器，有玩家在玩游戲，不能輕易更新和縮容。音視頻服務器除了有海量的用戶接入，還有服務器之間的級聯。服務器級聯形成了一個流的分發(fā)網絡，服務器節(jié)點的變化會導致分發(fā)網絡的重建。雖然會通過 SDK 重試等策略降低這個網絡重建的成本和對用戶體驗的影響，但是還是希望發(fā)布、擴縮容這些運維操作能盡量降低對音視頻業(yè)務的影響。

具體來看，希望做到 IP 端口固定的無損直連；鏡像更新，pod 不重建，降低 pod 重建重新調度耗時對業(yè)務影響；希望容器更新過程中，鏡像拉取耗時是極短的，來降低推拉流的中斷。有狀態(tài)業(yè)務的擴容需要有多種業(yè)務指標來觸發(fā)，縮容需要很精確的控制。一個 pod 內有兩個容器，引擎容器和配套業(yè)務處理容器，希望這兩個容器能夠做到各自獨立發(fā)布。有一些定向運維操作的需求。

主機網絡減少網絡損耗

我們選擇主機網絡模式來減少網絡損耗，這樣的好處是不需要經過容器額外的網絡虛擬化層，但是也帶來了端口沖突的問題。我們新建了一個 Daemonset，端口管理的服務，在節(jié)點上 pod 啟動的時候負責進行端口的分配。

工作負載的選擇、更新策略

前面我們提到 K8s 自帶的 workload 不滿足音視頻業(yè)務的生命周期管理，在這里我們選擇了 openKruise 的 cloneset 作為我們的工作負載，關注它主要是看中它如下幾塊的能力：原地升級、指定 pod 縮容、sidecarset 實現 sidecar 容器部署的能力、鏡像預熱的能力。

如上圖所示，音視頻引擎作為主容器、配套業(yè)務處理容器作為 sidecar 容器 ，sidecar 容器通過 webhook 注入到 pod 中，通過 cloneset 和 sidecarset 兩種資源實現兩個容器的獨立灰度發(fā)布。社區(qū)的版本 sidecarset 并不支持 env from metadata 的原地升級，我們完善了這個能力，后續(xù)也會提 PR 貢獻給到社區(qū)。基于 cloneset 和 sidecarset，我們能進行下圖所示的基于 partition 的百分比多階段灰度發(fā)布。

原地升級不能解決所有的更新問題

我們知道原地升級的觸發(fā)條件主要是 spec container 的鏡像變化以及 env from metadata 中 label 和注解的變化，但是 cloneset yaml 的其他字段需要修改的時候我們怎么能做到避免 pod 的重建從而使對業(yè)務的影響接近于零呢，即還能保持 IP 端口的穩(wěn)定？對這種情況我們實現了一個 clonesetmigration 的 operator 來協調這個過程。

鏡像預熱

我們在方案選型的時候對比分析了鏡像預熱和邊緣 P2P 鏡像分發(fā)這兩種方式。對比的過程中我們發(fā)現 dragonfly 這種 P2P 鏡像分發(fā)對于邊緣場景運維還是偏復雜，因為它要求一個 P2P 網絡中服務網絡必須是互通的，那對于較大的邊緣機房 P2P 網絡是內網能有很好的效果，但對于多個較小的邊緣機房又需要分區(qū)域組成一個外網的 P2P 網絡，但是音視頻又是高帶寬的服務，為了不影響業(yè)務在節(jié)點和任務的維度都會要求有限速，明顯的限速又影響到 P2P 鏡像的拉取效果。于是回到了我們的核心訴求，原地升級時鏡像拉取的耗時足夠低，那 OpenKruise 每一階段灰度發(fā)布時 node 的提前鏡像預熱+鏡像倉庫多地域部署已經能滿足我們的訴求。

音視頻場景下的彈性伸縮

音視頻場景下彈性伸縮我們區(qū)別于社區(qū)的 HPA 方案，我們做的是帶音視頻業(yè)務狀態(tài)的伸縮方案，擴容會多維度指標綜合評估，從帶寬、PPS、推拉流數、CPU、內存等多指標進行計算，縮容有點特殊，在有用戶在推拉流的時候不能直接進行縮容操作，需要做業(yè)務的無損清理，不然容易帶來用戶的黑屏、卡頓。如果我們設計了 pod 業(yè)務狀態(tài)的狀態(tài)機，有初始化、已分配、墓碑態(tài)和等待被刪除幾種狀態(tài)。其中墓碑態(tài)是關鍵的狀態(tài)，進入這個狀態(tài)會從業(yè)務層面不進行新請求和流量被調度進來等待流量的自然消亡，以及超時后的接近無損的驅趕和清理，當然如果墓碑態(tài)的過程中流量上漲會將業(yè)務狀態(tài)回退到已分配狀態(tài)繼續(xù)服務業(yè)務。

2、質量和運維效率提升

在邊緣容器的質量和運維效率提升方面，即構在成立之初就自研了“海量有序數據網絡 MSDN”，實時探測網絡質量，可以實現全球范圍內優(yōu)質的智能調度及路由，鏈路故障秒級恢復，大幅降低云邊斷網概率，提升數據傳輸速度及可靠性。即構還基于機器學習算法預測邊緣機房未來利用率，生成擴容、縮容資源 node 數，然后基于這個推薦數據自動進行邊緣節(jié)點購買/納管、cordon/drain/節(jié)點退訂，實現邊緣資源池的智能化推薦、擴縮。此外，即構通過全球邊緣容器控制面的多集群管理，實現全球資源統(tǒng)一管理。

肖瀟還提到，關于云邊協同的另一種有趣的方式——多云 Serverless 容災。

當邊緣容器控制面所在的中心 region 故障的時候，因為邊緣自治的原因，邊緣容器依舊可以正常運轉，但是會影響到服務的擴容能力和容量水位。這個時候我們的一種容災方式是通過在多云商不同中心機房的 serverless 集群的擴容進行這部分彈性容量的補齊。其次，用中心機房 Serverless 承載邊緣資源池的突發(fā)溢出流量也非常有價值。這種溢出往往是臨時性的突然打高，通過邊緣帶寬承載日常流量加 Serverless 流量計費承載突發(fā)流量，可以實現網絡成本的最優(yōu)組合。這里也充分用到了中心機房 Serverless 極致的彈性能力。

3、成本優(yōu)化

邊緣資源的最大化共享。使用邊緣容器的邊緣資源池能夠做到不同的業(yè)務集群或業(yè)務角色能共享相同的資源池，通過整個資源池的資源冗余來避免在業(yè)務集群和服務維度各自的資源冗余。其次我們有全局多級資源池調度，上一級滿了會溢出到下一級，實現在資源池全局資源的復用，和任意區(qū)域 N-2 機房資源的冗余。

資源調度策略?；趯崟r音視頻場景思考，我們把默認的 Spread 調度策略改成 Binpack 調度策略，它會優(yōu)先將 pod 調度到資源消耗較多的節(jié)點，多個 pod 會優(yōu)先使用同一節(jié)點來提高整個資源的利用率，相較于虛擬機和物理機時代工作負載提升了一倍。

關于成本，即構關注如何大幅降低云邊通信的流量的成本。以 OpenYurt 為例，首先要盡量減少 Service 和 EndpointSlice 的使用；第二，kubelet、daemonset list-watch 資源要 label 篩選本節(jié)點的數據，減少關注度；第三，以 Openyurt 為例，通過 Pool-Coordinator 和 Yurthub 的協同，實現單一節(jié)點池內云邊只有一份 pool scope data 數據通信，當然 pool-coordinator 機制帶來的好處，能區(qū)分出云邊斷網和節(jié)點宕機。

未來展望

未來即構會從三方面入手，一是探索更適合業(yè)務的調度算法， 對計算密集型的業(yè)務開放 CPU 拓撲感知調度的能力、提供 GPU 調度從而實現更全的業(yè)務覆蓋；其次，通過更多工具鏈系統(tǒng)的建設和更多的能力抽象，進一步降低業(yè)務接入邊緣容器的成本， 實現分鐘級的部署；第三，把更多的能力在邊緣側進行提供。

即構將會繼續(xù)推動邊緣容器在全球音視頻場景的進一步探索和應用！文章來源地址http://www.zghlxwxcb.cn/news/detail-812324.html

到了這里，關于云邊協同的 RTC 如何助力即構全球實時互動業(yè)務實踐的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！