三體雲–高可用實時音視頻服務演進之路

 

三體雲的前身是一家視頻會議提供商，現在致力於爲多領域提供實時音視頻技術總體解決方案,爲開發者提供簡單易用、極度穩定、低延時、高保障的直播雲服務，這其中的轉變在架構升級、系統調度和質量監控三個方面都有不一樣的體現。本文來自於張光在LiveVideoStackCon2019北京站上的精彩分享。

文/ 張光

整理 / LiveVideoStack

你們好，我是三體雲CTO張光，今天我演講的主題是三體雲如何提供高可用的實時音視頻服務。我從2005年開始從事音視頻技術研究，有十年的移動端音視頻研發經驗，曾任著名視頻會議廠商研發經理,負責過多行業100+音視頻項目，2008奧運會有幸擔任TD3G供應商項目主要負責人，目前更加關注與實時音視頻技術的發展。

1. 高可用

1.1 高可用的定義

 

衆所周知，雲服務廠商與客戶簽定協議之時通常都會附帶SLA協議，而SLA協議中基本就已經定義了廠商給用戶提供的服務須要達到什麼樣的等級。SLA協議中更多提到的是服務在何時能夠提供給客戶使用，而具體的使用效果並無明確說明，所以三體雲對自身提出了更高的要求，但願提供的服務可以在可用的同時帶給用戶更好的使用體驗。

1.2 如何作到高可用

 

三體雲的前身是一家視頻會議提供商，總體軟件的架構都是由視頻會議過渡而來，要提供實時音視頻服務並處理海量併發需求，當務之急是須要對系統架構進行升級，另外，好的調度系統也能使音視頻服務變得更好用。在提供優質服務以後，三體雲還但願可以建設一套全面的質量監控系統，更好更快的找出系統的不足，不斷地改進以提供更好的服務給客戶。

2. 系統架構升級

2.1 早期適用於視頻會議的系統架構

 

既然三體雲以前是視頻會議的系統架構，那麼就先從早期架構談起。如圖所示，早期的業務和媒體節點都部署在一個地點，若是沒有高併發、跨地域等的需求狀況下，僅僅一個master就能提供服務。隨着用戶有更多分支機構的變動以及更多用戶接入的狀況出現，就須要在MASTER節點上用SLAVE節點鏈接作拓展，隨着層級愈來愈多，延遲也會愈來愈大，MASTER節點可能會成爲瓶頸。在這種結構下，全部的狀態都存儲在業務服務器上，業務同步會很是複雜，某一節點宕機以後通常都採起雙機熱備的方式處理。所以三體雲在轉型音視頻服務以後須要對舊的系統架構進行全面的升級。

2.2 更適合公有網絡部署的方案

2.2.1 媒體接入及轉發

 

系統架構升級的第一步是對媒體接入及轉發作一些改變，在媒體接入部分，三體雲將全國各地的每臺服務器作平級化處理，相互之間沒有分層，全部的媒體服務器都會向loadbalance節點上報狀態，幫助其作一些調度方面的決策。而在媒體之間轉發部分，在視頻會議架構中節點轉發須要上報根節點以後才能下發到相應節點，而改變也如圖中所示，例如北京移動轉發到廣東電信須要通過BGP中心節點來幫助作路由轉發，廣東到上海也會有一個三線IDC來幫助其轉發。

2.2.2 信令及狀態維護

 

信令和狀態維護方面的改變與以前媒體部分的改變比較相似，loadbalance節點一樣作接入和分發的工做，而業務之間也不存在層級關係，都會向loadbalance上報本身的狀態，同時全部跟業務相關的房間、用戶的狀態信息等都會寫入redis，業務之間的數據同步就會變得更簡單。

2.2.3 結合

 

上圖表示的是一個客戶端想要接入系統首先須要鏈接loadbalance，當前更多采用域名的方式來鏈接，接入以後調度到指定的業務服務器上，全部的業務都須要把狀態寫到redis，業務服務器分發以後首先會有校驗和建立狀態的環節，完成以後就會給他分配媒體服務器。改變以後的業務和媒體的拓展比以前的樹狀結構要簡單許多，不須要把新加的媒體或業務掛在某一個MASTER或SLAVE節點下，只須要部署在平臺上並註冊在loadbalance上就能夠，業務和媒體的個數不用一一綁定，拓展要相對靈活一些。儘管三體雲作到了這些架構升級，但在現實中仍然出現Loadbalance和redis集羣癱瘓所引起的問題，所以須要進一步改進框架，優化產品服務。

2.2.4 優化

 

