摘要：實時互動直播延時必須低達幾百毫秒。實時互動直播要保證高可用性，有巨大的難度，原因如下實時很難。單服務器實時互動直播架構實時互動直播，不能使用方案，因為方案性質決定了延時達不到實時的要求。

現在比較流行的直播，經常會出現這樣的情況： 用戶打了一個彈幕上去，主播念出來的時候，彈幕已經飛出去了。二者時間是不匹配的。

這是我們的一個客戶，兩個主播連線互動，實時交互。試想，如果直播時延時高達幾秒，像這樣的雙主播組合是沒有辦法進行交談的。A說完之后，對方要等幾秒才能聽到，又過了幾秒，A才能聽到對方的回答。

這兩個例子其實要說明實時互動直播和普通直播相比有本質的區別：延時。實時互動直播延時必須低達幾百毫秒。

為什么是幾百毫秒？為什么不是幾秒也不是幾毫秒？這是由人們日常交流習慣決定的。人的說話聲音通過聲波傳播，如果兩人相隔34米，那么延時就是100毫秒。基于這個范圍，略長的延時，觀眾還能。基于互聯網的音視頻通信，音頻通話延時標準在400毫秒以內，視頻通話延時在800毫秒以內，這可以讓通話雙方無延時感知的。延時如果達到秒的數量級，那么通話雙方就會有明顯的等待。

互聯網是基于電磁波或者通過光纖傳播的。光繞地球一圈，耗時300毫秒，這是無法逾越的物理定律延時。有人號稱可以做到0延時，他們估計用上了量子通信。在實際互聯網應用中，網絡條件并不理想，互聯網信號繞地球一圈的延時必然大于300毫秒。這就給實時互動直播，帶來了巨大的挑戰。

第一，互聯網的骨干網上路由器的部署，不是直線點到點，而是中間要經過很多路由器的跳數，實際上是在走“彎路”。所以，互聯網傳輸沒有辦法繞地球一圈正好300毫秒，最好的情況也需要要近400毫秒。

第二，公共互聯網上，路由器其實經常出現故障。比如，在晚高峰的時候，網絡會比較慢。這是因為部分路由器可能過載。因為路由器有最大的處理能力上限，一旦超過上限，就不能處理，會造成丟包、擁塞。

第三，無線網絡相對有線網絡，可靠性較低。無線網絡普及度越來越高，，越來越多的手機、筆記本連接無線網。但是無線網絡相對有線網絡沒有那么可靠，同時也會引入信號污染。信號覆蓋不到的地方，效果較差。

第四，高并發挑戰。首先需要普及一個概念：并發和在線是有區別的。當今的移動互聯網，大家都在講千萬級。當我們談及海量用戶架構這個話題時，似乎如果不說到上億這個量級，是落后了。但是實際上，前面這些說法都混淆概念了，它們都在說“在線”，而不是“并發”。以下圖為例：

左邊是QQ在線好友列表，圖中可以看到很多好友展現，其實沒有交互，使用者不會有壓力。右邊是一個框同時和很多人聊天，使用者會感受到巨大壓力。同樣的，對于直播服務而已，如果用戶只是在線，很少會跟服務器有交流，最多偶爾發一個心跳包。

用戶在線時，如果參與了“看”“說”，這就是并發。直播的并發峰值具有突發性，往往跟主播的活動密切相關。比如，主播會跟粉絲約定直播時間，到了約好的時間，粉絲就會在短時間大量涌入一個直播頻道。觀眾慢慢進入頻道，服務器沒有壓力，但如果瞬間涌入，后臺的壓力非常大。

本文，將重點介紹互動直播的可用性問題。電信業務的可用性標準是四個九，我們期望做到五個九。雙十一時，支付寶的處理能力非常強，百度百科上提供的數據顯示，支付寶當天處理了96%訂單。但是，我們對自己的互動直播有更高的要求，期望做到99.999%。

實時互動直播要保證高可用性，有巨大的難度，原因如下：

實時很難。互聯網基礎設施不是為實時通信設計的。

覆蓋很難。機房找點，互聯互通。對通信云來說，覆蓋不好會影響到可用性。

高并發很難。不能看著看著就不動了，沒聲了。

