TOP100summit【分享實錄-網易】構建云直播分發網絡

邵峰:網易視頻云、網易杭州研究院服務端技術專家

浙江大學計算機專業博士畢業。

自畢業以后從事數據庫、分布式存儲等領域研究,有十年左右的服務端開發經驗。

目前在網易視頻云負責產品化研發工作,在服務端開發、存儲/數據庫開發等方面有豐富的實戰經驗。

導讀:在網易視頻云直播產品開發中,研發團隊遇到了直播卡頓難題。如何提供穩定、流暢、無卡頓的直播服務,是當時迫切需要解決的問題。通過客戶端分析、網絡統計等手段,定位卡頓問題的根源在于直播分發網絡不佳。能否提供一套可靠的直播分發網絡,決定了直播是否有卡頓,也最終決定了用戶的直播體驗。

為了流暢的直播體驗,保證基本無卡頓,技術團隊采用了一種融合式分發網絡架構。通過該融合分發網絡,直播云服務基本解決了卡頓問題,保證了流暢的直播體驗。本文將介紹網易云直播分發網絡架構的構建及優化過程。

一、問題的提出

直播業務迅猛發展,但其背后的直播技術門檻較高,為了降低技術門檻,讓產品開發者迅速開發出直播產品,就出現了直播云服務的概念。直播云服務,為直播提供了端到端的解決方案,包括:直播端采集-編碼-播放、網絡端轉碼-分發、播放端解碼-播放等。其中每個環節都涵蓋大量技術,同時也影響著直播質量的高與低。

網易視頻云就是為開發者用戶提供這種直播云服務。我們在直播云服務的建設過程中,發現直播網絡體驗是所有直播產品的痛點,穩定、流暢、無卡頓是所有直播產品的共同訴求。那如何把我們的直播云服務做到體驗好、無卡頓呢?起初,我們采用了一系列音視頻技術,對主播和播放兩端進行了優化,體驗未得到實質性改善。分析后,我們把焦點集中于網絡端,因此上述問題被轉化為:如何優化分發網絡,從而保證直播無卡頓、體驗好?

在網絡分發端,起初我們采用了一個傳統第三方CDN網絡,但第三方CDN在帶寬配置和節點部署上存在諸多限制,而且直播線路調整采用人工手段,因此無法滿足我們的優化需求。接著我們自建了一套分發網絡,但由于節點數不足,分發性能要求也不甚理想。后續,我們又接入了多家第三方CDN網絡,但每一家都不能完全滿足我們的“無卡頓、體驗好”的要求。最后,我們考慮能否在已有的單CDN分發網絡基礎上,構建一個融合式直播分發網絡,達到穩定流暢要求?因此,我們開始了一趟融合分發網絡的構建旅程。

二、實踐過程

我們的云直播分發網絡構建,從時間維度分為三階段:單CDN階段、多CDN階段和融合CDN階段。各階段是漸進式發展的。

2.1 單CDN階段

單CDN-構建階段

我們為云直播服務選用了一個傳統的第三方CDN分發網絡。通過封裝調用第三方CDN的分發網絡接口,構筑了一套完整的分發網絡服務,其基本架構如圖1所示。

圖1. 單CDN分發網絡

單CDN分發網絡的優點是實現簡單,能快速封裝實現。在我們云服務發展初期,該方案能幫我們迅速實現產品,并且應用于實際場景。

缺點很明顯:網絡不穩定、卡頓率較高,并且線路調優較為麻煩。

單CDN-優化階段

當我們的用戶量達到一定規模時,單個CDN的問題就集中體現出來了,首先網絡不穩定,經常出現卡頓掉線等情況,而且對國內運營商網絡存在差異化支持,例如電信、聯通線路較好,而移動線路較差等問題。

通過與第三方CDN排查問題,發現其本質原因為:節點覆蓋不足、帶寬資源提供不足。

通過讓CDN廠商加節點資源、優化線路,部分解決了卡頓流暢性問題,但是無法從本質上解決網絡覆蓋等問題。

2.2 多CDN階段

多CDN-構建階段

