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