本文由網易雲信技術團隊分享，原題“如何保障一場千萬級大型直播？”，有修訂和改動。
1、引言
本文以TFBOYS“日光旅行”七週年這場直播演唱會為案例，為你分享大型直播系統後端架構設計的方方面面，包括：基本架構、穩定性保障、安全性障、監控報警、應急預案等技術範疇。
案例中的這次演唱會採用了線上實時互動及演唱會現場的多場景導播切換，提供了主機位和三個藝人專屬機位流，同時每個機位流實時轉碼四個清晰度檔位，使用者可以根據喜好選擇自己想看的內容。這場演唱會最高同時線上人數達78.6萬，打破線上付費演唱會世界記錄。
學習交流：
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
- 開源IM框架原始碼：https://github.com/JackJiang2...
（本文同步釋出於：http://www.52im.net/thread-38...）
2、本文作者
費曼：網易智企服務端開發工程師。碩士畢業於華中科技大學電信系，2016年加入網易雲信，熱衷於大規模分散式系統和音視訊相關技術，愛好文學、體育和電影。
3、架構方面
3.1 基本
上圖是該次TFBOYS線上演唱會的直播媒體架構簡圖。
可以看出一場大型活動直播涵蓋的技術方案點非常龐雜，本節接下來的內容我們將以推拉流鏈路、全域性智慧排程、流量精準排程以及單元化部署，對這套直播方案做一個展開介紹。
3.2 推拉流鏈路
如上圖所示，直播技術架構，分為幾大部分：
1）視訊直播中心（LMS——Live Manage Service）：負責直播流的邏輯管理和操作控制，包括儲存和下發實時轉碼、加密等媒體處理的配置資訊；
2）實時互動直播服：由連麥互動和直播兩部分組成，主播和連麥者的音視訊資料在互動直播高效能伺服器合成為一道流後推流到直播流媒體伺服器；
3）直播源站服務（LSS——Live Source Service）：網易雲信自建的直播流媒體伺服器節點，結合全域性智慧排程系統，提供第一公里的最佳鏈路選擇，同時融合支援接入多家CDN廠商；
4）媒體處理服務（MPS——Media Processing Service）：提供實時水印、實時轉碼、媒體資料加密等強大的流媒體處理能力；
5）融合CDN與全域性智慧排程（GSLB——Golabal Server Load Balancing）：提供敏捷智慧的CDN排程策略和分配演算法，結合全鏈路、端到端的流媒體控制，來達到最終端側優良的使用者體驗；
6）客戶端SDK：提供推流、拉流以及上下行的排程能力，便於使用者快速接入使用網易雲信平臺一站式的音視訊解決方案。
3.3 融合CDN與智慧排程
這是一個端到端的服務，通過平臺的SDK執行一個類似HTTPDNS的排程，來做到真正根據使用者IP做就近的接入。
針對國內相對複雜的運營商網路環境，在直播上行方面通過BGP網路以及與相關運營商在網路接入方面的合作，能夠更加精準地控制網路鏈路的選擇。
而對於下行，也提供了播放端的SDK接入，通過端到端的排程策略就近選擇合適的下行鏈路。
排程的準確性以及最終效果，依賴及時準確的資料支撐。
我們有一個全鏈路、立體的資料監控體系，一方面利用CDN上的一些實時日誌，另一方面結合自建節點、客戶端側上報收集鏈路上探測的資料，然後整合做一個實時計算來支撐整個排程的策略。
融合CDN方案，通過排程、監控、高可用等技術和手段來解決CDN網路方面的問題。但是對於技術人員來說，就和在使用一個傳統的CDN網路一樣沒有大的差異，這些技術細節對技術人員透明無感知。
3.4 流量精準排程
大型演唱會直播活動，尤其是正式開播時的進場階段，突發流量峰值會非常高，這就需要實時精準的智慧排程策略。
融合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廠商的打分演算法：影響因子包含當前頻寬、保底頻寬、最大頻寬、頻寬預測、頻寬質量。
演算法遵循以下原則：
1）沒超保底的頻寬，比超過保底的頻寬，得分更高；
2）沒超保底的時候，剩餘保底和剩餘總頻寬越大，得分更高；
3）超過保底的時候，剩餘總頻寬越大、質量越好，得分更高。
各CDN的分數之比決定了排程比例，CDN打分演算法是在持續地迭代更新計算，最大化分配使用各家CDN的頻寬，然後再分配各家CDN廠商的保障之外的資源。同時優先選擇質量較好的廠家，避免單價CDN廠商超分配。
3.5 單元化部署
上面所說，在大型直播活動中，短時間大量湧入的使用者請求，對以全域性智慧排程服務為主的相關非媒體流鏈路應用，也提出了更高的併發處理挑戰。
除了上行的推流鏈路我們做了主備兩個單元的部署，非媒體資料鏈路上的服務也採用了單元化的部署方案。
在此部署方案下，可用性做到任意單元機房故障，不影響整體可用性，即異地多活。
單元化部署遵循以下原則：
1）單元化的依賴也必須單元化（核心業務）；
2）單元化粒度為應用，非api；
3）單元化技術棧對應用盡量避免產生侵入性。
如上圖所示：非單元化的業務部署在主機房，單元化的業務則部署在主機房和單元機房。
4、穩定性保障
4.1 上行鏈路穩定
超大型直播方案最核心的訴求就是直播穩定性，下面我們將以該次線上演唱會為案例，重點闡述一下直播的全鏈路穩定性架構。
上圖是我們直播的媒體流鏈路示意簡圖：整體方案可以承受任何單節點、單線路、單機房網路出口的故障。
如直播源站部分：採用了多線策略收流，包含機房專線和4G揹包方案，一主一備兩個線路。同時每個單元的源站叢集都有4層負載均衡，一臺機器當機不會影響整體可用性。LMS、LSS、MPS都是跨機房部署，所有服務模組都可配置專有資源池供使用，保證不會受其他租戶影響。
整個推流鏈路：採用雙路熱流、互為主備，且部署上是互相獨立的兩個單元，能做到支援Rack級別的故障災備。雙路熱流實現了自動主備切換，端上無需專門新增應用層的線路切換邏輯。當任何一個鏈路出現問題的時候，觀眾的直播流不會受到影響，端上平均卡頓感知時間在1s以內。
除了推流鏈路的整體主備單元容災，每個單元的服務本身也會有容災手段。比如UPS接入，可以接受30min的供電故障，比如當實時互動流出現問題時，導播臺會推墊片流以保證鏈路資料不中斷。
4.2 下行鏈路穩定
在訪次直播活動中，全域性智慧排程服務會承受較大的峰值壓力，在單元化部署的基礎上，我們經過多輪壓測和效能調優，模型上可支撐千萬級使用者在半分鐘內全部進入直播間。
除了上述關於推流鏈路的高可用，下行鏈路也有相關的容災策略。當GSLB智慧排程服務整體不可用，在客戶端SDK預埋了融合CDN的local DNS災備邏輯與比例配置，將雲端的全域性智慧排程fail-over到客戶端的本地兜底排程，並保持大資料統計層面的各CDN廠商的流量分配均衡。
同時：客戶端也會有播放體驗方面的容災策略，諸如清晰度降級、線路調整等。
5、安全性保障
除了直播全鏈路的穩定之外，直播安全也很重要。
該次直播活動中，為TFBOYS活動鏈路多環節都提供了安全保障機制（如防盜鏈鑑權、IP黑白名單、HTTPS等能力），以及地區、運營商等下行排程的動態限制，實現全鏈路安全保障。
在此基礎上：此次活動採用了端到端的視訊流資料加密。
直播場景的加密有幾點基本要求：壓縮比不變、實時性和低計算複雜度。
除此之外：在融合多cdn的方案背景下，視訊流的加密必須考慮到CDN廠商的相容性。
比如須滿足以下要求：
1）不破壞流媒體協議格式、視訊容器格式；
2）metadata/video/audio tag的header部分不加密；
3）對於avcSequenceHeader和aacSequenceHeader tag整體不加密。
具體加密演算法，可以採用一些流式加密演算法，這裡我們不再贅述。
6、監控與報警
6.1 概述
一場大型直播將會有大量的計算節點參與，除了媒體資料處理與分發的各個伺服器節點，還有分佈在國內外的海量客戶端。
我們對網路鏈路、服務節點、裝置端的健康與質量感知，都離不開資料監控系統。
同時：我們在現有系統無法自動fail-over的故障場景下，需要人工預案介入，而後者的決策判斷，也強依賴於完善的全鏈路資料質量監控與報警系統。
6.2 全鏈路監控
整個直播鏈路的監控包含了：
1）上行推流鏈路的流質量；
2）媒體流實時轉碼處理；
3）端上播放質量；
4）智慧排程系統的可用性；
5）業務量水位等相關監控資料。
上行鏈路常見的QoS指標有：幀率、位元速率、RTT等，其維度包含主備線路、出口運營商、CDN廠商節點等。
端上的QoS指標則包含了：拉流成功率、首幀時長、卡頓率、httpdns快取命中率，維度則覆蓋包含CDN廠商、國家、省份、運營商、直播流、清晰度檔位、客戶端等。
此次直播中：內容上支援了多種機位流以及多個清晰度的轉碼輸出流，同時通過多個CDN廠商進行分發，我們把上行鏈路中節點的位元速率、幀率，直觀地通過N個指標卡集中展示在單個大盤頁面上，並且通過增加預警值進行異常顯示和彈窗訊息告警。活動作戰室現場，我們採用了多個大屏展示，非常直觀地展現當前主備雙推流鏈路的實時幀率、位元速率等情況，為現場地指揮保障提供了強大的資料決策支撐。
以下圖為例：藍色表示上行幀率，綠色表示正常的上行位元速率，紅色表示位元速率值過低，N/A表示當前沒有上行推流資料。
而在下行播放鏈路中，比較常用的指標就是卡頓率。
下面是我們對卡頓相關的描述：
1）一次卡頓：播放器持續2s發生緩衝區空，即播放器2s沒有拉到流；
2）一分鐘使用者卡頓：1分鐘視窗內，使用者只要卡頓一次，則該使用者計作卡頓使用者；
3）一分鐘使用者卡頓率：1分鐘視窗內，卡頓使用者數/總的使用者數；
4）一分鐘使用者零卡頓率：1分鐘視窗內，(總的使用者數 - 卡頓使用者數)/總的使用者數。
為什麼會選擇使用者卡頓率這個指標，而不是使用整體的卡頓取樣點/總取樣數呢？
是因為：我們更想看到有多少使用者沒有出現過卡頓現象，這更能直觀體現優質網路的整體佔比。通過對各省份使用者零卡頓率、使用者數排行，以及各省使用者卡頓率的觀察，我們可以非常直觀地找到卡頓嚴重的地區，以便重點關注，進行資源排程優化。
7、應急預案
任何一個系統，無論你號稱它被設計得多麼健壯，它仍然會有故障時間的存在。
硬體故障、軟體bug、人為操作失誤等等，這些都無可避免地存在著。他們未必是一個必須多少時間內將其徹底解決的問題，他們是我們必須認清並接受共存的一個事實。
所以：預案管理是大型直播活動保障中不可缺少的一環。
我們遵循以下的預案原則：
1）預案資訊明確：大盤自動監控不具備二義性，確保預案資訊來源正確，觸發執行預案的條件明確且有數值化約束；
2）預案操作簡潔：所有的預案操作都有有簡潔明確(開關型)的操作輸入；
3）預案操作安全：所有預案要經過充分預演，同時預演操作本身需要有明確的確認機制，以確保在正常情況下不會被誤觸發；
4）預案影響驗證：明確理清預案操作的影響，QA在預演階段需要對相關影響進行充分驗證。
此次活動的前期籌備中，我們總計進行了3次直播全鏈路的擬真演練，以及2次聯合互動現場、導播臺現場的活動全流程級別的彩排，另外進行了大大小小總計數十次的各類風險預案演練。所有演練過程中發現的問題，都會進行專項解決。
風險預案這塊，包含了各類資源故障、上下行鏈路質量、地區性網路故障、CDN異常流量水位等在內的場景應對。其中資源故障包含了機器當機、機架整體斷電、堆疊交換機當機、機房外網出口不可用，我們均進行了風險預案演練覆蓋。
下面列舉幾點直播解決方案中的部分預案機制：
1）如果因為誤操作等導致非正常解密等，可在推流不中斷的情況下，動態中止流加密，客戶端無任何感知影響；
2）某家cdn在某地區運營商出現大面積故障癱瘓，該地區相應運營商線路的QoS指標會大幅度下降並觸發報警，將故障cdn在該地區運營商進行黑名單處理，動態停止對其的排程，將流量排程至正常提供服務的cdn廠商；
3）在兩路熱流均正常的情況下，但是正在分發的一路出現質量問題，方案可支援手動觸發主備切換，讓監控資料質量更好的另一路流參與分發，客戶端感知時間在1s以內；
4）因為一些不可抗因素，某機房出現大面積故障整體不可用，觸發鏈路報警，此時我們會緊急將流切至另一機房，故障感知與恢復的時間在一分鐘內。
8、相關文章
[1] 移動端實時音視訊直播技術詳解（一）：開篇
[2] 移動端實時音視訊直播技術詳解（二）：採集
[3] 移動端實時音視訊直播技術詳解（三）：處理
[4] 移動端實時音視訊直播技術詳解（四）：編碼和封裝
[5] 移動端實時音視訊直播技術詳解（五）：推流和傳輸
[6] 移動端實時音視訊直播技術詳解（六）：延遲優化
[7] 淘寶直播技術乾貨：高清、低延時的實時視訊直播技術解密
[8] 愛奇藝技術分享：輕鬆詼諧，講解視訊編解碼技術的過去、現在和將來
[9] 零基礎入門：實時音視訊技術基礎知識全面盤點
[10] 實時音視訊面視必備：快速掌握11個視訊技術相關的基礎概念
[11] 網易雲信實時視訊直播在TCP資料傳輸層的一些優化思路
[12] 淺談實時音視訊直播中直接影響使用者體驗的幾項關鍵技術指標
[13] 首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？
[14] 直播系統聊天技術(一)：百萬線上的美拍直播彈幕系統的實時推送技術實踐之路
[15] 直播系統聊天技術(二)阿里電商IM訊息平臺，在群聊、直播場景下的技術實踐
[16] 直播系統聊天技術(三)：微信直播聊天室單房間1500萬線上的訊息架構演進之路
[17] 直播系統聊天技術(四)：百度直播的海量使用者實時訊息系統架構演進實踐
[18] 直播系統聊天技術(五)：微信小遊戲直播在Android端的跨程式渲染推流實踐
[19] 直播系統聊天技術(六)：百萬人線上的直播間實時聊天訊息分發技術實踐
[20] 直播系統聊天技術(七)：直播間海量聊天訊息的架構設計難點實踐
（本文同步釋出於：http://www.52im.net/thread-38...）