大家好，我叫薛寧，非常榮幸能參加今天的會(huì)議。我目前就職于映客，主要負(fù)責(zé)映客直播CDN調(diào)度和服務(wù)器優(yōu)化方面的工作，我今天主要和大家分享下映客直播在調(diào)度方面的一些實(shí)踐經(jīng)驗(yàn)。
今天的分享將從以下3個(gè)方面進(jìn)行展開(kāi)
直播與CDN
CDN的全稱(chēng)為內(nèi)容分發(fā)網(wǎng)絡(luò)，主要用來(lái)解決由于網(wǎng)絡(luò)帶寬小、用戶(hù)訪(fǎng)問(wèn)量大、網(wǎng)點(diǎn)分布不均勻等導(dǎo)致用戶(hù)訪(fǎng)問(wèn)網(wǎng)站速度慢的問(wèn)題。其實(shí)現(xiàn)是通過(guò)在現(xiàn)有的網(wǎng)絡(luò)中，增加一層新的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)站的內(nèi)容發(fā)布到離用戶(hù)最近的網(wǎng)絡(luò)節(jié)點(diǎn)上，這樣用戶(hù)可以就近獲取所需的內(nèi)容，解決網(wǎng)絡(luò)擁塞、訪(fǎng)問(wèn)延遲高的問(wèn)題，提升用戶(hù)體驗(yàn)。目前映客的直播系統(tǒng)也是基于cdn構(gòu)建?！ ?/span>
經(jīng)典使用場(chǎng)景如圖所示，內(nèi)容提供商通過(guò)主動(dòng)預(yù)熱或者被動(dòng)更新的方式，把內(nèi)容緩存在CDN上，當(dāng)用戶(hù)訪(fǎng)問(wèn)資源時(shí)，從就近CDN節(jié)點(diǎn)上獲取到所需資源，平常大家瀏覽網(wǎng)頁(yè)和和觀(guān)看網(wǎng)絡(luò)視頻資源，大部分都是通過(guò)以這種方式。
直播CDN與通常的CDN使用方式上稍微有點(diǎn)不同，主播開(kāi)始進(jìn)行直播，向智能DNS發(fā)送解析請(qǐng)求； 智能DNS返回最優(yōu)CDN節(jié)點(diǎn)IP地址； 主播端采集音視頻數(shù)據(jù)，發(fā)送給CDN節(jié)點(diǎn)，CDN節(jié)點(diǎn)進(jìn)行緩存等處理； 觀(guān)眾端要觀(guān)看此主播的視頻，向智能DNS發(fā)送解析請(qǐng)求； 智能DNS返回最優(yōu)CDN節(jié)點(diǎn)IP地址； 觀(guān)眾端向CDN節(jié)點(diǎn)請(qǐng)求音視頻數(shù)據(jù)； CDN節(jié)點(diǎn)通過(guò)內(nèi)部網(wǎng)絡(luò)同步其他節(jié)點(diǎn)的音視頻數(shù)據(jù)；之后將音視頻數(shù)據(jù)發(fā)送給觀(guān)眾端；
可以看出移動(dòng)直播的交互過(guò)程比傳統(tǒng)CDN更為復(fù)雜一些，在視頻內(nèi)容上也更具實(shí)時(shí)性，對(duì)延遲非常敏感，CDN內(nèi)部并不能做太長(zhǎng)時(shí)間的內(nèi)容緩存。主播方上行網(wǎng)絡(luò)到CDN節(jié)點(diǎn)網(wǎng)絡(luò)狀況的不確定性，觀(guān)眾在觀(guān)看視頻過(guò)程中，更容易遇到視頻打不開(kāi)、黑屏、觀(guān)看直播卡頓、延遲大，觀(guān)看直播音畫(huà)不同步、音畫(huà)丟失、花屏等現(xiàn)象。
排除觀(guān)眾和主播網(wǎng)絡(luò)自身問(wèn)題，問(wèn)題更可能出現(xiàn)在與cdn的交互上，直播調(diào)度的目標(biāo)就是在cdn的基礎(chǔ)上來(lái)提升用戶(hù)使用直播的用戶(hù)體驗(yàn)。
映客直播調(diào)度系統(tǒng)
在講訴調(diào)度系統(tǒng)之前，先介紹下映客的流媒體場(chǎng)景，這是映客目前的流媒體的系統(tǒng)組成框圖。
主播發(fā)起視頻直播后，會(huì)選取一個(gè)CDN或私有媒體云作為推流方式，把采集的視頻數(shù)據(jù)推到CDN上，為保證整個(gè)系統(tǒng)的穩(wěn)定性，我們使用多家cdn，在CDN與CDN會(huì)做視頻互推，映客為支持視頻審核和視頻錄播等功能會(huì)拉一路流到映客服務(wù)器內(nèi)部。普通cdn比較難以支持更低延遲的視頻直播比如連麥互動(dòng)，所以我們內(nèi)部也建立了私有媒體云，用于支持更低延遲的視頻直播。
在當(dāng)前的媒體系統(tǒng)基礎(chǔ)上，我們?cè)O(shè)計(jì)了cdn調(diào)度系統(tǒng)，整個(gè)系統(tǒng)由日志收集平臺(tái)、直播調(diào)度平臺(tái)、數(shù)據(jù)監(jiān)控平臺(tái)、日志處理平臺(tái)4個(gè)部分組成，整個(gè)系統(tǒng)中日志占了比較大的比重，我們整個(gè)系統(tǒng)以正是以日志數(shù)據(jù)為驅(qū)動(dòng)的。
日志收集系統(tǒng)對(duì)整個(gè)媒體系統(tǒng)做全鏈路的日志數(shù)據(jù)收集，包括端上的日志、CDN日志、媒體中心日志、媒體云日志。
端上的日志由客戶(hù)端或者網(wǎng)頁(yè)端上報(bào)到埋點(diǎn)服務(wù)器，這一部分日志也是我們整個(gè)日志收集系統(tǒng)最重要的一部分，為保障客戶(hù)端的日志能穩(wěn)定上報(bào)，我們把日志系統(tǒng)部署在多個(gè)多線(xiàn)的BGP機(jī)房、同時(shí)在客戶(hù)端層面也做了比較多的上報(bào)容錯(cuò)機(jī)制，端上的日志收集包含開(kāi)停播事件、卡頓、速率、延遲等相關(guān)的數(shù)據(jù)。
CDN日志由CDN廠(chǎng)商的提供，日志收集平臺(tái)會(huì)通過(guò)輪詢(xún)方式去CDN平臺(tái)拉取，這部分?jǐn)?shù)據(jù)包含當(dāng)前在CDN上直播數(shù)、每路直播的上行速率、幀率、視頻數(shù)據(jù)丟棄狀況、流量等相關(guān)數(shù)據(jù)。
媒體云會(huì)實(shí)時(shí)上報(bào)媒體服務(wù)器的數(shù)據(jù)，這部分?jǐn)?shù)據(jù)和端上的日志類(lèi)似包含開(kāi)停播時(shí)間、速率、幀率、延遲等相關(guān)的數(shù)據(jù)。
媒體中心相當(dāng)于客戶(hù)端，會(huì)拉取所有的直播到媒體中心的服務(wù)器上，媒體中心會(huì)采集到每一路直播的下行相關(guān)數(shù)據(jù)匯報(bào)到日志收集系統(tǒng)。
我們通過(guò)日志采集系統(tǒng)獲取到大量的日志，這些日志統(tǒng)一交由內(nèi)部kafka消息隊(duì)列，我們對(duì)收集的日志做了3類(lèi)處理：實(shí)時(shí)分析、準(zhǔn)實(shí)時(shí)分析和大數(shù)據(jù)分析系統(tǒng)
實(shí)時(shí)分析會(huì)實(shí)時(shí)分析統(tǒng)計(jì)每個(gè)主播和用戶(hù)的上下行數(shù)據(jù)，某個(gè)主播或者用戶(hù)出現(xiàn)卡頓了，我們?cè)?0s之內(nèi)就能知道，針對(duì)這種情況，可以馬上就能夠通知實(shí)時(shí)調(diào)度平臺(tái)采取策略。實(shí)時(shí)分析系統(tǒng)從實(shí)現(xiàn)和執(zhí)行方式上全部采用基于內(nèi)存的計(jì)算模型實(shí)現(xiàn)。
第二類(lèi)數(shù)據(jù)通過(guò)開(kāi)源的elasticsearch實(shí)現(xiàn)，端上和媒體中心日志在經(jīng)過(guò)格式化和數(shù)據(jù)提取后會(huì)準(zhǔn)實(shí)時(shí)存儲(chǔ)到ES中，ES本身也即是一個(gè)存儲(chǔ)系統(tǒng)也是一個(gè)搜索引擎，調(diào)度系統(tǒng)的監(jiān)控平臺(tái)會(huì)會(huì)從ES里面讀取處理后的數(shù)據(jù)做一些粗粒度的監(jiān)控，比如當(dāng)前多少用戶(hù)有推流日志等，ES的主要功能是提供日志檢索功能，通過(guò)ES可以很快的查到某個(gè)用戶(hù)的實(shí)時(shí)推拉流情況。
最后一類(lèi)數(shù)據(jù)是借用大數(shù)據(jù)部門(mén)的spark-hive集群做數(shù)據(jù)處理，hive集群提供原始日志存儲(chǔ)，可以服務(wù)于內(nèi)部數(shù)據(jù)分析和報(bào)表系統(tǒng)，也支持詳細(xì)的日志檢索功能；spark會(huì)對(duì)數(shù)據(jù)按照一定的指標(biāo)和維度做基于時(shí)間窗口的聚合，聚合后的數(shù)據(jù)輸出到報(bào)警中心。
spark做聚合計(jì)算的時(shí)候分別從主播和觀(guān)眾方主做5個(gè)維度的指標(biāo)分析。拉流端卡頓率、首幀時(shí)間、播放延遲、成功率、有效內(nèi)容比，卡頓率定義為用戶(hù)的卡頓的時(shí)間比例用來(lái)衡量觀(guān)眾觀(guān)看直播的流暢度；首幀時(shí)間也即從打開(kāi)直播看到的第一個(gè)視頻畫(huà)面消耗的時(shí)間，如果時(shí)間小于1秒大家經(jīng)常說(shuō)的秒開(kāi)，用來(lái)衡量加載時(shí)間；播放延遲是指觀(guān)眾方觀(guān)看到畫(huà)面與主播產(chǎn)生的畫(huà)面之間的延遲時(shí)間，用來(lái)衡量CDN分發(fā)過(guò)程中產(chǎn)生的延遲；成功率也即播放直播的成功率，定義為若干秒沒(méi)有看到畫(huà)面的的比例；有效內(nèi)容比定義為用戶(hù)觀(guān)看到的直播與播放時(shí)間的比例，由于卡頓或者其他因素，視頻在播放過(guò)程中會(huì)出現(xiàn)視頻幀丟棄等現(xiàn)象，這個(gè)指標(biāo)用來(lái)衡量丟棄的比例。推流端成功率、有效內(nèi)容比、編碼速率、網(wǎng)絡(luò)速率和失敗時(shí)長(zhǎng)，成功率和有效內(nèi)容比和觀(guān)看方的類(lèi)似，網(wǎng)絡(luò)速率直接反映了主播的網(wǎng)絡(luò)速率，由于播放器的碼率自適應(yīng)，我們加入了編碼速率來(lái)作為網(wǎng)絡(luò)速率的參考值，失敗時(shí)長(zhǎng)定義為推流失敗的時(shí)間可以直接反應(yīng)出主播推流的失敗影響的時(shí)間。
基于這些指標(biāo)，我們對(duì)數(shù)據(jù)做多維度聚合統(tǒng)計(jì)，全網(wǎng)維度、CDN廠(chǎng)商維度比較好理解，由于映客同時(shí)直播并發(fā)量比較大，單家CDN的單域名難以承載并發(fā)的直播數(shù)量，我們?cè)谝患褻DN也會(huì)存在使用多個(gè)域名。
此外我們還會(huì)以CDN的節(jié)點(diǎn)的維度做數(shù)據(jù)統(tǒng)計(jì)，有時(shí)CDN是好的，可能某些節(jié)點(diǎn)有故障；映客除了普通直播還會(huì)有游戲直播合作廠(chǎng)商的直播，直播類(lèi)型也是我們聚合的一個(gè)維度。有時(shí)候有一些大型合作活動(dòng)，我們會(huì)對(duì)這些房間做特殊的數(shù)據(jù)聚合；
我們經(jīng)常會(huì)遇到一些與設(shè)備類(lèi)型相關(guān)的故障，同一app在不同機(jī)型上可能存在不同的表現(xiàn)，我們對(duì)設(shè)備類(lèi)型也做了聚合統(tǒng)計(jì)。
地區(qū)+運(yùn)營(yíng)商作為業(yè)內(nèi)衡量cdn的數(shù)據(jù)必備的維度，這兩個(gè)維度也是我們的數(shù)據(jù)聚合的一個(gè)點(diǎn)。
基于各個(gè)維度的數(shù)據(jù)，我們做了一套監(jiān)控報(bào)警的可視化系統(tǒng)，監(jiān)控指標(biāo)有很多項(xiàng)，這里主要列出重要的幾點(diǎn)，監(jiān)控的指標(biāo)會(huì)從上面的多個(gè)維度上做統(tǒng)計(jì)，卡頓率定義為：當(dāng)前維度下出現(xiàn)卡頓的人數(shù)除以當(dāng)前維度下總?cè)藬?shù)，失敗率定義類(lèi)似為打開(kāi)失敗的人數(shù)除以打開(kāi)直播的人數(shù)，這兩個(gè)指標(biāo)直接衡量了當(dāng)前維度故障的影響范圍；流媒體系統(tǒng)錯(cuò)誤了定義為流媒體中心拉流的失敗率，這個(gè)從一定程度上反映了直播的穩(wěn)定性；平均首屏?xí)r間，直接反應(yīng)了觀(guān)眾打開(kāi)直播觀(guān)看到內(nèi)容的速度，從一定程度上反映出了cdn的調(diào)度的準(zhǔn)確性；我們對(duì)各個(gè)維度的流量和并發(fā)推流數(shù)也會(huì)做監(jiān)控，通過(guò)流量與推流數(shù)的對(duì)比關(guān)系，可以比較直觀(guān)的看出當(dāng)前cdn上觀(guān)眾有沒(méi)有出現(xiàn)明顯的故障，比如某個(gè)地區(qū)流量突然下跌，這個(gè)地區(qū)的cdn節(jié)點(diǎn)可能存在異常。
對(duì)于這些監(jiān)控指標(biāo)，我們做了不同的報(bào)警策略，：對(duì)于質(zhì)量我們衡量質(zhì)量的波動(dòng)性，比如首屏?xí)r間是否出現(xiàn)了比較大的波動(dòng)；對(duì)流量和直播數(shù)量我們做同比環(huán)比策略，比如此時(shí)昨天1000并發(fā)，今天600，同時(shí)直播量突然從1000降到800肯定，肯定是那里出現(xiàn)了故障；我們對(duì)于活動(dòng)的特殊直播間做有白名單的監(jiān)控，對(duì)活動(dòng)的白名單房間做特殊的監(jiān)控策略；有時(shí)我們發(fā)現(xiàn)故障可能來(lái)自?xún)?nèi)部的開(kāi)播或者觀(guān)看服務(wù)，我們開(kāi)播次數(shù)和播放次數(shù)的同比波動(dòng)。
當(dāng)報(bào)警或者異常產(chǎn)生時(shí)，我們需要將異常轉(zhuǎn)移走，我們?cè)O(shè)計(jì)了全平臺(tái)的地址調(diào)度系統(tǒng)，調(diào)度平臺(tái)由地址分配系統(tǒng)、策略管理系統(tǒng)、配置系統(tǒng)組成。調(diào)度平臺(tái)對(duì)整個(gè) 開(kāi)播、觀(guān)看和媒體處理的地址做統(tǒng)一分配，cdn的地址統(tǒng)一由地址分配系統(tǒng)分配，帶來(lái)的好處時(shí)域名管理是收攏的，新增刪除或者配置不同比重是很方便的統(tǒng)一處理；策略管理系統(tǒng)管理地址和策略的關(guān)系，配置平臺(tái)管理用戶(hù)或者地區(qū)對(duì)應(yīng)的策略關(guān)系。如果我們要接入一家cdn，只需在策略管理系統(tǒng)增加一條地址規(guī)則，通過(guò)配置平臺(tái)分配用戶(hù)。
調(diào)度模塊最核心的模塊是調(diào)度策略，我們的調(diào)度策略有常見(jiàn)的基于用戶(hù)出口IP位置的調(diào)度策略，會(huì)針對(duì)用戶(hù)的出口IP選擇一個(gè)最優(yōu)的接入方式；用戶(hù)在觀(guān)看或者直播過(guò)程中，如果效果不理想，會(huì)在運(yùn)行的過(guò)程中不中斷的訪(fǎng)問(wèn)調(diào)度服務(wù)器獲得一個(gè)備選的地址；有些用戶(hù)通過(guò)IP策略調(diào)度效果始終不滿(mǎn)意，我們會(huì)基于之前的歷史數(shù)據(jù)對(duì)用戶(hù)的IP調(diào)度策略做再次糾錯(cuò)；在IP調(diào)度使用過(guò)程中，會(huì)經(jīng)常發(fā)現(xiàn)ip庫(kù)給的地理位置是不準(zhǔn)確的，我們結(jié)合用戶(hù)的gps數(shù)據(jù)對(duì)IP的位置數(shù)據(jù)做再次糾錯(cuò)這個(gè)是基于第三方服務(wù)實(shí)現(xiàn)；如果用戶(hù)對(duì)多個(gè)cdn的效果都不理想，我們會(huì)適當(dāng)分配媒體云的資源給用戶(hù)嘗試，我們的私有媒體服務(wù)器都部署在bgp機(jī)房，連通性要比普通機(jī)房更好。
盡管我們有多種調(diào)度策略，有時(shí)候任然會(huì)遇到一些用戶(hù)個(gè)例，一些用戶(hù)會(huì)在線(xiàn)反饋，這類(lèi)用戶(hù)都期望能快速的解決當(dāng)期那問(wèn)題，這種情況下需要一個(gè)很方便定位問(wèn)題的平臺(tái)，基于調(diào)度平臺(tái)的全鏈路日志收集功能，我們專(zhuān)門(mén)做了一個(gè)工具，即使是客服或者運(yùn)維的同事可以很方便定位到用戶(hù)故障原因。
目前調(diào)度在映客內(nèi)部使用支撐起了直播監(jiān)控、質(zhì)量?jī)?yōu)化、故障定位、流量調(diào)度、音視頻優(yōu)化以及成本核算工作。通過(guò)調(diào)度系統(tǒng)的報(bào)表監(jiān)控系統(tǒng)可以發(fā)現(xiàn)直播系統(tǒng)中潛在的異常問(wèn)題，為cdn的優(yōu)化提供指導(dǎo)方向，調(diào)度系統(tǒng)提供的各個(gè)組件也在持續(xù)幫助QA和音視頻團(tuán)隊(duì)提升工作效率。
調(diào)度系統(tǒng)未來(lái)
我們的調(diào)度系統(tǒng)做了很多工作，但是有很多地方還不是很完善，我們也正在做下面的一些工作：
調(diào)度系統(tǒng)目前還是事后調(diào)度，異常發(fā)生到故障處理的延時(shí)還是比較大，我們正在做一套全網(wǎng)撥測(cè)的系統(tǒng)，通過(guò)全網(wǎng)撥測(cè)，提前感知到CDN系統(tǒng)的故障，當(dāng)用戶(hù)訪(fǎng)問(wèn)的時(shí)候提前轉(zhuǎn)移
私有媒體云現(xiàn)在承載這映客的一部分核心功能，私有媒體云采用的是私有協(xié)議，目前運(yùn)行上發(fā)現(xiàn)有些網(wǎng)絡(luò)與私有媒體云的有連接不通的狀況，需要對(duì)私有媒體云的鏈路再做優(yōu)化。
目前調(diào)度平臺(tái)僅僅依靠人力調(diào)度，在這一點(diǎn)上需要做一套智能調(diào)度系統(tǒng)，主動(dòng)發(fā)現(xiàn)問(wèn)題主動(dòng)切換。
微信掃一掃
