跨國應用場景下網(wǎng)絡的復雜性、不穩(wěn)定和高丟包率對網(wǎng)絡的實時性和流暢性提出了更高的挑戰(zhàn)。本文是即構科技技術副總裁冼牛在LiveVideoStackCon 2018大會上的分享，深入探討了實時網(wǎng)絡調(diào)度系統(tǒng)的部署、架構設計、挑戰(zhàn)和應對策略。由LiveVdeoStack整理而成。

文 / 冼牛

整理 / LiveVideoStack

大家好，我是冼牛，目前在即構科技主要負責實時音視頻引擎的研發(fā)，專注于視頻直播、視頻社交和在線教育等領域。本次主要分享即構科技在出海構建全球網(wǎng)絡的過程中遇到的問題和解決問題的方法和思路。

分享內(nèi)容覆蓋四個領域，分別是實時音視頻和跨國應用場景，跨國實時網(wǎng)絡的部署，跨國調(diào)度系統(tǒng)的架構設計，以及跨國調(diào)度系統(tǒng)的挑戰(zhàn)和應對的方法。

1.?實時音視頻和跨國應用場景

圖中所列的幾點摘自《36k研究報告》。互聯(lián)網(wǎng)出海大多是因為趨勢，圖中列出了相關的一些背景和理由。人口紅利的消退，技術的溢出，更關鍵的是國內(nèi)的激烈競爭。而國外部分國家的互聯(lián)網(wǎng)技術相對落后四到五年。

視頻直播/視頻社交-互聯(lián)網(wǎng)出海應用場景

圖中展示的是視頻直播的其中一個應用場景，出海應用場景包括兩類：一類是視頻直播一類是視頻社交。視頻直播分兩種，基礎的是單向直播，沒有互動，用戶一般從CDN拉流，主播推流到比較好的資源里去做加速。第二種是連麥直播，連麥直播對技術的要求比較高，上面兩張圖截取自“花椒直播APP”。

實時音視頻系統(tǒng)架構圖

關于實時音視頻系統(tǒng)架構圖有兩點需要說明。第一點是對于實時傳輸網(wǎng)絡，我們要考慮其實時性和成本。綜合考量后，對于實時的低延遲波動，我們會選擇通過比較好的資源來支持實時的互動，使用UDP的私有協(xié)議，或者RTMP協(xié)議來支持，利用CDN網(wǎng)絡進行大規(guī)模的分發(fā)也是其中比較經(jīng)濟的。另外一點就是需要支持目前所有主流的終端，但是每個終端的協(xié)議，音頻編碼的格式，視頻編碼的格式都不一樣，如果不同的終端要通信，就要考慮是否需要互相轉(zhuǎn)碼，如果需要轉(zhuǎn)碼，就要考慮增加的成本，以及是否會帶來延遲。

跨國在線教育微場景

跨國在線教育中最主要的場景有兩種：一種是1對1的英語學習；另外一種是跨國小班互動教學。由于跨國的教育資源不平衡，在美國、英國有大量英語非常優(yōu)秀的老師，但缺少教育的市場。而在中國則是有大量的孩子想要學英語，卻沒有足夠優(yōu)秀的英語老師，將他們連接起來，就需要跨國的實時傳輸網(wǎng)絡。

跨國實時傳輸網(wǎng)絡的挑戰(zhàn)

