如何保障一場千萬級大型直播？

導讀：TFBOYS「日光旅行」七週年演唱會近日成功舉辦，最高同時在線人數達78.6萬，口碑票房雙豐收。網易雲信的大型直播解決方案全程支撐了網易雲音樂的這場活動，本篇文章將和你們分享這場穩定、流暢、清晰的線上演唱會背後的故事。

文｜ 費曼

網易智企服務端開發工程師

8月22日，TFBOYS「日光旅行」七週年演唱會在網易雲音樂平臺上與廣大粉絲們見面。據官方數據顯示，這場演唱會最高同時在線人數達78.6萬，打破線上付費演唱會世界記錄，取得了口碑票房的雙豐收。

這次演唱會採用了在線實時互動及演唱會現場的多場景導播切換，提供了主機位和三個藝人專屬機位流，同時每一個機位流實時轉碼四個清晰度檔位，用戶能夠根據喜愛選擇本身想看的內容。

網易雲信的大型直播解決方案，全程支撐了網易雲音樂這場活動，今天咱們來聊聊一場穩定、流暢、清晰的線上演唱會背後的故事。

大型直播架構

上圖是這次TFBOYS在線演唱會的直播媒體架構簡圖，能夠看出一場大型活動直播涵蓋的技術方案點很是龐雜，這裏咱們先以推拉流鏈路、全局智能調度、流量精準調度以及單元化部署，對網易雲信的大型直播方案作一個展開介紹。

推拉流鏈路

網易雲信的大型直播技術架構，分爲幾大部分：

• 視頻直播中心（LMS, Live Manage Service），負責直播流的邏輯管理和操做控制，包括存儲和下發實時轉碼、加密等媒體處理的配置信息。
• 實時互動直播服務，由連麥互動和直播兩部分組成，主播和連麥者的音視頻數據在互動直播高性能服務器合成爲一道流後推流到直播流媒體服務器。
• 直播源站服務（LSS, Live Source Service），網易雲信自建的直播流媒體服務器節點，結合全局智能調度系統，提供第一千米的最佳鏈路選擇，同時融合支持接入多家CDN廠商。
• 媒體處理服務（MPS, Media Processing Service），提供實時水印、實時轉碼、媒體數據加密等強大的流媒體處理能力。
• 融合CDN與全局智能調度(GSLB, Golabal Server Load Balancing)，提供敏捷智能的CDN調度策略和分配算法，結合全鏈路、端到端的流媒體控制，來達到最終端側優良的用戶體驗。

• 客戶端SDK，提供推流、拉流以及上下行的調度能力，便於用戶快速接入使用網易雲信平臺一站式的音視頻解決方案。

  融合CDN與智能調度

網易雲信提供的是一個端到端的服務，經過平臺的SDK執行一個相似HTTPDNS的調度，來作到真正根據用戶IP作就近的接入。針對國內相對複雜的運營商網絡環境，雲信在直播上行方面經過BGP網絡以及與相關運營商在網絡接入方面的合做，可以更加精準地控制網絡鏈路的選擇。而對於下行，網易雲信也提供了播放端的SDK接入，經過端到端的調度策略就近選擇合適的下行鏈路。

調度的準確性以及最終效果，依賴及時準確的數據支撐。咱們有一個全鏈路、立體的數據監控體系，一方面利用CDN上的一些實時日誌，另外一方面結合自建節點、客戶端側上報收集鏈路上探測的數據，而後整合作一個實時計算來支撐整個調度的策略。

融合CDN方案，經過調度、監控、高可用等技術和手段來解決CDN網絡方面的問題，可是對於雲信平臺上的用戶，就和在使用一個傳統的CDN網絡同樣沒有大的差別，這些技術細節對用戶透明無感知，用戶經過簡單易用的接入sdk，就具有了高可用、全鏈路控制的流媒體分發服務。

流量精準調度

