談到直播，實時性和流暢性一直是整個服務(wù)體系中的重中之重。本文是網(wǎng)易云通信視頻技術(shù)開發(fā)工程師何榮光在LiveVideoStack Meet杭州站沙龍的分享，著重梳理網(wǎng)易云在海外推流方面的部署實踐，幫助開發(fā)者了解如何以更低成本來優(yōu)化節(jié)點與鏈路。

大家好，我叫何榮光，是網(wǎng)易云通信視頻技術(shù)開發(fā)工程師。我們主要業(yè)務(wù)是普通流媒體的RTMP接流服務(wù)，包括網(wǎng)易云SDK，或者是第三方OBS推流，但是我們在處理過程中需要較多考慮傳輸?shù)馁|(zhì)量，也就是卡頓率的指標(biāo)，因此我今天主要分享我們海外直播鏈路優(yōu)化的問題和解決問題的一個思路。我今天介紹的主要流程，大概就是拋出一個問題，簡單介紹我們解決的思路，在這個過程中碰到的一些問題和我們具體進(jìn)行的一些思考，以及后續(xù)可以再進(jìn)行一些額外優(yōu)化的處理。

? ??

●●●

指標(biāo)定義

在介紹整體內(nèi)容之前，首先定義一下我們的性能指標(biāo)，由于我們暫時不考慮實時性，所以主要考慮的是卡頓率。卡頓指的就是觀眾在播放一個視頻的時候，由于網(wǎng)絡(luò)原因，播放器緩沖區(qū)中沒有接收到新的數(shù)據(jù)數(shù)據(jù)了，這個時候畫面就一直轉(zhuǎn)圈，然后一直等待新數(shù)據(jù)的到來，這時候就無法播放。

網(wǎng)易云對卡頓有兩種衡量指標(biāo)，一種是實時卡頓率，以秒級為單位，如果播放器緩沖區(qū)空了，這一秒就記為卡頓，總卡頓率的計算方法就是直播卡頓的秒數(shù)除以總直播秒數(shù)；但是通常我們還會用另一種卡頓率的指標(biāo)，也是以秒級為單位，但是觀察的不是單純一秒之內(nèi)的卡頓，我們考慮的是連續(xù)兩秒卡頓，這個時候用戶會非常明顯的感覺到播放異常，此外，卡頓的出現(xiàn)一般也不會是跳躍式的卡頓，如第一秒卡，第三秒卡，第五秒卡這樣，因此兩秒內(nèi)連續(xù)卡頓發(fā)生，我們就標(biāo)記整分鐘卡頓，這個的總卡頓率就是一個直播卡頓的總分鐘除以總的直播時間。一般來說選擇一分鐘卡頓率這種指標(biāo)會比較嚴(yán)格一點，因為它更可以直觀反映出用戶體驗。

網(wǎng)易云提供了一個平臺級融合CDN的服務(wù)，主要針對企業(yè)級用戶提供解決方案，其中包括使用我們的SDK，或者繞過我們的SDK直接使用推流器進(jìn)行推流。我們今天探討的海外推流的問題，主要場景是我們當(dāng)時接入了網(wǎng)易新聞的業(yè)務(wù)，在聯(lián)合開發(fā)的過程中，發(fā)現(xiàn)當(dāng)一些主播在國外進(jìn)行推流，而觀眾卻是在國內(nèi)的這種場景下，卡頓率就會非常的高，經(jīng)常就在轉(zhuǎn)圈，甚至有些就直接拉不到了，用戶體驗極差。為了處理解決這個問題，需要提高海外直播的接流覆蓋率，并針對鏈路進(jìn)行優(yōu)化，從而有效降低整體從推流到拉流的卡頓率。

●●●

原因分析

首先分析一下原因，當(dāng)直接使用CDN資源時，但是有些CDN廠商在國外是沒有部署源站的，這個時候主播推流會直接傳回國內(nèi)源站，但是一般來說主播的網(wǎng)絡(luò)都不是特別好，國外鏈路到國內(nèi)源站這段鏈路質(zhì)量一般都是比較差的，此外由于RTMP流是基于TCP可靠傳輸?shù)乃栽阪溌泛懿畹臅r候，TCP反映會更劇烈，這樣在主播到國內(nèi)源站這一段時間內(nèi)就已經(jīng)發(fā)生非常大的一個卡頓，不管從國內(nèi)源站到其的邊緣節(jié)點延遲有多低，這個時候觀眾拉到的流一定都是卡的。

還有一種場景是部分CDN廠商在國外是有一些源站的，但是他們在源站和自己國內(nèi)的節(jié)點之間沒有進(jìn)行相應(yīng)的鏈路優(yōu)化，這個時候從國外源站一直到下發(fā)到邊緣節(jié)點的這一段過程，網(wǎng)絡(luò)傳輸效果較差，相當(dāng)于只是把主播到國內(nèi)源站的這一段推流過程放到了網(wǎng)絡(luò)傳輸?shù)闹虚g一公里，以上是出現(xiàn)問題的主要兩種場景。

