跨國應用場景下網絡的復雜性、不穩定和高丟包率對網絡的實時性和流暢性提出了更高的挑戰。本文是即構科技技術副總裁冼牛在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協議的網絡。具有這三張不同的獨立的小集群就可以提高效率，降低成本。最后展示的是不同終端之間的轉碼關系。

精品文章推薦

技術干貨：

• Pixel 3的超分辨變焦技術

• 熊貓TV直播H5播放器架構探索

• BBR如何讓Spotify流媒體更流暢？

• 騰訊視頻全網清晰度提升攻堅戰

• 英特爾QSV技術在FFmpeg中的實現與使用

• AV1：下一代視頻標準—約束定向增強濾波器

人物專訪：

• 一切從用戶的需求與體驗出發

• 雷輝：讓視頻會議conferencing like TV

• Zoe Liu：被Chrome Media團隊的專注精神感染

總結

以上是生活随笔為你收集整理的跨国实时网络调度系统设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。