想要實現(xiàn)跨國實時網(wǎng)絡，我們就需要解決其中所遇到的一系列問題，包括RTP較大，網(wǎng)絡不穩(wěn)定，易掉線，丟包率高等等。此外，小班課存在的問題是：小班課的終端需要供多個學生同時上課。因為人數(shù)較多，如果這種互動課我們采取拉多流的方式，網(wǎng)絡挑戰(zhàn)非常大。除了前面提到的跨國，跨區(qū)域不穩(wěn)定之外還存在的技術挑戰(zhàn)就是，“就近接入”。就近接入采取的是查IP庫的方式，但IP庫往往是不準確的，特別是在國外。此外，網(wǎng)絡故障的情況在中國經(jīng)常出現(xiàn)，海外發(fā)生的頻率更高。然后是容量控制，它指的是每個節(jié)點的容量（帶寬資源，計算能力），需要對這些容量進行管理，避免某個節(jié)點容量過載。多協(xié)議互通，用戶從多個終端連接到云端，每個終端有著不同的協(xié)議，多個協(xié)議之前需要互通（需要轉(zhuǎn)碼），這也意味著會產(chǎn)生大量成本。

跨國實時傳輸網(wǎng)絡的策略

同一地區(qū)，我們會通過區(qū)域化部署的方式解決本地的一些通信問題。第一公里和最后一公里，我們采用就近接入，負載均衡的傳輸方式。中間的六個部分采取動態(tài)路由、動態(tài)回源的傳輸方式。我們比較有優(yōu)勢的傳輸方案是基于UDP的傳輸方案。在理想的網(wǎng)絡狀態(tài)下（不存在丟包，不存在抖動，帶寬充足），RTMP與UDP的私有協(xié)議理論上差別不大；但在弱網(wǎng)情況下，UDP協(xié)議會具有更好的抗性。

2. 跨國實時網(wǎng)絡的部署

圖中展示的是即構在全球的服務器節(jié)點、CDN節(jié)點部署的情況，重點部署地點包括日本、韓國、東南亞、中東、東歐、西歐、美東和美西等，，節(jié)點資源相對密集的地方用戶和需求也就相對較多。

跨國網(wǎng)絡節(jié)點的部署流程

上圖展示的是我們在海外新的區(qū)域部署節(jié)點時的流程，以及列舉的市場上部分資源供應商。部署新節(jié)點的流程是：首先與當?shù)鼗蛘邍H的云商溝通，詢問是否有當前節(jié)點的資源，如果有就選購這個資源，如果沒有，就選擇通過國際運營商購買資源，在選購資源時我們有一套方法對節(jié)點資源進行測試。當選購到比較好的節(jié)點資源后，部署時我們的軟件系統(tǒng)是不用改動的，主要是對采購的硬件資源進行優(yōu)化，然后部署。一般在節(jié)點資源到位的情況下，兩天時間就可以完成。部署完成后，會對節(jié)點進行長期的優(yōu)選，好的節(jié)點保留，不好的淘汰。經(jīng)過長期的運營，積累下來的都是比較優(yōu)質(zhì)的節(jié)點，同時也積累了大量的運營數(shù)據(jù)，這些運營數(shù)據(jù)可以支撐我們在選路，動態(tài)回源時進行更好的決策。

3．調(diào)度系統(tǒng)的架構設計

?跨國實時網(wǎng)絡的拓撲圖

上圖是跨國實時網(wǎng)絡的拓撲圖，其中基本包括了四類實體，一類是用戶終端；第二類是普通的媒體節(jié)點；第三類是調(diào)度中心；第四類是服務節(jié)點。在整體設計邏輯中，我們要遵守的第一個原則是盡量保證每個節(jié)點設計簡單，這就可以使得調(diào)度策略也相對簡單。遵循簡單的原則，我們把調(diào)度中心獨立出來，轉(zhuǎn)碼服務的節(jié)點也獨立出來，每個藍色媒體節(jié)點的功能基本上就相當于一個SFU，進行傳求證的功能，不進行復雜的處理。

服務器節(jié)點和調(diào)度中心的工作機制