針對第三方CDN的問題,我們考慮采用多CDN方案加以解決。通過對不同的幾個CDN廠商進行基調測試后,發現每個CDN廠商都有局部優勢和劣勢,例如CDN廠商A對移動線路支持較好,而CDN廠商B對電信/聯通線路支持較好。針對該特點,我們接入了多家CDN進行節點及線路互補。對于一些特殊區域,例如小運營商、海外節點等情況,我們通過部署自有節點,開發了一套簡單的自研CDN進行區域覆蓋。最終我們形成了一個多CDN分發網絡系統,架構如圖2所示。

圖2. 多CDN分發網絡

多CDN-優化階段

在多CDN分發網絡中,由云管理中心為主播選擇分發線路。在卡頓率分析時,我們發現上行推流的穩定性起著決定作用。因此我們根據主播端的IP,查詢推流源位置信息,然后選擇最佳CDN進行流分發。

舉例說明,主播A為北京移動線路,我們就選擇上行較優的CDNⅡ進行分發;主播B為上海電信線路,選擇電信較優的CDNⅠ進行分發。選擇策略在云管理中心進行配置。選擇策略根據,基調測試結果或線上結果反饋,定期調整。

2.3 融合CDN階段

融合CDN構建階段

多CDN分發網絡極大地降低了卡頓率,但運行一段時間后,我們發現多CDN分發網絡,還存在一些缺陷,例如第三方CDN上行線路無法達到最優化;下行觀眾端拉流無法選擇最佳CDN;直播線路無法臨時調優等。

為此,我們重構了分發網絡,提出了一種融合CDN架構,如圖3所示。融合CDN分發網絡,在多CDN的基礎上,主要增加了兩大功能:接流源站和智能云調度中心。

●通過自建接流源站,我們能最大限度的優化直播上行線路。

●通過智能云調度中心,我們能自適應網絡環境,根據網絡變化,動態的調整上下性線路。

圖3. 融合CDN分發網絡

融合CDN優化階段

當前我們處于融合CDN使用階段,但我們還將對該分發網絡進行優化。考慮下行線路,第三方CDN廠商無法完全覆蓋所有區域,而自研分發網絡構建/維護成本過高。因此,考慮對于CDN廠商無法覆蓋的下行區域,如果用戶訪問密度高,我們將在下行邊緣做一層服務轉發。

這樣帶來的好處有兩點:

●增加邊緣覆蓋率,同時降低CDN流量成本;

●路由判斷更加精準,避免CDN廠商路由漂移情況。

其框架如圖4所示,我們正處于該優化階段的建設過程中。

圖4. 融合CDN分發網絡-改進

直播分發網絡構建中,融合CDN分發網絡的設計/建設最為關鍵。

接下來將具體描述其兩大關鍵模塊的設計思路:接流源站、智能調度中心。

接流源站

在最初的設計中,源站的目的性很明確,用于接收主播的推流,并轉發CDN。由于直播流采用rtmp協議,因此源站主要實現了rtmp協議處理。在內部,源站架構分為三層:接口協議層、邏輯處理層和網絡分發層。

●接口層接收解析rtmp流協議;

●處理層進行流媒體處理;

●網絡分發層進行rtmp轉發。

需要注意的是:每路推流轉發一路給不同的CDN網絡,這樣觀眾就能從不同的CDN網絡獲取流信息。

隨著云直播業務的擴展,互動直播以及直播連麥等需求也引入到了直播框架中,因此我們對源站進行了擴展,提供了一種多協議源站。引入的協議為RTP類協議,有交互性要求或實時性要求較高的直播形式,都走RTP類協議,其底層走UDP通道。而對廣播式要求,我們通過RTMP轉封裝和混屏處理,無縫對接現有CDN。整體框架如圖5所示。

圖5. 多協議源站

源站調度

我們在全國二十幾個主要區域部署了源站集群,在重要區域,例如北京、上海、廣州、杭州等,采用BGP網絡。其他區域采用多線。從而保證用戶與源站之間網絡的高質量。我們通過全局調度中心GSLB進行源站調度。調度中心,通過心跳式探活,感知實時情況。通過配置模塊,動態調整源站的配置,如流量限制,黑白名單限制等。主播在推流之前,從調度中心獲取源站路由。調度中心會根據推流源地址、策略表,最優選擇一個源站。整體框架如圖6所示。