大型演唱會直播活動，尤爲是正式開播時的進場階段，突發流量峯值會很是高，這就須要實時精準的智能調度策略。雲信融合cdn的智能調度包含兩大部分：CDN分配調度和節點調度。

節點調度，比較常見的是DNS協議解析調度和IP調度（302/HTTPDNS），前者因爲DNS協議緣由，調度生效時間較慢，然後者則能夠作到請求級別的調度，也就是支持任意比例的負載均衡，更加及時精準。在雲信智能調度的場景裏，正常狀況下會遵循IP調度，在IP調度解析失敗時，客戶端上會啓動loacl DNS解析邏輯，二者的結合確保了調度的精準和穩定可靠。

Don't put all your eggs in one basket.

永遠不要將雞蛋放在同一個籃子裏，從風險管控的角度來講，大型活動保障的CDN廠商資源，一般無法經過一家CDN資源進行知足。網易雲信的融合CDN方案則是將多家CDN廠商進行整合與流量分配調度。一般在一次大型直播中，多家CDN廠商提供的容量（區域帶寬、最高帶寬）、質量會各不相同。咱們的目標則是經過動態調整調度比例，在確保不超過最大帶寬的前提下，精確化按比例分配流量，以及儘量地確保體驗。

咱們設計了一套針對CDN廠商的打分算法，影響因子包含當前帶寬、保底帶寬、最大帶寬、帶寬預測、帶寬質量，算法遵循如下原則：

• 沒超保底的帶寬，比超過保底的帶寬，得分更高
• 沒超保底的時候，剩餘保底和剩餘總帶寬越大，得分更高
• 超過保底的時候，剩餘總帶寬越大、質量越好，得分更高

各CDN的分數之比決定了調度比例，CDN打分算法是在持續地迭代更新計算，最大化分配使用各家CDN的帶寬，而後再分配各家CDN廠商的保障以外的資源，同時優先選擇質量較好的廠家，避免單價CDN廠商超分配。

單元化部署

上文所說，在大型直播活動中，短期大量涌入的用戶請求，對以全局智能調度服務爲主的相關非媒體流鏈路應用，也提出了更高的併發處理挑戰。除了上行的推流鏈路咱們作了主備兩個單元的部署，非媒體數據鏈路上的服務咱們也採用了單元化的部署方案。

在此部署方案下，可用性作到任意單元機房故障，不影響總體可用性，即異地多活。單元化部署遵循如下原則：

• 單元化的依賴也必須單元化（核心業務）
• 單元化粒度爲應用，非api
• 單元化技術棧對應用盡可能避免產生侵入性

如上圖所示，非單元化的業務部署在主機房，單元化的業務則部署在主機房和單元機房。

穩定性與安全性的保障

上行鏈路穩定

超大型直播方案最核心的訴求就是直播穩定性，下面咱們將以這次在線演唱會爲案例，重點闡述一下網易雲信大型直播的全鏈路穩定性架構。

上圖是雲信大型直播的媒體流鏈路示意簡圖，總體方案能夠承受任何單節點、單線路、單機房網絡出口的故障。如直播源站部分，採用了多線策略收流，包含機房專線和4G揹包方案，一主一備兩個線路。同時每一個單元的源站集羣都有4層負載均衡，一臺機器宕機不會影響總體可用性。LMS、LSS、MPS都是跨機房部署，全部服務模塊均可配置專有資源池供使用，保證不會受其餘租戶影響。

整個推流鏈路採用雙路熱流，互爲主備，且部署上是互相獨立的兩個單元，能作到支持Rack級別的故障災備。雙路熱流實現了自動主備切換，端上無需專門添加應用層的線路切換邏輯。當任何一個鏈路出現問題的時候，觀衆的直播流不會受到影響，端上平均卡頓感知時間在1s之內。