經過對系統架構的升級優化，客戶端在接入時，會有如圖兩套loadbalance鏈接，並且redis分開寫入，兩個loadbalance之間保持高速同步，這樣能夠作到兩我的經過不一樣的loadbalance進行連麥操做。但這樣作仍是會出現部分用戶鏈接不到服務器的問題，通過排查發現緣由是這部分用戶的域名被劫持，所以三體雲又多建了一套固定IP，與前兩個loadbalance一塊兒寫入SDK，用戶使用服務進行連通時若是訪問不到域名就會嘗試鏈接靜態IP來訪問，更進一步保證了服務的連通性。

3. 智能調度

3.1 節點的選擇

 

系統架構的升級在必定程度上提升了三體雲服務的用戶體驗，但僅僅靠架構優化遠遠達不到咱們的預期，還須要智能調度來進一步提高產品質量。中國幅員遼闊，大的國土面積帶來的問題是會出現各類各樣的網絡問題，若是要爲不一樣地方的用戶提供服務就須要部署更多的服務器，目前在國內就已經有兩百多個數據節點，而對於不一樣位置須要對節點部署進行選擇。首先須要找到一些可以部署服務器的機房，找到節點以後進行撥測，保證服務器真實可用且知足基本條件就能夠部署服務，部署成功再通過內部測試才能夠上線，而上線以後纔是對於節點的真正考驗。節點上線以後咱們會對其進行數據監控，以觀測該節點是否符合服務標準，最終會對不符合條件的節點進行淘汰，並從新在該區域選擇節點部署。這樣對於節點的選擇流程會使三體雲部署的所有節點都是符合服務標準的選擇。

3.2 第一千米&最後一千米

 

想要作到智能調度的第一點是要讓節點部署離用戶更近，最初三體雲是經過IP庫返回所在地域以及運營商進行選擇，但實際上國內的網絡環境很是複雜，IP庫也存在必定的準確性問題，甚至服務器獲取的IP與媒體服務器獲取到的IP可能不一致，這些問題都急需解決。

 

經過IP庫返回所在地域以及運營商這件事自己並無錯，問題出在運營商並無將這件事解決完全，所以在進行用戶調度時須要更嚴格要求就近原則、運營商匹配度以及負載均衡，除此以外還須要作一些兜底保障和數據統計的工做來完善調用規則。

3.3 路徑選擇

 

互聯網作實時音視頻交互大部分都是跨區域連通，而三體雲在解決這部分問題時也遵循着四個原則，首先經過探測機制探測各節點間的網絡情況（分區域），畢竟在國內目前就存在兩百多個服務器節點，對這些節點進行探測是基本不可能的，所以是按區域劃分進行探測，各區域會把本身的探測結果上報到決策中心去作統一的調度。第二點是關於實時負載情況的統計，國內兩百多個服務器節點的配置是不同的，因此必須把實時運行的狀態上報到決策中心，方便作後續分配。最後在路徑選擇方面還須要基於成本考量，而且遵循最短路徑原則。

3.4 路徑切換

 

路徑選擇完成以後在真實網絡環境下還會出現，國內的網絡包括主幹網和單線機房都會隨時發生抖動，或者發生機房宕機等狀況，爲了儘可能避免這些特殊狀況對用戶體驗的影響，還須要在智能調度中加入路徑切換，可以在使用過程當中對路徑作實時選擇。

3.5 服務下線、升級

 

服務器部署以後並非一成不變的，算法的改進和服務節點的替換都是服務下線和升級的過程，而在這個過程當中咱們也但願能有更好的用戶體驗。假如A服務須要下線、升級，以前的作法是直接殺死A服務，依賴client的斷線重連使服務維持下去，但這期間會發生黑屏、卡頓等很是影響用戶體驗的情況發生。然後的改進措施是先從loadbalance上註銷A服務，保證調度時再也不有新的用戶訪問A服務，等待A服務用戶逐漸歸零以後再升級服務，但現實狀況下根本沒辦法等到全部用戶都從A服務上下線，因此最終三體雲的改進方法是主動發送信令通知用戶從A服務遷移到B服務，在此期間作到用戶對於服務下線、升級徹底無感知，體驗不到中間有任何的斷開。

4. 質量監控

 

在作完服務器部署以及智能調度以後，已經能夠保證用戶可以無時無刻的訪問三體雲的業務，但最終的使用效果若是沒有質量監控是沒辦法觀測到的，而且須要作到先於用戶發現問題，或者幫助客戶一塊兒來改進服務質量。如下是三體雲質量監控系統對某客戶使用效果的一些指標統計數據

4.1 質量監控示例