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