對于不同的CDN廠商，有一些是有國外源站覆蓋的，但是仍有一些CDN廠商跟國外主播是完全沒有辦法接流的。對于有國外部署源站的廠商，如果覆蓋率不夠，不能滿足客戶分布需求的話，它只能解決一部分場景，比如解決一些比較熱門的城市，但是這些熱門城市并不一定是主播比較集中的地點，而主播集中的地點它反而可能沒有辦法完全的覆蓋到，這種場景下依靠CDN自身的源站能解決的卡頓問題是比較少的。

●●●

解決思路

針對于這個問題，網(wǎng)易云通過自建CDN源站節(jié)點來處理這種場景，因為用戶上行節(jié)點推流一般網(wǎng)絡(luò)狀況都不一樣，有WiFi、4G，我們需要通過自建CDN先把主播的流接過來，然后再通過自建的CDN和回國鏈路之間進(jìn)行中間一公里的一些優(yōu)化，來徹底解決這個問題。但是部署節(jié)點也有一個比較麻煩的問題，就是成本和性能，如果選擇了一個源站覆蓋密度非常高，這個時候用戶體驗肯定會好很多，但是你的成本也就特別高，而且你的主播也并不是一定會用到所有的節(jié)點，容易造成資源的浪費；相反，源站覆蓋密度比較粗，那主播的問題就很有可能并沒有得到解決，成本還是浪費了。

因此需要在成本和性能之間找到一個比較好的平衡點。我們首先根據(jù)一年多以來的歷史數(shù)據(jù)，進(jìn)行分析，選擇海外主播密度較高的幾個主要區(qū)域進(jìn)行一定規(guī)模數(shù)量的節(jié)點部署，完成后我們需要針對這些節(jié)點進(jìn)行相應(yīng)的質(zhì)量評估，評估這些節(jié)點是否有能力承載我們的這些訴求。除此以外，我們還可以進(jìn)行一些相應(yīng)的優(yōu)化，比如說如果是使用一些第三方云服務(wù)云主機(jī)，我們是可以用他們之間的一些專線來進(jìn)行鏈路調(diào)度上額外的優(yōu)化；最后一點是分布式系統(tǒng)必須要經(jīng)常考慮的一個問題，就是節(jié)點的高可用。

這是我們整個的流程圖，主播要開始推流的時候，會先登錄云管理中心去請求一個推流列表，推流列表經(jīng)過云調(diào)度中心去把這個推流地址轉(zhuǎn)換成一個實際推流的源站IP，云調(diào)度中心主要分成兩塊，一塊是中心調(diào)度，是實時的，能實時監(jiān)控所有的源站；還有一塊是基于DNS，因為網(wǎng)易云業(yè)務(wù)本身有不少第三方的推流用戶，這種場景是不經(jīng)過中心調(diào)度的，因此我們需要擁有一個DNS調(diào)度中心，在這兩個調(diào)度背后還隱藏著一個大數(shù)據(jù)平臺，大數(shù)據(jù)平臺在整個解決問題的過程中發(fā)揮一個比較大的作用：所有的數(shù)據(jù)，包括推流和拉流，這些數(shù)據(jù)都會匯總到統(tǒng)計平臺上，統(tǒng)計平臺最后就會完成鏈路調(diào)度的選優(yōu)。當(dāng)主播獲取到這個相應(yīng)的IP以后，會推流到自建的海外CDN源站然后走回到國內(nèi)源站，在國內(nèi)還可以利用融合CDN的優(yōu)勢來通過不同的CDN網(wǎng)絡(luò)進(jìn)行分發(fā)，便于不同的觀眾從質(zhì)量較好的邊緣節(jié)點進(jìn)行拉流觀看。

1. 源站部署

源站部署是自建CDN的第一步，主要是借用第三方云服務(wù)廠商的云主機(jī)。第一步就是要在成本和性能之間做一個平衡，首先，我們利用統(tǒng)計平臺去分析之前將近一年的所有主播推流的數(shù)據(jù)，比如IP分布和一些推流數(shù)據(jù)的測量，篩選出主播最常用的一些地點，并把源站按照這些地域的熱度進(jìn)行分布，并多選擇一些節(jié)點作為備選，以便后面能進(jìn)行一些更好的測評。在完成節(jié)點部署以后，就需要對這些節(jié)點進(jìn)行測評，測評主要分為兩部分：一部分是上行鏈路質(zhì)量的測試，還有一部分是中間一公里傳輸?shù)臏y試。在上行鏈路數(shù)據(jù)的收集，我們額外花了三個月的時間專門用來對這些源站進(jìn)行鏈路數(shù)據(jù)收集，首先先過濾掉一部分性能完全都跟不上的節(jié)點，然后會在源站服務(wù)器上進(jìn)行一個比較長時間的模擬推流，并在國內(nèi)進(jìn)行拉流，把所有數(shù)據(jù)匯總到了大數(shù)據(jù)平臺，最后根據(jù)大數(shù)據(jù)平臺上反饋的數(shù)據(jù)結(jié)果，結(jié)合上行數(shù)據(jù)，整合出一套調(diào)度方案。

