跨國實時網路排程系統設計
跨國應用場景下網路的複雜性、不穩定和高丟包率對網路的實時性和流暢性提出了更高的挑戰。本文是即構科技技術副總裁冼牛在LiveVideoStackCon 2018大會上的分享，深入探討了實時網路排程系統的部署、架構設計、挑戰和應對策略。由LiveVdeoStack整理而成。
文 / 冼牛
整理 / LiveVideoStack
大家好，我是冼牛，目前在即構科技主要負責實時音視訊引擎的研發，專注於視訊直播、視訊社交和線上教育等領域。本次主要分享即構科技在出海構建全球網路的過程中遇到的問題和解決問題的方法和思路。
分享內容覆蓋四個領域，分別是實時音視訊和跨國應用場景，跨國實時網路的部署，跨國排程系統的架構設計，以及跨國排程系統的挑戰和應對的方法。
1. 實時音視訊和跨國應用場景
圖中所列的幾點摘自《36k研究報告》。網際網路出海大多是因為趨勢，圖中列出了相關的一些背景和理由。人口紅利的消退，技術的溢位，更關鍵的是國內的激烈競爭。而國外部分國家的網際網路技術相對落後四到五年。
視訊直播/視訊社交-網際網路出海應用場景
圖中展示的是視訊直播的其中一個應用場景，出海應用場景包括兩類：一類是視訊直播一類是視訊社交。視訊直播分兩種，基礎的是單向直播，沒有互動，使用者一般從CDN拉流，主播推流到比較好的資源裡去做加速。第二種是連麥直播，連麥直播對技術的要求比較高，上面兩張圖擷取自“花椒直播APP”。
實時音視訊系統架構圖
關於實時音視訊系統架構圖有兩點需要說明。第一點是對於實時傳輸網路，我們要考慮其實時性和成本。綜合考量後，對於實時的低延遲波動，我們會選擇通過比較好的資源來支援實時的互動，使用UDP的私有協議，或者RTMP協議來支援，利用CDN網路進行大規模的分發也是其中比較經濟的。另外一點就是需要支援目前所有主流的終端，但是每個終端的協議，音訊編碼的格式，視訊編碼的格式都不一樣，如果不同的終端要通訊，就要考慮是否需要互相轉碼，如果需要轉碼，就要考慮增加的成本，以及是否會帶來延遲。
跨國線上教育微場景
跨國線上教育中最主要的場景有兩種：一種是1對1的英語學習；另外一種是跨國小班互動教學。由於跨國的教育資源不平衡，在美國、英國有大量英語非常優秀的老師，但缺少教育的市場。而在中國則是有大量的孩子想要學英語，卻沒有足夠優秀的英語老師，將他們連線起來，就需要跨國的實時傳輸網路。
跨國實時傳輸網路的挑戰
想要實現跨國實時網路，我們就需要解決其中所遇到的一系列問題，包括RTP較大，網路不穩定，易掉線，丟包率高等等。此外，小班課存在的問題是：小班課的終端需要供多個學生同時上課。因為人數較多，如果這種互動課我們採取拉多流的方式，網路挑戰非常大。除了前面提到的跨國，跨區域不穩定之外還存在的技術挑戰就是，“就近接入”。就近接入採取的是查IP庫的方式，但IP庫往往是不準確的，特別是在國外。此外，網路故障的情況在中國經常出現，海外發生的頻率更高。然後是容量控制，它指的是每個節點的容量（頻寬資源，計算能力），需要對這些容量進行管理，避免某個節點容量過載。多協議互通，使用者從多個終端連線到雲端，每個終端有著不同的協議，多個協議之前需要互通（需要轉碼），這也意味著會產生大量成本。
跨國實時傳輸網路的策略
同一地區，我們會通過區域化部署的方式解決本地的一些通訊問題。第一公里和最後一公里，我們採用就近接入，負載均衡的傳輸方式。中間的六個部分採取動態路由、動態回源的傳輸方式。我們比較有優勢的傳輸方案是基於UDP的傳輸方案。在理想的網路狀態下（不存在丟包，不存在抖動，頻寬充足），RTMP與UDP的私有協議理論上差別不大；但在弱網情況下，UDP協議會具有更好的抗性。
2. 跨國實時網路的部署
圖中展示的是即構在全球的伺服器節點、CDN節點部署的情況，重點部署地點包括日本、韓國、東南亞、中東、東歐、西歐、美東和美西等，，節點資源相對密集的地方使用者和需求也就相對較多。
跨國網路節點的部署流程
上圖展示的是我們在海外新的區域部署節點時的流程，以及列舉的市場上部分資源供應商。部署新節點的流程是：首先與當地或者國際的雲商溝通，詢問是否有當前節點的資源，如果有就選購這個資源，如果沒有，就選擇通過國際運營商購買資源，在選購資源時我們有一套方法對節點資源進行測試。當選購到比較好的節點資源後，部署時我們的軟體系統是不用改動的，主要是對採購的硬體資源進行優化，然後部署。一般在節點資源到位的情況下，兩天時間就可以完成。部署完成後，會對節點進行長期的優選，好的節點保留，不好的淘汰。經過長期的運營，積累下來的都是比較優質的節點，同時也積累了大量的運營資料，這些運營資料可以支撐我們在選路，動態回源時進行更好的決策。
3．排程系統的架構設計
跨國實時網路的拓撲圖
上圖是跨國實時網路的拓撲圖，其中基本包括了四類實體，一類是使用者終端；第二類是普通的媒體節點；第三類是排程中心；第四類是服務節點。在整體設計邏輯中，我們要遵守的第一個原則是儘量保證每個節點設計簡單，這就可以使得排程策略也相對簡單。遵循簡單的原則，我們把排程中心獨立出來，轉碼服務的節點也獨立出來，每個藍色媒體節點的功能基本上就相當於一個SFU，進行傳求證的功能，不進行復雜的處理。
伺服器節點和排程中心的工作機制
圖中展示的是藍色的伺服器節點和排程中心之間的服務機制。流媒體的服務節點會定期的以秒/毫秒的級別向排程中心上報負載的情況。負載的情況包括負載中進出流的輸入頻寬，以及CPU的負載情況，容量和註冊流的資訊。每個節點將資訊上報給排程中心，排程中心就可以根據這些資訊進行決策，排程。那麼排程中心能夠給流媒體伺服器提供什麼樣的幫助呢？流媒體伺服器可以向它查詢對應回源的策略，另外排程中心還可以幫流媒體節點調整指令，如某個節點過載，或者光纖刮斷了，路線需要重新調整，這個調整路徑的策略決定是由排程中心決定的，它通過調整指令告訴這個節點該如何進行處理。
單點排程模式（成本優先）
這裡簡單介紹一下我們的排程模式，它分為兩種，一種是單點排程模式；一種是多點排程模式。單點，簡單來說就是推流到某個節點，拉流也從那個節點進行。這種模式有兩個好處，第一節省成本；第二傳輸的節點越少，延遲就越少。所以從延時的角度來考慮，一般來說，同一個城市我們會採取單點排程的模式。當然單點排程模式也有其弊病，如中國和美國的使用者通話，如果採取單點排程的模式，而節點設定在中國，讓美國的使用者從中國拉流基本是行不通的。對於這種情況我們有一些後備方案，如果單點拉流體驗不好，達不到要求怎麼辦？如果是因為容量不足，負載能力不夠，我們會在同一個機房利用其它的節點來進行負載。同機房內的節點間，互相拉流是免費，沒有成本的，而且同一個機房的計算資源可以支撐這個負載；如果是因為不同的ISP，網路之間通訊有問題導致體驗不好，可以通過BGP節點作為中轉。BGP結點在不同的運營商網路裡有不同的IP地址，這樣就可以解決跨網通訊的問題。如果還是沒有辦法解決，我們還會有全域性網路節點來保障其可用性。
多點排程模式
多點排程模式其實是為了解決單點排程模式中存在的問題。多點排程模式遵循的哲學是體驗優先，成本其次。上面所展示的針對國內的不需要中轉的場景，簡單來說，比如北京的使用者流推到A節點，會到排程中心註冊說明推流到了A結點，排程中心瞭解掉A節點流的存在。當深圳節點的使用者需要拉流觀看，會就近接入節點C詢問排程中心如何拉取終端1的流，排程中心會指示從節點A拉流，這樣整個排程過程就完成了。這是動態回源的方式。
但是對於兩個節點分別在國內外的情況，由於存在的通訊問題，需要在中間增加一箇中轉節點。通過中轉節點往往會使延遲降低，流暢性提高。
第一公里&最後一公里
第一公里和最後一公里，從排程的角度來說，它們是一樣的。簡單的邏輯就是，當你向排程中心詢問應該從哪推流或者拉流，排程中心就會告訴你答案。在這裡我們遵循兩個原則，第一是就近，另外是要考慮負載均衡。當用戶在推流的時候，會詢問排程中心應該向哪一個節點推流，排程中心會給出多個選擇。這一系列的選擇存在優先順序，首先會考慮到成本，人為的偏好等多種因素。這些選擇主要是通過查IP庫，根據使用者所在地域，運營商進行分配的，可能會存在一些問題，使用者也會通過測速來選擇最優的節點接入。對於負載均衡，我們採取兩個策略，一個是預售票的策略，舉個例子，假設一個節點，如果告訴所有的排程中心這個節點有三百路下行的推流能力，每個排程中心都會將這三百路用完，也就會因為重疊而導致節點擠爆。我們的做法是將三百路分成三份，每個排程中心的手裡只有一百個名額，這樣每個排程中心都不會用超。萬一發生資源分配用超的情況，則會在事後進行重定向，也就是對應的第二種策略。
節點之間傳輸
對於節點之間的傳輸，前面有提到區域性的部署，也就是分散式部署。包括了排程中心要在各個區域有所部署；服務節點負擔轉碼的工作，它也需要在各個區域有所部署。排程中心要做動態的回源和全域性的排程，必須要監控整個網路鏈路的健康性，每個節點的容量。並且必須要遵循最短的原則，原因是其成本最低且對應路距短，延遲也會最低。之後還要考慮質量的評估，也就是指事後評估。在運營一段時間以後，積累了一定量的資料，我們會根據這些資料分析某個時間段推流時節點效果。在動態回源的過程中也會主動的做一些實時的測速，根據測速的結果綜合考慮動態回源的決策。
4. 排程系統的挑戰和應對
就近接入-IP庫問題
關於排程系統挑戰的應對，首先看第一個問題，即IP庫的問題。第一公里或者最後一公里在就近接入的時候，我們採取傳統的方法是查IP庫。但是查IP庫的方式存在一些問題，因為通過查IP庫得到的資訊不是實時的，是查詢時的最終結果，可能已經發生改變。這種情況在國內約有10%概率會發生，而在國外的機率會更高。那麼解決這個問題的方法是，排程中心通過查IP庫得到結果後，同時返回若干個選擇給客戶端。客戶端獲得選擇後會主動測速來驗證排程中心所給的結果。
負載均衡-容量控制的問題
第二個問題是容量控制的問題，前面有提到過一些方法，一個是通過預售票的方式，另外則是重定向的方式。接下來將介紹這兩個方法是如何解決問題的。我們通過多個引數、多個維度來衡量每個節點的容量，測量流的數目就可以反映CPU的運算能力，位元速率用來考量網絡卡的吞吐能力，還有CPU的佔有的百分比，另外一個就是純音訊的場景和語音視訊要分成不同的網路來處理，因為音訊和視訊的位元速率不是一個量級的。
智慧選路-網路故障的問題
在網路故障的情況發生時，我們會進行路線重新排程，如果要能夠實時的重新排程另外一個路線，就必須存在多個備用方案。在接入回源時，為了能夠準備多個接入的選擇，排程系統需要對整個網路有全域性的監控才能夠動態的調整路由。
智慧選路-跨區域不穩定的問題
關於跨區域不穩定的問題，跨區域指的是不同的區域，不同的國家之間是靠進出口光纖通訊的。進出口光纖資源是稀缺的，共享的，並且存在很多不穩定的情況。為了解決這個問題，我們的出海領域的客戶裡大部分還是區域化的業務場景，所以我們在每個區域部署當地的排程中心，轉碼伺服器，多條路線的熱備。
智慧選路-跨區域排程
跨區域排程還存在另外一個問題，用上圖的場景來解釋，當深圳的使用者與紐約的使用者之間通話的時候，這裡是採用了多節點排程的方式。從流程上來說，在紐約的使用者推流出去之前會詢問美東的排程中心應該推流至哪個節點？美東的排程中心會回覆它推流到節點A。當節點A存在流之後，如果有需求，節點A 就可以將流貢獻出去。深圳的使用者要跟紐約的使用者進行通話，在拉流之前會詢問華南的排程中心要從哪個節點進行。由於是區域化部署，所以就存在美東排程中心，華南排程中心，當華南排程中心不知道紐約使用者的流在哪時，它有兩種方法。一種是廣播詢問紐約使用者的流在哪，每個排程中心都會收到這個詢問，當美東排程中心知道後會回覆它使用者流在節點A，這樣深圳的使用者回源到節點A拉流。另外一個方式是紐約的使用者通過房間裡面的信令告訴深圳使用者這個流在節點A，華南的排程中心可以告訴他從美東排程中心查詢，那麼最終深圳的使用者可以通過節點D回源到節點A拉流。
多協議互通-轉碼的問題
這是最後要討論的一個問題，在最開始展示的實時架構圖裡顯示了支撐不同的接入的終端，比如微信小程式、WebRTC瀏覽器，安卓、iOS，甚至有非WebRTC H5頁面的。不同的終端是使用不同的協議進行通訊的，流媒體的封裝格式也不一樣。那麼不同終端之間的通訊就需要轉碼。但是轉碼，包括解碼、重新編碼會增加延遲，消耗資源，增加複雜度。於是我們採取三種應對的方式，第一種是被動轉碼的方式。舉個場景來說，如果有安卓和iOS兩個使用者間通話，兩種終端所用的協議，編解碼格式都是一樣的，那就不需要轉碼。如果這時有第三個人再進這個房間跟這兩個使用者聊天，並且是用網頁版加入進來的。網頁版是通過WebRTC的瀏覽器來支援通話的，網頁版的WebRTC的通訊是RTP和RTCP，音視訊格式為H.264/OPUS，2、微信小程式上支援RTMP標準協議，音視訊格式為H.264/AAC，這裡就需要進行轉碼，只有在有使用者要進來，必要的時候再進行轉碼，這就方式叫做被動轉碼。
轉碼的服務之間要獨立，比如WebRTC的伺服器當作一個子叢集，RTMP的協議包括小程式等都要獨立一個叢集來運營。我們的私有網路也有另外一個大的叢集。我們有兩張大的私有網路，一張是支援RTMP協議的網路，另外一個是基於UDP協議的網路。具有這三張不同的獨立的小叢集就可以提高效率，降低成本。最後展示的是不同終端之間的轉碼關係。
精品文章推薦
技術乾貨：
人物專訪：