突發性很難。系統容量要高，還要防止雪崩。

這些挑戰我們在做整個服務的時候，都需要全面考慮。

這是當前流行的直播架構，左下角是一個主播，主播通過手機或電腦等設備，把自己的視頻流上傳到服務器，接入目前流行的CDN服務，通過CDN服務進行網絡分發，分發到各地的用戶。所有用戶都可以看到主播的表演。

實時互動直播，不能使用CDN方案，因為CDN方案性質決定了延時達不到實時的要求。下圖是我們認為可以實現實時互動的架構。主播把自己的視頻流上傳到服務器，通過這臺服務器分發給其他用戶，再采用合適的傳輸協議，延時可以做到很小。從主播到服務器再到觀眾的延時，加上編解碼和抖動的延時，可以做控制在幾百毫秒以內。

這個架構很簡單，但有一個缺點，沒有考慮覆蓋不同地用戶的問題。并且一臺服務器支撐不了大規模用戶。這臺服務器如果宕機，或者服務器機房出故障，整個傳輸都會受到影響。這必然達不到高可用架構的標準。

主播的視頻流上傳到一個接入服務器，這個服務器會把這個視頻流分發到我們部署在世界各地的服務器。然后這些服務器接入本地的用戶，把視頻傳下去。

在這個架構里面，首先可以解決的是覆蓋問題，部署在世界各地的服務器，可以讓用戶可以快速就近接入。整個視頻流通過我們在互聯網上做的分布式傳輸算法，把它實時的傳輸到世界各地的機房。其次，可以避免機房甚至骨干網故障，對傳輸造成的影響。

可用性可以分為兩個部分：接入可用性和使用可用性。你在使用服務的時候，能夠接得進去，能夠聽得到，這是接入可用性。舉個例子，打電話的時候，有時會出現你所呼叫的用戶無法接通，因為用戶的手機沒有接入電信服務，這就是接入可用性問題。在通話的時候，聽不到對方說話了，使用中掉線了，這就是使用可用性。

為了實時監測可用性，我們做了兩方面的監測：

1、主動監測

服務可用性不能依靠用戶數據反饋或者用戶主動上報，這樣你永遠是最后一個知道的。況且初期用戶量小怎么辦？因此，我們需要自己給出我們的服務有多可靠。為此，我們研發主動監測系統來監測整個服務。端到端監測，接入有沒有問題，在使用的過程中會不會出問題。

2、被動監測

用戶在使用我們的服務的時候，我們會收集用戶接入服務的整個過程，多長時間可以接入，接入時經過了幾次請求，使用中有沒有掉線，中間有沒有聲音終端或卡頓。我們會收集這些數據，據此了解服務的可用性。

有了監測數據，那么就可以據此來不斷改進我們的服務，解決前面所說的挑戰。

在中國做互聯網的人應該都有一個感受，聯通跨電信，用戶之間是難以交互的。早期的QQ傳文件沒有做中轉，如果聯通和電信的用戶要互相傳文件，速度非常慢，甚至會中斷。玩網游的用戶，也會遇到有電信專區、網通專區。下圖是一個簡單的測試，當跨運營商的時候，發一個包，可以看到里面有很多丟包。這個數字是RTT，這個測試結果可以看出，最小是62毫秒，最大是840毫秒。

不但中國有網絡互通的問題，國外也有。很多人以為發達國家，比如美國、日本，互聯網的基礎設施較好，所以不會有互聯互通的問題。但是，在我們做實際測試時，美國的互聯網也存在互聯互通的問題，只是狀況比中國好一些。

上圖，展示了一個一個阿爾及利亞用戶的網絡狀況。他接入的是國家電信的服務商，從骨干網接入阿爾及利亞電信有很多線路，最下面的線路意大利電信是最直接的。如果不走意大利電信，那么中間就必須經過很多運營商跳轉。在這種情況下，要保證用戶有做最快的傳輸，就要保證傳輸走意大利電信。這必須依靠覆蓋來解決。

如何解決覆蓋問題？

