摘要：為了處理解決這個(gè)問(wèn)題，需要提高海外直播的接流覆蓋率，并針對(duì)鏈路進(jìn)行優(yōu)化，從而有效降低整體從推流到拉流的卡頓率。

今天主要分享我們海外直播鏈路優(yōu)化的問(wèn)題和解決問(wèn)題的一個(gè)思路，介紹的主要流程，大概就是拋出一個(gè)問(wèn)題，簡(jiǎn)單介紹我們解決的思路，在這個(gè)過(guò)程中碰到的一些問(wèn)題和我們具體進(jìn)行的一些思考，以及后續(xù)可以再進(jìn)行一些額外優(yōu)化的處理。

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

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

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

原因分析

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

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

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

解決思路

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

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

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

1、源站部署

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

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

2、智能調(diào)度

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

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

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

3、高可用覆蓋

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

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

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

隨著音頻處理和壓縮技術(shù)的不斷發(fā)展，效果更好、適用范圍更廣、性能更高的算法和新的技術(shù)必將不斷涌現(xiàn)，如果你有好的技術(shù)或者分享，歡迎關(guān)注網(wǎng)易 MC 官方博客以及微信公眾號(hào)：

關(guān)注更多技術(shù)干貨內(nèi)容：網(wǎng)易云信博客
歡迎關(guān)注網(wǎng)易云信 GitHub
歡迎關(guān)注網(wǎng)易云信官網(wǎng)
官網(wǎng)微信公眾號(hào)：