這套調(diào)度方案不單純是基于區(qū)域，也會額外考慮收集到的這些數(shù)據(jù)，并賦予一定的權(quán)重，比如說有些是屬于比較偏遠(yuǎn)省份的邊緣數(shù)據(jù)，可以對其進(jìn)行一些額外的細(xì)化，根據(jù)調(diào)度數(shù)據(jù)選擇最合適的調(diào)度點，不一定是物理上所屬的那種區(qū)域概念。

這個是我們當(dāng)時上行優(yōu)化測試出來的數(shù)據(jù);藍(lán)色是我們優(yōu)化后的結(jié)果，橙色是原方案的對比，我們可以看到，大部分的卡頓率都是有所下降的，有一些可能它在比較小的幅度上面會有額外一點點的增加，但是這一部分在后面中間一公里優(yōu)化的時候會變得非常小。

這張圖是中間一公里進(jìn)行傳輸優(yōu)化的測試結(jié)果：藍(lán)色的還是優(yōu)化方案的數(shù)據(jù)，橙色是CDN廠商原來對比的數(shù)據(jù)。可以看到我們自己的數(shù)據(jù)已經(jīng)比它好很多了，基本上是不到一半，而且整體的卡頓率維持在一個比較好的范圍之內(nèi)。

2.智能調(diào)度

除了上面說的，我們還可以依托于云服務(wù)廠商的一些專線服務(wù)，根據(jù)我們自己部署在上面的一些測試腳本，對這些源站進(jìn)行分級和分類，類似于CDN架構(gòu)中的父節(jié)點和邊緣節(jié)點，在這些節(jié)點之間根據(jù)它的分級進(jìn)行一個級聯(lián)型的調(diào)度，并測試級聯(lián)傳輸效率，級聯(lián)調(diào)度并不會造成額外的延遲，但是在合適的鏈路選擇下傳輸優(yōu)化效果非常明顯，可以非常有效的降低相應(yīng)的卡頓率。

這是新方案的流程，從主播推流再到中心調(diào)度這塊跟前面都是一樣的，唯一不同的是在源站接入節(jié)點以后，并不會直接推到國內(nèi)的源站，而會根據(jù)配置的調(diào)度方案，在圖里面實線和虛線相當(dāng)于是兩套調(diào)度方案，我們可以根據(jù)這兩套調(diào)度方案它的性能進(jìn)行評估，然后進(jìn)行一個相應(yīng)的選入過程，在選擇一個最優(yōu)質(zhì)的鏈路調(diào)度以后，將它推回到國內(nèi)源站，再通過我們的融合CDN進(jìn)行分發(fā)。

這張圖是我們整體評估出來的一個測試結(jié)果，測試結(jié)果上面來看：我們的數(shù)據(jù)整體來說已經(jīng)比原來CDN廠商要好很多，大部分都能優(yōu)化將近一半以上。

3.高可用覆蓋

對于高可用來說， GSLB是一個實時調(diào)度方案，它能實時和所有的源站服務(wù)器進(jìn)行保活，還有它相應(yīng)的數(shù)據(jù)收集功能，因此它是可以做到實時高可用的。但是對于一些第三方的推流用戶來說，他們的DNS并不屬于實時調(diào)度的，可能會有一些緩存，因此我們需要對DNS覆蓋下的所有服務(wù)器進(jìn)行其他高可用方案，我們主要采用的是keepalived方案，進(jìn)行一個高可用的保證，keepalived可以使用多機(jī)器根據(jù)虛IP的漂移實現(xiàn)不同機(jī)制之間的組配切換。

這個是我們實際處理的效果，我們從今年5月份開始就逐漸把流量從CDN廠商切換到我們自己的源站服務(wù)器上。上面這張圖是卡頓率的一個圖，下面是采樣點的一個對比，可以看到上面那張圖，使用我們自己源站服務(wù)器卡頓率還是比較低，維持在一個比較低的水平，相對于CDN廠商這種波動，我們還算是一個比較穩(wěn)定的過程。

●●●

后續(xù)優(yōu)化

當(dāng)然我們雖然做了這些，但其實后面還有很多要處理的東西，比如現(xiàn)在針對的產(chǎn)品是國外的推流用戶和國內(nèi)的拉流用戶，但實際上還有一批用戶，觀眾并不在國內(nèi)，這個時候我們還是需要對下行鏈路進(jìn)行一個相應(yīng)的處理，使其可以直接從國外繞出去，并不需要從國內(nèi)再特地走一圈。此外我們還可以針對這種實時的鏈路質(zhì)量進(jìn)行更高精度的智能調(diào)度，我們現(xiàn)在也有收集實時數(shù)據(jù)，但調(diào)度還不是非常實時的處理，我們后續(xù)還可以根據(jù)這些鏈路數(shù)據(jù)進(jìn)行一個比較實時的調(diào)度方案的智能選擇。

——【特別推薦】——

短信效果不好？試試這幾招

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的网易云海外推流部署实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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