【網易雲信】海外推流部署實踐

今天主要分享咱們海外直播鏈路優化的問題和解決問題的一個思路，介紹的主要流程，大概就是拋出一個問題，簡單介紹咱們解決的思路，在這個過程當中碰到的一些問題和咱們具體進行的一些思考，以及後續能夠再進行一些額外優化的處理。

指標定義

在介紹總體內容以前，首先定義一下咱們的性能指標，因爲咱們暫時不考慮實時性，因此主要考慮的是卡頓率。卡頓指的就是觀衆在播放一個視頻的時候，因爲網絡緣由，播放器緩衝區中沒有接收到新的數據數據了，這個時候畫面就一直轉圈，而後一直等待新數據的到來，這時候就沒法播放。

網易雲對卡頓有兩種衡量指標，一種是實時卡頓率，以秒級爲單位，若是播放器緩衝區空了，這一秒就記爲卡頓，總卡頓率的計算方法就是直播卡頓的秒數除以總直播秒數；可是一般咱們還會用另外一種卡頓率的指標，也是以秒級爲單位，可是觀察的不是單純一秒以內的卡頓，咱們考慮的是連續兩秒卡頓，這個時候用戶會很是明顯的感受到播放異常，此外，卡頓的出現通常也不會是跳躍式的卡頓，如第一秒卡，第三秒卡，第五秒卡這樣，所以兩秒內連續卡頓發生，咱們就標記整分鐘卡頓，這個的總卡頓率就是一個直播卡頓的總分鐘除以總的直播時間。通常來講選擇一分鐘卡頓率這種指標會比較嚴格一點，由於它更能夠直觀反映出用戶體驗。

背景介紹

網易雲提供了一個平臺級融合 CDN 的服務，主要針對企業級用戶提供解決方案，其中包括使用咱們的 SDK，或者繞過咱們的 SDK 直接使用推流器進行推流。咱們今天探討的海外推流的問題，主要場景是咱們當時接入了網易新聞的業務，在聯合開發的過程當中，發現當一些主播在國外進行推流，而觀衆倒是在國內的這種場景下，卡頓率就會很是的高，常常就在轉圈，甚至有些就直接拉不到了，用戶體驗極差。爲了處理解決這個問題，須要提升海外直播的接流覆蓋率，並針對鏈路進行優化，從而有效下降總體從推流到拉流的卡頓率。

緣由分析

首先分析一下緣由，當直接使用 CDN 資源時，可是有些 CDN 廠商在國外是沒有部署源站的，這個時候主播推流會直接傳回國內源站，可是通常來講主播的網絡都不是特別好，國外鏈路到國內源站這段鏈路質量通常都是比較差的，此外因爲 RTMP 流是基於 TCP 可靠傳輸的因此在鏈路不好的時候，TCP 反映會更劇烈，這樣在主播到國內源站這一段時間內就已經發生很是大的一個卡頓，無論從國內源站到其的邊緣節點延遲有多低，這個時候觀衆拉到的流必定都是卡的。

還有一種場景是部分 CDN 廠商在國外是有一些源站的，可是他們在源站和本身國內的節點之間沒有進行相應的鏈路優化，這個時候從國外源站一直到下發到邊緣節點的這一段過程，網絡傳輸效果較差，至關於只是把主播到國內源站的這一段推流過程放到了網絡傳輸的中間一千米，以上是出現問題的主要兩種場景。

對於不一樣的 CDN 廠商，有一些是有國外源站覆蓋的，可是仍有一些 CDN 廠商跟國外主播是徹底沒有辦法接流的。對於有國外部署源站的廠商，若是覆蓋率不夠，不能知足客戶分佈需求的話，它只能解決一部分場景，好比解決一些比較熱門的城市，可是這些熱門城市並不必定是主播比較集中的地點，而主播集中的地點它反而可能沒有辦法徹底的覆蓋到，這種場景下依靠 CDN 自身的源站能解決的卡頓問題是比較少的。

解決思路

針對於這個問題，網易雲經過自建 CDN 源站節點來處理這種場景，由於用戶上行節點推流通常網絡情況都不同，有WiFi、4G，咱們須要經過自建 CDN 先把主播的流接過來，而後再經過自建的 CDN 和回國鏈路之間進行中間一千米的一些優化，來完全解決這個問題。可是部署節點也有一個比較麻煩的問題，就是成本和性能，若是選擇了一個源站覆蓋密度很是高，這個時候用戶體驗確定會好不少，可是你的成本也就特別高，並且你的主播也並非必定會用到全部的節點，容易形成資源的浪費；相反，源站覆蓋密度比較粗，那主播的問題就頗有可能並無獲得解決，成本仍是浪費了。

所以須要在成本和性能之間找到一個比較好的平衡點。咱們首先根據一年多以來的歷史數據，進行分析，選擇海外主播密度較高的幾個主要區域進行必定規模數量的節點部署，完成後咱們須要針對這些節點進行相應的質量評估，評估這些節點是否有能力承載咱們的這些訴求。除此之外，咱們還能夠進行一些相應的優化，好比說若是是使用一些第三方雲服務雲主機，咱們是能夠用他們之間的一些專線來進行鏈路調度上額外的優化；最後一點是分佈式系統必需要常常考慮的一個問題，就是節點的高可用。