除了推流鏈路的總體主備單元容災，每一個單元的服務自己也會有容災手段。好比UPS接入，能夠接受30min的供電故障，好比當實時互動流出現問題時，導播臺會推墊片流以保證鏈路數據不中斷。

下行鏈路穩定

在這次活動中，全局智能調度服務會承受較大的峯值壓力，在單元化部署的基礎上，咱們通過了多輪壓測和性能調優，模型上能夠支撐千萬級用戶在半分鐘內所有進入直播間。

除了上述關於推流鏈路的高可用，下行鏈路也有相關的容災策略。當GSLB智能調度服務總體不可用，咱們在客戶端SDK預埋了融合CDN的local DNS災備邏輯與比例配置，將雲端的全局智能調度fail-over到客戶端的本地兜底調度，並保持大數據統計層面的各CDN廠商的流量分配均衡。

同時，客戶端也會有播放體驗方面的容災策略，諸如清晰度降級、線路調整等。

直播內容安全

固然，除了直播全鏈路的穩定以外，直播安全也十分重要。這次活動中，網易雲信爲TFBOYS活動鏈路多環節都提供了安全保障機制，如防盜鏈鑑權、IP黑白名單、HTTPS等能力，以及地區、運營商等下行調度的動態限制，實現全鏈路安全保障。

在此基礎上，這次活動採用了端到端的視頻流數據加密，直播場景的加密有幾點基本要求：壓縮比不變、實時性和低計算複雜度。除此以外，在融合多cdn的方案背景下，視頻流的加密必須考慮到CDN廠商的兼容性，好比須知足如下要求：不破壞流媒體協議格式、視頻容器格式；metadata/video/audio tag的header部分不加密；對於avcSequenceHeader和aacSequenceHeader tag總體不加密。具體加密算法，能夠採用一些流式加密算法，這裏咱們再也不贅述。

**監控報警與預案
**

一場大型直播將會有大量的計算節點參與，除了媒體數據處理與分發的各個服務器節點，還有分佈在國內外的海量客戶端，咱們對網絡鏈路、服務節點、設備端的健康與質量感知，都離不開數據監控系統。同時，咱們在現有系統沒法自動fail-over的故障場景下，須要人工預案介入，然後者的決策判斷，也強依賴於完善的全鏈路數據質量監控與報警系統。

全鏈路監控

整個直播鏈路的監控包含了上行推流鏈路的流質量、媒體流實時轉碼處理、端上播放質量、智能調度系統的可用性、業務量水位等相關監控數據。上行鏈路常見的QoS指標有幀率、碼率、RTT等，其維度包含主備線路、出口運營商、CDN廠商節點等。端上的QoS指標則包含了拉流成功率、首幀時長、卡頓率、httpdns緩存命中率，維度則覆蓋包含CDN廠商、國家、省份、運營商、直播流、清晰度檔位、客戶端等。

這次直播中，內容上支持了多種機位流以及多個清晰度的轉碼輸出流，同時經過多個CDN廠商進行分發，咱們把上行鏈路中節點的碼率、幀率，直觀地經過N個指標卡集中展現在單個大盤頁面上，而且經過增長預警值進行異常顯示和彈窗消息告警。活動做戰室現場，咱們採用了多個大屏展現，很是直觀地展示當前主備雙推流鏈路的實時幀率、碼率等狀況，爲現場地指揮保障提供了強大的數據決策支撐。

如下圖爲例：藍色表示上行幀率，綠色表示正常的上行碼率，紅色表示碼率值太低，N/A表示當前沒有上行推流數據。

而在下行播放鏈路中，比較經常使用的指標就是卡頓率。下面是咱們對卡頓相關的描述：

• 一次卡頓：播放器持續2s發生緩衝區空，即播放器2s沒有拉到流
• 一分鐘用戶卡頓：1分鐘窗口內，用戶只要卡頓一次，則該用戶計做卡頓用戶
• 一分鐘用戶卡頓率：1分鐘窗口內，卡頓用戶數/總的用戶數
• 一分鐘用戶零卡頓率：1分鐘窗口內，(總的用戶數 - 卡頓用戶數)/總的用戶數