圖中展示的是藍色的服務器節(jié)點和調(diào)度中心之間的服務機制。流媒體的服務節(jié)點會定期的以秒/毫秒的級別向調(diào)度中心上報負載的情況。負載的情況包括負載中進出流的輸入帶寬，以及CPU的負載情況，容量和注冊流的信息。每個節(jié)點將信息上報給調(diào)度中心，調(diào)度中心就可以根據(jù)這些信息進行決策，調(diào)度。那么調(diào)度中心能夠給流媒體服務器提供什么樣的幫助呢？流媒體服務器可以向它查詢對應回源的策略，另外調(diào)度中心還可以幫流媒體節(jié)點調(diào)整指令，如某個節(jié)點過載，或者光纖刮斷了，路線需要重新調(diào)整，這個調(diào)整路徑的策略決定是由調(diào)度中心決定的，它通過調(diào)整指令告訴這個節(jié)點該如何進行處理。

單點調(diào)度模式（成本優(yōu)先）

這里簡單介紹一下我們的調(diào)度模式，它分為兩種，一種是單點調(diào)度模式；一種是多點調(diào)度模式。單點，簡單來說就是推流到某個節(jié)點，拉流也從那個節(jié)點進行。這種模式有兩個好處，第一節(jié)省成本；第二傳輸?shù)墓?jié)點越少，延遲就越少。所以從延時的角度來考慮，一般來說，同一個城市我們會采取單點調(diào)度的模式。當然單點調(diào)度模式也有其弊病，如中國和美國的用戶通話，如果采取單點調(diào)度的模式，而節(jié)點設置在中國，讓美國的用戶從中國拉流基本是行不通的。對于這種情況我們有一些后備方案，如果單點拉流體驗不好，達不到要求怎么辦？如果是因為容量不足，負載能力不夠，我們會在同一個機房利用其它的節(jié)點來進行負載。同機房內(nèi)的節(jié)點間，互相拉流是免費，沒有成本的，而且同一個機房的計算資源可以支撐這個負載；如果是因為不同的ISP，網(wǎng)絡之間通訊有問題導致體驗不好，可以通過BGP節(jié)點作為中轉(zhuǎn)。BGP結點在不同的運營商網(wǎng)絡里有不同的IP地址，這樣就可以解決跨網(wǎng)通信的問題。如果還是沒有辦法解決，我們還會有全局網(wǎng)絡節(jié)點來保障其可用性。

多點調(diào)度模式

多點調(diào)度模式其實是為了解決單點調(diào)度模式中存在的問題。多點調(diào)度模式遵循的哲學是體驗優(yōu)先，成本其次。上面所展示的針對國內(nèi)的不需要中轉(zhuǎn)的場景，簡單來說，比如北京的用戶流推到A節(jié)點，會到調(diào)度中心注冊說明推流到了A結點，調(diào)度中心了解掉A節(jié)點流的存在。當深圳節(jié)點的用戶需要拉流觀看，會就近接入節(jié)點C詢問調(diào)度中心如何拉取終端1的流，調(diào)度中心會指示從節(jié)點A拉流，這樣整個調(diào)度過程就完成了。這是動態(tài)回源的方式。

但是對于兩個節(jié)點分別在國內(nèi)外的情況，由于存在的通信問題，需要在中間增加一個中轉(zhuǎn)節(jié)點。通過中轉(zhuǎn)節(jié)點往往會使延遲降低，流暢性提高。

第一公里&最后一公里

第一公里和最后一公里，從調(diào)度的角度來說，它們是一樣的。簡單的邏輯就是，當你向調(diào)度中心詢問應該從哪推流或者拉流，調(diào)度中心就會告訴你答案。在這里我們遵循兩個原則，第一是就近，另外是要考慮負載均衡。當用戶在推流的時候，會詢問調(diào)度中心應該向哪一個節(jié)點推流，調(diào)度中心會給出多個選擇。這一系列的選擇存在優(yōu)先級，首先會考慮到成本，人為的偏好等多種因素。這些選擇主要是通過查IP庫，根據(jù)用戶所在地域，運營商進行分配的，可能會存在一些問題，用戶也會通過測速來選擇最優(yōu)的節(jié)點接入。對于負載均衡，我們采取兩個策略，一個是預售票的策略，舉個例子，假設一個節(jié)點，如果告訴所有的調(diào)度中心這個節(jié)點有三百路下行的推流能力，每個調(diào)度中心都會將這三百路用完，也就會因為重疊而導致節(jié)點擠爆。我們的做法是將三百路分成三份，每個調(diào)度中心的手里只有一百個名額，這樣每個調(diào)度中心都不會用超。萬一發(fā)生資源分配用超的情況，則會在事后進行重定向，也就是對應的第二種策略。

