1、構(gòu)建云直播分發(fā)網(wǎng)絡(luò)案例簡(jiǎn)述背景介紹 實(shí)踐思路 實(shí)踐過(guò)程 實(shí)踐小結(jié) 案例分析 案例啟示本案例，將描述網(wǎng)易云直播產(chǎn)品開發(fā)中，流媒體分發(fā)網(wǎng)絡(luò)的構(gòu)建過(guò)程。項(xiàng)目實(shí)踐中，為了保證全網(wǎng)直播流暢性、降低直播卡頓，分發(fā)網(wǎng)絡(luò)建設(shè)經(jīng)歷了單 CON 模式 - 多 CON 模式 - 融合 CON 模式三個(gè)階段演變，最終達(dá)到了直播服務(wù)基本 無(wú)卡頓的要求。目標(biāo)：1.直播流能夠全網(wǎng)分發(fā)；2.流分發(fā)基本無(wú)卡頓（卡頓率 5%)案例簡(jiǎn)述網(wǎng)易云直播是 PaaS 級(jí)云服務(wù)，對(duì)企業(yè)級(jí)用戶提供直播解決方案云課堂項(xiàng)目開發(fā)中，遇到了直播流分發(fā)卡頓難題 傳統(tǒng)的 CON 分發(fā)網(wǎng)絡(luò)，無(wú)法根本解決卡頓問(wèn)題由千中國(guó)網(wǎng)絡(luò)的復(fù)雜性，構(gòu)建一套完美的、面向全網(wǎng)

2、環(huán)境的流分 發(fā)網(wǎng)絡(luò)，是業(yè)界的一大難題背景介紹降卡頓尋找問(wèn)題瓶頸點(diǎn)分布解決瓶頸點(diǎn)1.節(jié)點(diǎn)覆蓋不全2.CON 接流點(diǎn)不佳3.線路調(diào)整漫區(qū)域卡頓、運(yùn)營(yíng)商卡頓主播上行推流卡頓持續(xù)卡頓單 CON 擴(kuò)展為多 CON自建接流源站中心調(diào)度智能化實(shí)踐思路推流（RTMP)拉流（RTMP/HLS/ HTTP)推流端(iOS / Android / PC / Web)流媒體分發(fā)網(wǎng)絡(luò) 播放端(iOS / Android / Web)錄制視頻存儲(chǔ)服務(wù)視頻轉(zhuǎn)碼系統(tǒng)視頻點(diǎn)播系統(tǒng)(VOO)直播錄制系統(tǒng)播放器(iOS / Android / Web)流媒體分發(fā)網(wǎng)絡(luò)錄制視頻上傳HTTP 方式 視頻上傳視頻專馬視頻點(diǎn)播點(diǎn)播回源拉流（

3、HTTP/HLS)云 直 播云 點(diǎn) 播實(shí)踐過(guò)程 1.1(直播云框架)邊緣服務(wù)邊緣服務(wù)邊緣服務(wù)中心服務(wù)集群分發(fā)調(diào)度系統(tǒng)轉(zhuǎn)碼集群接流服務(wù)推流(RTMP 協(xié)議)傳統(tǒng) CON 分發(fā)網(wǎng)絡(luò)主播觀眾拉流(RTMP 協(xié)議)拉流(HTTP / HLS 協(xié)議)拉流(HTTP / FLV 協(xié)議)實(shí)踐過(guò)程 1.2(建設(shè)初期 單 CON 模式)1.節(jié)點(diǎn)覆蓋不去，卡頓率高2.流量高峰期，容錯(cuò)能力差3.第三方 CON，線路優(yōu)化較漫1.實(shí)現(xiàn)簡(jiǎn)單，能快速搭建2.對(duì)云直播早期建設(shè)具有很 大的幫助1.接入多家 CON 廠商，解決節(jié) 點(diǎn)覆蓋和備份間題實(shí)踐過(guò)程 1.2(單 CON 模式分析)CON 分發(fā)網(wǎng)絡(luò) ICON 分發(fā)網(wǎng)絡(luò) II自

4、研分發(fā)網(wǎng)絡(luò)分配直播地址 A分配直播地址 B分配直播地址 C云管理中心主播 C主播 B主播 A推流推流推流拉流拉流拉流觀 眾 A1 / A2觀 眾 B1 / B2觀 眾 C1 / C2推 / 拉流地址綁定域名解析推流地址解析拉流地址ONS 中心實(shí)踐過(guò)程 1.3(建設(shè)中期 多 CON 模式)優(yōu)點(diǎn)缺點(diǎn)1.節(jié)點(diǎn)覆蓋情況改善，線路調(diào)優(yōu)更 加快速；2.對(duì)比單 CON 模式，卡頓率有明 顯下降。1.上行推流網(wǎng)絡(luò)，無(wú)法進(jìn)步優(yōu)化；2.無(wú)法自動(dòng)化調(diào)優(yōu)線路。實(shí)踐過(guò)程 1.3(建設(shè)中期 多 CON 模式)分配直播地址 云管理中心主播 推流接流源站CON 分發(fā)網(wǎng)絡(luò) ICON 分發(fā)網(wǎng)絡(luò) II自研分發(fā)網(wǎng)絡(luò)拉流拉流拉流觀眾觀