爲何會選擇用戶卡頓率這個指標呢，而不是使用總體的卡頓採樣點/總採樣數呢？是由於咱們更想看到有多少用戶沒有出現過卡頓現象，這更能直觀體現優質網絡的總體佔比。經過對各省份用戶零卡頓率、用戶數排行，以及各省用戶卡頓率的觀察，咱們能夠很是直觀地找到卡頓嚴重的地區，以便重點關注，進行資源調度優化。

直播應急預案

Hardware faults，software bugs， and operator errors， such failures are a fact of life：not a problem that will someday be solved once and for all， but a reality that we must live with.

Armando Fox.2002.Torward Recovery-Oriented Computing. VLDB 2002.

任何一個系統，不管你號稱它被設計得多麼健壯，它仍然會有故障時間的存在。硬件故障、軟件bug、人爲操做失誤等等，這些都無可避免地存在着，他們未必是一個必須多少時間內將其完全解決的問題，他們是咱們必須認清並接受共存的一個事實。

因此，預案管理是大型直播活動保障中不可缺乏的一環，咱們遵循如下的預案原則：

1. 預案信息明確：大盤自動監控不具有二義性，確保預案信息來源正確，觸發執行預案的條件明確且有數值化約束。
2. 預案操做簡潔：全部的預案操做都有有簡潔明確(開關型)的操做輸入。
3. 預案操做安全：全部預案要通過充分預演，同時預演操做自己須要有明確的確認機制，以確保在正常狀況下不會被誤觸發。
4. 預案影響：明確理清預案操做的影響，QA在預演階段須要對相關影響進行充分驗證。

這次活動的前期籌備中，咱們總計進行了3次直播全鏈路的擬真演練，以及2次聯合互動現場、導播臺現場的活動全流程級別的彩排，另外進行了大大小小總計數十次的各種風險預案演練。全部演練過程當中發現的問題，都會進行專項解決。

風險預案這塊，包含了各種資源故障、上下行鏈路質量、地區性網絡故障、CDN異常流量水位等在內的場景應對，其中資源故障包含了機器宕機、機架總體斷電、堆疊交換機宕機、機房外網出口不可用，咱們均進行了風險預案演練覆蓋。下面列舉幾點網易雲信大型直播解決方案中的部分預案機制：

• 若是由於誤操做等致使非正常解密等，網易雲信可在推流不中斷的狀況下，動態停止流加密，客戶端無任何感知影響。
• 某家cdn在某地區運營商出現大面積故障癱瘓，該地區相應運營商線路的QoS指標會大幅度降低並觸發報警，網易雲信將故障cdn在該地區運營商進行黑名單處理，動態中止對其的調度，將流量調度至正常提供服務的cdn廠商。
• 在兩路熱流均正常的狀況下，可是正在分發的一路出現質量問題，方案可支持手動觸發主備切換，讓監控數據質量更好的另外一路流參與分發，客戶端感知時間在1s之內。
• 由於一些不可抗因素，某機房出現大面積故障總體不可用，觸發鏈路報警，此時咱們會緊急將流切至另外一機房，故障感知與恢復的時間在一分鐘內。

結    語

依靠網易雲信的千萬級大型直播方案，這次活動圓滿完成，總體推流鏈路可靠穩定，下行流量分配合理，相關故障預案完整充分並真實發揮做用。乾貨萬千，紙短情長，點擊【閱讀原文】便可諮詢網易雲信大型直播方案，瞭解更多技術細節。

做者介紹

費曼，網易智企服務端開發工程師。碩士畢業於華中科技大學電信系，2016年加入網易雲信，熱衷於大規模分佈式系統和音視頻相關技術，愛好文學、體育和電影。

*各渠道文章轉載需註明來源及做者