節(jié)點之間傳輸

對于節(jié)點之間的傳輸，前面有提到區(qū)域性的部署，也就是分布式部署。包括了調(diào)度中心要在各個區(qū)域有所部署；服務節(jié)點負擔轉(zhuǎn)碼的工作，它也需要在各個區(qū)域有所部署。調(diào)度中心要做動態(tài)的回源和全局的調(diào)度，必須要監(jiān)控整個網(wǎng)絡鏈路的健康性，每個節(jié)點的容量。并且必須要遵循最短的原則，原因是其成本最低且對應路距短，延遲也會最低。之后還要考慮質(zhì)量的評估，也就是指事后評估。在運營一段時間以后，積累了一定量的數(shù)據(jù)，我們會根據(jù)這些數(shù)據(jù)分析某個時間段推流時節(jié)點效果。在動態(tài)回源的過程中也會主動的做一些實時的測速，根據(jù)測速的結果綜合考慮動態(tài)回源的決策。?

4. 調(diào)度系統(tǒng)的挑戰(zhàn)和應對

就近接入-IP庫問題

關于調(diào)度系統(tǒng)挑戰(zhàn)的應對，首先看第一個問題，即IP庫的問題。第一公里或者最后一公里在就近接入的時候，我們采取傳統(tǒng)的方法是查IP庫。但是查IP庫的方式存在一些問題，因為通過查IP庫得到的信息不是實時的，是查詢時的最終結果，可能已經(jīng)發(fā)生改變。這種情況在國內(nèi)約有10%概率會發(fā)生，而在國外的幾率會更高。那么解決這個問題的方法是，調(diào)度中心通過查IP庫得到結果后，同時返回若干個選擇給客戶端。客戶端獲得選擇后會主動測速來驗證調(diào)度中心所給的結果。?

負載均衡-容量控制的問題

第二個問題是容量控制的問題，前面有提到過一些方法，一個是通過預售票的方式，另外則是重定向的方式。接下來將介紹這兩個方法是如何解決問題的。我們通過多個參數(shù)、多個維度來衡量每個節(jié)點的容量，測量流的數(shù)目就可以反映CPU的運算能力，碼率用來考量網(wǎng)卡的吞吐能力，還有CPU的占有的百分比，另外一個就是純音頻的場景和語音視頻要分成不同的網(wǎng)絡來處理，因為音頻和視頻的碼率不是一個量級的。

智能選路-網(wǎng)絡故障的問題

在網(wǎng)絡故障的情況發(fā)生時，我們會進行路線重新調(diào)度，如果要能夠?qū)崟r的重新調(diào)度另外一個路線，就必須存在多個備用方案。在接入回源時，為了能夠準備多個接入的選擇，調(diào)度系統(tǒng)需要對整個網(wǎng)絡有全局的監(jiān)控才能夠動態(tài)的調(diào)整路由。

智能選路-跨區(qū)域不穩(wěn)定的問題