首先，部署大量邊緣服務器。邊緣服務器的地理位置越接近用戶越好，二者的線路越接近約好，同一個SP最好。比如中國國內，我們會有大量電信、聯通、移動服務器。當我們發現一個接入的用戶是電信時，我們會找電信線路，如果是聯通的會找聯通線路。再看回上一個圖，如果遇到阿爾及利亞的用戶要怎么辦？在現在的服務里面我們就要找一個意大利電信接入，而不是隨便找歐洲的機房。必須部署很多邊緣服務器才能做到這一點。

其次，要有分配服務。有邊緣服務器之后，用戶還是無法接入邊緣服務器，因為他不知道接哪個。因此，必須有配套算法，根據用戶的SP，找到和他最匹配的邊緣服務器，來進行接入分配。

我們在全中國有好幾十個機房，其中有很多電信的機房，不同的電信用戶來使用我們的服務，應該給他哪個電信機房呢？如果把北京電信用戶接到廣州的電信機房，雖然大多數情況下丟包不會很高，但延時會比較大。為此，我們設計了就近接入算法，使用我們服務的每個用戶，都會接入到最靠近他，且線路最匹配的服務器。

當我們就近按SP接入時，遇到了一個新問題：假如一個香港用戶，接入的是香港機房，想看北京聯通用戶的表演，那么這個香港用戶怎么看到北京用戶的表演呢？我們就需要有一個分布式傳輸的架構和算法，來把北京的流量傳到香港。

今天無線互聯網非常普及，使用無線網時，有一個問題比有線網更嚴重：DNS解析。用戶接入時，第一步是通過域名解析，解析到最近的服務器。但是，做DNS解析時，無線網絡的信號會存在污染，導致DNS解析失敗。為此，我們優先使用解析，解析不到再用靜態IP配置。

我們發現在骨干網上，很多默認的骨干網路由經常出問題，同時有一些骨干網部分是不會擁堵的。基于這樣的發現，我們做了自己的路由網絡。

在默認路由之外，我們會額外部署路由機房。比如，從上海到洛杉磯，假設默認線路到晚上高峰期會比較擁堵，同時我們發現從上海經過廣州再經過香港再到洛杉磯，這條線路不會擁堵。那么，我們就會部署這樣一條路由線路，然后做自動的適配。

如果骨干網上出故障了，我們通過路由的方式構建Overlay應對。首先，我們的應用會先連接到分配服務，分配服務會給出一批可接入的機房，當接入的機房壞了，就立即切換到下一個可用機房，如果發現還是壞了，則再次接入到分配服務，繼續尋找當前可用服務器。

蜂擁是實時互動直播里面特別突出的現象，短時間內大量用戶進入頻道或者使用服務。蜂擁對整個后臺的沖擊力非常強。大多數的互聯網的后臺服務器每秒接入大概千的量級，但是對于蜂擁而來的用戶，處理量遠遠不夠。這時候就會遇到一個問題，后臺處理響應速度越來越慢，很多用戶的請求會超時。超時之后就會進入更多的請求，請求就會像滾雪球一樣越來越大，導致整個后臺系統不能響應，整個系統就會產生雪崩，這叫雪崩效應。

1）要把性能上限提高。通常來說我們的性能上限會達到峰值處理能力10倍以上。性能上限提高要做分配服務性能擴展，我們的做法一般是水平擴展，因為垂直擴展比較困難。

2）應用里面做自動的重復請求，它會不斷累計請求量，我們要做退避的策略。

3）保證整個接入服務本身的可用性問題，處理方法很簡單，多點備份，然后做并發的請求。我們有很多分配的服務器，們的應用接入的時候會同時從幾個點請求分配，分配到一批邊緣服務器之后，會同時連接幾個邊緣服務器，哪個先響應就處理哪個。

本文整理自聲網Agora.io 1號架構師李偉，在ArchSummit深圳2016 全球架構師峰會 的演講。

【李偉】

2006年-2008年，在PP live工作的時候研發了PP live（已更名PPTV），當時最高有接近150萬人在線。
2008年到2010年，在新浪負責新浪視頻的研發，2008年的歐冠直播，40萬人在線。
2010年到2013年在YY工作，主要負責YY的架構，最高在線是超過一千萬，最大的單人頻道達150萬左右。
2013年，加入聲網，負責聲網音視頻的系統架構。