三體云的前身是一家視頻會議提供商，如今致力于為多領域提供實時音視頻技術整體解決方案，為開發(fā)者提供簡單易用、極度穩(wěn)定、低延時、高保障的直播云服務，這其中的轉變在架構升級、系統(tǒng)調度和質量監(jiān)控三個方面都有不同的體現(xiàn)。本文來自于張光在LiveVideoStackCon2019北京站上的精彩分享。

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

　　眾所周知，云服務廠商與客戶簽訂協(xié)議之時一般都會附帶SLA協(xié)議，而SLA協(xié)議中基本就已經(jīng)定義了廠商給用戶提供的服務需要達到什么樣的等級。SLA協(xié)議中更多提到的是服務在什么時候可以提供給客戶使用，而具體的使用效果并沒有明確說明，因此三體云對自身提出了更高的要求，希望提供的服務能夠在可用的同時帶給用戶更好的使用體驗。

　　三體云的前身是一家視頻會議提供商，整體軟件的架構都是由視頻會議過渡而來，要提供實時音視頻服務并處理海量并發(fā)需求，當務之急是需要對系統(tǒng)架構進行升級，另外，好的調度系統(tǒng)也能使音視頻服務變得更好用。在提供優(yōu)質服務之后，三體云還希望能夠建設一套全面的質量監(jiān)控系統(tǒng)，更好更快的找出系統(tǒng)的不足，不斷地改進以提供更好的服務給客戶。

　　既然三體云之前是視頻會議的系統(tǒng)架構，那么就先從早期架構談起。如圖所示，早期的業(yè)務和媒體節(jié)點都部署在一個地點，如果沒有高并發(fā)、跨地域等的需求情況下，僅僅一個master就能提供服務。隨著用戶有更多分支機構的變更以及更多用戶接入的情況出現(xiàn)，就需要在MASTER節(jié)點上用SLAVE節(jié)點連接做拓展，隨著層級越來越多，延遲也會越來越大，MASTER節(jié)點可能會成為瓶頸。在這種結構下，所有的狀態(tài)都存儲在業(yè)務服務器上，業(yè)務同步會非常復雜，某一節(jié)點宕機之后一般都采取雙機熱備的方式處理。因此三體云在轉型音視頻服務之后需要對舊的系統(tǒng)架構進行全面的升級。

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

　　信令和狀態(tài)維護方面的改變與之前媒體部分的改變比較類似，loadbalance節(jié)點同樣做接入和分發(fā)的工作，而業(yè)務之間也不存在層級關系，都會向loadbalance上報自己的狀態(tài)，同時所有跟業(yè)務相關的房間、用戶的狀態(tài)信息等都會寫入redis，業(yè)務之間的數(shù)據(jù)同步就會變得更簡單。

　　上圖表示的是一個客戶端想要接入系統(tǒng)首先需要連接loadbalance，當前更多采用域名的方式來連接，接入之后調度到指定的業(yè)務服務器上，所有的業(yè)務都需要把狀態(tài)寫到redis，業(yè)務服務器分發(fā)之后首先會有校驗和創(chuàng)建狀態(tài)的環(huán)節(jié)，完成之后就會給他分配媒體服務器。改變之后的業(yè)務和媒體的拓展比之前的樹狀結構要簡單許多，不需要把新加的媒體或業(yè)務掛在某一個MASTER或SLAVE節(jié)點下，只需要部署在平臺上并注冊在loadbalance上就可以，業(yè)務和媒體的個數(shù)不用一一綁定，拓展要相對靈活一些。盡管三體云做到了這些架構升級，但在現(xiàn)實中仍然出現(xiàn)Loadbalance和redis集群癱瘓所引發(fā)的問題，因此需要進一步改進框架，優(yōu)化產(chǎn)品服務。

　　通過對系統(tǒng)架構的升級優(yōu)化，客戶端在接入時，會有如圖兩套loadbalance連接，而且redis分開寫入，兩個loadbalance之間保持高速同步，這樣可以做到兩個人通過不同的loadbalance進行連麥操作。但這樣做還是會出現(xiàn)部分用戶連接不到服務器的問題，經(jīng)過排查發(fā)現(xiàn)原因是這部分用戶的域名被劫持，因此三體云又多建了一套固定IP，與前兩個loadbalance一起寫入SDK，用戶使用服務進行連通時如果訪問不到域名就會嘗試連接靜態(tài)IP來訪問，更進一步保證了服務的連通性。