5、眾觀眾解 析 推 流 地 址獲取推流地址列表解析拉流地址實(shí)踐過(guò)程 1.4(現(xiàn)階段 融合 CON 模式)GSLB云調(diào)度中心接流源站調(diào)度中心作用：優(yōu)化上線推流網(wǎng)絡(luò) 難點(diǎn)：支持推流協(xié)議； 如何全國(guó)布點(diǎn)；如何接入下行 CON。作用：優(yōu)化用戶上下行線路 優(yōu)化源站資源難點(diǎn)：面對(duì)復(fù)雜網(wǎng)絡(luò)，如何提供最 佳路由；如何管理源站資源實(shí)踐過(guò)程 1.4(融合 CON 模式 關(guān)鍵改進(jìn)點(diǎn))探活配置路由策略GSLB調(diào)度中心地址路由直 播 推 流主播心跳心跳心跳配置調(diào)整配 置 調(diào) 整配置調(diào)整北京 BGPRTC_bjARTC_bjBRTMP_bjARTMP_bjB 廣州RTC_gzABGPRTC_gzBRTMP_gzARTMP_

6、gzB杭州RTC_hzABGPRTC_hzBRTMP_hzARTMP_hzB實(shí)踐 2.1(融合 CON 模式 接流源站)主播A參與者A主播BWebRTC 協(xié)議RTMP 協(xié)議媒體處理協(xié)議轉(zhuǎn)封裝混屏處理RTMP多路轉(zhuǎn)發(fā)第三方 CON第三方 CON自有 CON媒體處理接口協(xié)議層邏輯處理層網(wǎng)絡(luò)分發(fā)層實(shí)踐 2.2(融合 CON 模式 多協(xié)議源站)互動(dòng)直播 / 連麥直播推流實(shí)踐 2.3(融合 CON 模式 自學(xué)習(xí)調(diào)度中心)主播推流器融合 CON觀眾拉流端云統(tǒng)計(jì)中心規(guī)則庫(kù) 2.獲取調(diào)度規(guī)則1.獲取地址信息IP 地址庫(kù)GSLB 調(diào)度中心3.兩端路由地址下發(fā)推流推流4.兩端卡頓信息上報(bào)5.觸發(fā)規(guī)則調(diào)整統(tǒng)計(jì)式 自

7、調(diào)優(yōu)分配直播地址云管理中心主播 推流接流源站CON 分發(fā)網(wǎng)絡(luò) ICON 分發(fā)網(wǎng)絡(luò) II自研分發(fā)網(wǎng)絡(luò)拉流拉流觀眾觀眾解 析 推 流 地 址獲取推流地址列表解析拉流地址實(shí)踐過(guò)程 3(未來(lái) 下行邊緣優(yōu)化)拉流觀眾自研邊緣服務(wù)拉流觀眾拉流觀眾自研邊緣服務(wù)GSLB云調(diào)度中心實(shí)踐小結(jié)1.目標(biāo)明確。網(wǎng)絡(luò)構(gòu)建，以降卡頓率為核心目標(biāo)。2.尋找關(guān)鍵點(diǎn)，以最小代價(jià)解決瓶頸。3.面對(duì)線上產(chǎn)品，分發(fā)網(wǎng)絡(luò)構(gòu)建 / 優(yōu)化必須分步走，不能踱而就。4.初期可采用傳統(tǒng)方案，但極致化必須自建。案例數(shù)據(jù)分析 1：指標(biāo)定義一分鐘卡頓率以秒為單位，連續(xù)兩秒播放器解馬 緩存為空，則記為該分鐘直播卡頓。一分鐘卡頓率直播卡頓分鐘 / 總直播分鐘實(shí)時(shí)卡頓率以秒為單位，該秒內(nèi)播放器解馬緩 存為空次，則記為該秒直播卡頓。實(shí)時(shí)卡頓率直播卡頓秒數(shù) / 總直播秒數(shù)指標(biāo)選擇一分鐘卡頓率，更加嚴(yán)格，更能反映用戶觀看體驗(yàn)。案例數(shù)據(jù)分析 2：卡頓率比較3.00%0.00%6.00%12.00%9.00%1日2日3日4日5日6日7日8日9日10日11日12日13日14日X 月 單 CON Y 月 多 CON Z月融合 CON案例數(shù)據(jù)分析 3：卡頓率優(yōu)化3069單 CON多 CON融合 CON下降 26%12maxavgmin下降 44%案例啟示1.對(duì)