圖6. 源站調度

調度中心智能調優

調度中心是整個分發網絡的核心,它統一調度上行接入點和下行拉流點。調度中心內部最重要的是路由規則表的制定。傳統的規則表是固定配置規則表,跟實際網絡的適配性較差。我們在融合網絡中,設計了一套智能調優策略,通過網絡實際情況動態調整規則。調優的流程如圖7所示,采用五步驟循環模式。

●步驟1,GSLB調度中心獲取/解析用戶地址信息;

●步驟2,調度中心獲取已有調度規則;

●步驟3,調度中心生成路由地址,下發客戶端;

●步驟4,兩端上報卡頓信息到云統計中心;

●步驟5,云統計中心,定時分心數據,觸發規則,調整規則庫。

圖7. 調度中心路由調優

通過這些步驟,調度中心實現了統計式自調優。

三、效果評價

我們在真實環境對上述分發網絡進行了一系列對比測試,核心測試點就是卡頓率指標。為增加云直播產品質量,我們在卡頓率指標選擇上采用了更為嚴格的一分鐘卡頓率,而未使用常規的時長卡頓率。

所謂一分鐘卡頓率,就是如果一分鐘之內播放器連續卡兩次,就視為該一分鐘都為卡頓。而時長卡頓率,以每秒鐘為間隔,該秒內播放器卡,視該秒為卡頓。播放器卡的定義為:解碼線程每隔3ms從播放器緩沖區獲取數據,如果緩沖器為空,則定義為播放器卡。一般意義上,一分鐘卡頓率 = 4 ~ 15倍 × 時長卡頓率。

圖8. 兩周卡頓率比較

如圖8所示,我們選擇了X、Y、Z三個月的前半個月(兩周)卡頓率數據進行了比較。其中X月運行了單CDN分發網絡;Y月運行了多CDN分發網絡;Z月運行了融合CDN分發網絡。每天給出一個綜合卡頓率數據。各月,云平臺環境情況為:網絡實際流量分別為日均5TB、12TB和20TB, 98%以上流量運行于國內, 流量無重大區域變化性差異。從圖中,可以看出卡頓率有了明顯下降,在融合CDN分發網絡中,達到了我們預定<5%的指標要求。

圖9. 卡頓率優化比例

如圖9所示,給出了單CDN、多CDN和融合CDN的平均卡頓率下降指標。使用多CDN分發網絡比用單CDN分發網絡兩周平均卡頓率下降26%。 使用融合CDN分發網絡比用多CDN分發網絡兩周平均卡頓率下降44%。

因此,我們根據統計總結出:融合CDN分發網絡,能極大優化網絡分發,并把卡頓率指標降到了小于5%的優質范圍。接下來,為了達到極致體驗,我們將繼續改進融合CDN分發網絡,在拉流端考慮進一步優化。

四、推廣建議

●使用漸進方式,分階段進行網絡優化;

●網絡框架優化前,必須事先分析,尋找關鍵瓶頸點;

●網絡數據收集很重要,盡可能多收集;

●必須深挖細節點,每個小模塊都能做出大文章;

●國內網絡環境有特殊性,必須考慮運營商和區域性因素;

●邊緣加速很重要,盡量靠近用戶;

●善于使用第三方服務,并能在別人服務基礎上進行優化升華。

11月9-12日,北京國家會議中心,第六屆TOP100全球軟件案例研究峰會,網易云通信與視頻技術專家劉心坤將分享《網絡擁塞控制以及在實時通信領域中的應用》。日程查看. ?

免費體驗票申請入口

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,791評論 6 545
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,795評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,943評論 0 384
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 64,057評論 1 318
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,773評論 6 414
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 56,106評論 1 330
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 44,082評論 3 450
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 43,282評論 0 291
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,793評論 1 338
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,507評論 3 361
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,741評論 1 375
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,220評論 5 365
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,929評論 3 351
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,325評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,661評論 1 296
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,482評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,702評論 2 380

推薦閱讀更多精彩內容