關于跨區(qū)域不穩(wěn)定的問題，跨區(qū)域指的是不同的區(qū)域，不同的國家之間是靠進出口光纖通訊的。進出口光纖資源是稀缺的，共享的，并且存在很多不穩(wěn)定的情況。為了解決這個問題，我們的出海領域的客戶里大部分還是區(qū)域化的業(yè)務場景，所以我們在每個區(qū)域部署當?shù)氐恼{(diào)度中心，轉(zhuǎn)碼服務器，多條路線的熱備。

智能選路-跨區(qū)域調(diào)度

跨區(qū)域調(diào)度還存在另外一個問題，用上圖的場景來解釋，當深圳的用戶與紐約的用戶之間通話的時候，這里是采用了多節(jié)點調(diào)度的方式。從流程上來說，在紐約的用戶推流出去之前會詢問美東的調(diào)度中心應該推流至哪個節(jié)點？美東的調(diào)度中心會回復它推流到節(jié)點A。當節(jié)點A存在流之后，如果有需求，節(jié)點A 就可以將流貢獻出去。深圳的用戶要跟紐約的用戶進行通話，在拉流之前會詢問華南的調(diào)度中心要從哪個節(jié)點進行。由于是區(qū)域化部署，所以就存在美東調(diào)度中心，華南調(diào)度中心，當華南調(diào)度中心不知道紐約用戶的流在哪時，它有兩種方法。一種是廣播詢問紐約用戶的流在哪，每個調(diào)度中心都會收到這個詢問，當美東調(diào)度中心知道后會回復它用戶流在節(jié)點A，這樣深圳的用戶回源到節(jié)點A拉流。另外一個方式是紐約的用戶通過房間里面的信令告訴深圳用戶這個流在節(jié)點A，華南的調(diào)度中心可以告訴他從美東調(diào)度中心查詢，那么最終深圳的用戶可以通過節(jié)點D回源到節(jié)點A拉流。

多協(xié)議互通-轉(zhuǎn)碼的問題

這是最后要討論的一個問題，在最開始展示的實時架構圖里顯示了支撐不同的接入的終端，比如微信小程序、WebRTC瀏覽器，安卓、iOS，甚至有非WebRTC H5頁面的。不同的終端是使用不同的協(xié)議進行通訊的，流媒體的封裝格式也不一樣。那么不同終端之間的通信就需要轉(zhuǎn)碼。但是轉(zhuǎn)碼，包括解碼、重新編碼會增加延遲，消耗資源，增加復雜度。于是我們采取三種應對的方式，第一種是被動轉(zhuǎn)碼的方式。舉個場景來說，如果有安卓和iOS兩個用戶間通話，兩種終端所用的協(xié)議，編解碼格式都是一樣的，那就不需要轉(zhuǎn)碼。如果這時有第三個人再進這個房間跟這兩個用戶聊天，并且是用網(wǎng)頁版加入進來的。網(wǎng)頁版是通過WebRTC的瀏覽器來支持通話的，網(wǎng)頁版的WebRTC的通信是RTP和RTCP，音視頻格式為H.264/OPUS，2、微信小程序上支持RTMP標準協(xié)議，音視頻格式為H.264/AAC，這里就需要進行轉(zhuǎn)碼，只有在有用戶要進來，必要的時候再進行轉(zhuǎn)碼，這就方式叫做被動轉(zhuǎn)碼。

轉(zhuǎn)碼的服務之間要獨立，比如WebRTC的服務器當作一個子集群，RTMP的協(xié)議包括小程序等都要獨立一個集群來運營。我們的私有網(wǎng)絡也有另外一個大的集群。我們有兩張大的私有網(wǎng)絡，一張是支持RTMP協(xié)議的網(wǎng)絡，另外一個是基于UDP協(xié)議的網(wǎng)絡。具有這三張不同的獨立的小集群就可以提高效率，降低成本。最后展示的是不同終端之間的轉(zhuǎn)碼關系。

精品文章推薦

技術干貨：

• Pixel 3的超分辨變焦技術

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

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

• 騰訊視頻全網(wǎng)清晰度提升攻堅戰(zhàn)

• 英特爾QSV技術在FFmpeg中的實現(xiàn)與使用

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

人物專訪：

• 一切從用戶的需求與體驗出發(fā)

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

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

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。