這是咱們整個的流程圖，主播要開始推流的時候，會先登陸雲管理中心去請求一個推流列表，推流列表通過雲調度中心去把這個推流地址轉換成一個實際推流的源站 IP，雲調度中心主要分紅兩塊，一塊是中心調度，是實時的，能實時監控全部的源站；還有一塊是基於 DNS，由於網易雲業務自己有很多第三方的推流用戶，這種場景是不通過中心調度的，所以咱們須要擁有一個 DNS 調度中心，在這兩個調度背後還隱藏着一個大數據平臺，大數據平臺在整個解決問題的過程當中發揮一個比較大的做用：全部的數據，包括推流和拉流，這些數據都會彙總到統計平臺上，統計平臺最後就會完成鏈路調度的選優。當主播獲取到這個相應的IP之後，會推流到自建的海外 CDN 源站而後走回到國內源站，在國內還能夠利用融合 CDN 的優點來經過不一樣的 CDN 網絡進行分發，便於不一樣的觀衆從質量較好的邊緣節點進行拉流觀看。

一、源站部署

源站部署是自建 CDN 的第一步，主要是借用第三方雲服務廠商的雲主機。第一步就是要在成本和性能之間作一個平衡，首先，咱們利用統計平臺去分析以前將近一年的全部主播推流的數據，好比 IP 分佈和一些推流數據的測量，篩選出主播最經常使用的一些地點，並把源站按照這些地域的熱度進行分佈，並多選擇一些節點做爲備選，以便後面能進行一些更好的測評。在完成節點部署之後，就須要對這些節點進行測評，測評主要分爲兩部分：一部分是上行鏈路質量的測試，還有一部分是中間一千米傳輸的測試。在上行鏈路數據的收集，咱們額外花了三個月的時間專門用來對這些源站進行鏈路數據收集，首先先過濾掉一部分性能徹底都跟不上的節點，而後會在源站服務器上進行一個比較長時間的模擬推流，並在國內進行拉流，把全部數據彙總到了大數據平臺，最後根據大數據平臺上反饋的數據結果，結合上行數據，整合出一套調度方案。

這套調度方案不單純是基於區域，也會額外考慮收集到的這些數據，並賦予必定的權重，好比說有些是屬於比較偏遠省份的邊緣數據，能夠對其進行一些額外的細化，根據調度數據選擇最合適的調度點，不必定是物理上所屬的那種區域概念。

二、智能調度

除了上面說的，咱們還能夠依託於雲服務廠商的一些專線服務，根據咱們本身部署在上面的一些測試腳本，對這些源站進行分級和分類，相似於 CDN 架構中的父節點和邊緣節點，在這些節點之間根據它的分級進行一個級聯型的調度，並測試級聯傳輸效率，級聯調度並不會形成額外的延遲，可是在合適的鏈路選擇下傳輸優化效果很是明顯，能夠很是有效的下降相應的卡頓率。

這是新方案的流程，從主播推流再到中心調度這塊跟前面都是同樣的，惟一不一樣的是在源站接入節點之後，並不會直接推到國內的源站，而會根據配置的調度方案，在圖裏面實線和虛線至關因而兩套調度方案，咱們能夠根據這兩套調度方案它的性能進行評估，而後進行一個相應的選入過程，在選擇一個最優質的鏈路調度之後，將它推回到國內源站，再經過咱們的融合 CDN 進行分發。

這張圖是咱們總體評估出來的一個測試結果，測試結果上面來看：咱們的數據總體來講已經比原來 CDN 廠商要好不少，大部分都能優化將近一半以上。

三、高可用覆蓋

對於高可用來講， GSLB 是一個實時調度方案，它能實時和全部的源站服務器進行保活，還有它相應的數據收集功能，所以它是能夠作到實時高可用的。可是對於一些第三方的推流用戶來講，他們的 DNS 並不屬於實時調度的，可能會有一些緩存，所以咱們須要對 DNS 覆蓋下的全部服務器進行其餘高可用方案，咱們主要採用的是 keepalived 方案，進行一個高可用的保證，keepalived 可使用多機器根據虛IP的漂移實現不一樣機制之間的組配切換。

後續優化

固然咱們雖然作了這些，但其實後面還有不少要處理的東西，好比如今針對的產品是國外的推流用戶和國內的拉流用戶，但實際上還有一批用戶，觀衆並不在國內，這個時候咱們仍是須要對下行鏈路進行一個相應的處理，使其能夠直接從國外繞出去，並不須要從國內再特意走一圈。此外咱們還能夠針對這種實時的鏈路質量進行更高精度的智能調度，咱們如今也有收集實時數據，但調度還不是很是實時的處理，咱們後續還能夠根據這些鏈路數據進行一個比較實時的調度方案的智能選擇。

---

隨着音頻處理和壓縮技術的不斷髮展，效果更好、適用範圍更廣、性能更高的算法和新的技術必將不斷涌現，若是你有好的技術或者分享，歡迎關注網易 MC 官方博客以及微信公衆號：

關注更多技術乾貨內容： 網易雲信博客
歡迎關注 網易雲信 GitHub
歡迎關注 網易雲信官網

官網微信公衆號：