　　系統(tǒng)架構的升級在一定程度上提高了三體云服務的用戶體驗，但僅僅靠架構優(yōu)化遠遠達不到我們的預期，還需要智能調度來進一步提升產(chǎn)品質量。中國幅員遼闊，大的國土面積帶來的問題是會出現(xiàn)各種各樣的網(wǎng)絡問題，如果要為不同地方的用戶提供服務就需要部署更多的服務器，目前在國內就已經(jīng)有兩百多個數(shù)據(jù)節(jié)點，而對于不同位置需要對節(jié)點部署進行選擇。首先需要找到一些能夠部署服務器的機房，找到節(jié)點之后進行撥測，保證服務器真實可用且滿足基本條件就可以部署服務，部署成功再經(jīng)過內部測試才可以上線，而上線之后才是對于節(jié)點的真正考驗。節(jié)點上線之后我們會對其進行數(shù)據(jù)監(jiān)控，以觀測該節(jié)點是否符合服務標準，最終會對不符合條件的節(jié)點進行淘汰，并重新在該區(qū)域選擇節(jié)點部署。這樣對于節(jié)點的選擇流程會使三體云部署的全部節(jié)點都是符合服務標準的選擇。

　　想要做到智能調度的第一點是要讓節(jié)點部署離用戶更近，最初三體云是通過IP庫返回所在地域以及運營商進行選擇，但實際上國內的網(wǎng)絡環(huán)境非常復雜，IP庫也存在一定的準確性問題，甚至服務器獲取的IP與媒體服務器獲取到的IP可能不一致，這些問題都急需解決。

　　通過IP庫返回所在地域以及運營商這件事本身并沒有錯，問題出在運營商并沒有將這件事解決徹底，因此在進行用戶調度時需要更嚴格要求就近原則、運營商匹配度以及負載均衡，除此之外還需要做一些兜底保障和數(shù)據(jù)統(tǒng)計的工作來完善調用規(guī)則。

　　互聯(lián)網(wǎng)做實時音視頻交互大部分都是跨區(qū)域連通，而三體云在解決這部分問題時也遵循著四個原則，首先通過探測機制探測各節(jié)點間的網(wǎng)絡狀況（分區(qū)域），畢竟在國內目前就存在兩百多個服務器節(jié)點，對這些節(jié)點進行探測是基本不可能的，因此是按區(qū)域劃分進行探測，各區(qū)域會把自己的探測結果上報到?jīng)Q策中心去做統(tǒng)一的調度。第二點是關于實時負載狀況的統(tǒng)計，國內兩百多個服務器節(jié)點的配置是不一樣的，所以必須把實時運行的狀態(tài)上報到?jīng)Q策中心，方便做后續(xù)分配。最后在路徑選擇方面還需要基于成本考量，并且遵循最短路徑原則。

　　路徑選擇完成之后在真實網(wǎng)絡環(huán)境下還會出現(xiàn)，國內的網(wǎng)絡包括主干網(wǎng)和單線機房都會隨時發(fā)生抖動，或者發(fā)生機房宕機等情況，為了盡量避免這些特殊情況對用戶體驗的影響，還需要在智能調度中加入路徑切換，能夠在使用過程中對路徑做實時選擇。

　　服務器部署之后并不是一成不變的，算法的改進和服務節(jié)點的替換都是服務下線和升級的過程，而在這個過程中我們也希望能有更好的用戶體驗。假如A服務需要下線、升級，之前的做法是直接殺死A服務，依賴client的斷線重連使服務維持下去，但這期間會發(fā)生黑屏、卡頓等非常影響用戶體驗的狀況發(fā)生。而后的改進措施是先從loadbalance上注銷A服務，保證調度時不再有新的用戶訪問A服務，等待A服務用戶逐漸歸零之后再升級服務，但現(xiàn)實情況下根本沒辦法等到所有用戶都從A服務上下線，所以最終三體云的改進方法是主動發(fā)送信令通知用戶從A服務遷移到B服務，在此期間做到用戶對于服務下線、升級完全無感知，體驗不到中間有任何的斷開。

　　在做完服務器部署以及智能調度之后，已經(jīng)可以保證用戶能夠無時無刻的訪問三體云的業(yè)務，但最終的使用效果如果沒有質量監(jiān)控是沒辦法觀測到的，并且需要做到先于用戶發(fā)現(xiàn)問題，或者幫助客戶一起來改進服務質量。以下是三體云質量監(jiān)控系統(tǒng)對某客戶使用效果的一些指標統(tǒng)計數(shù)據(jù)。

 

 

 

 

 

　　來源：LiveVideoStack