本文由網(wǎng)易云信技術(shù)團(tuán)隊(duì)分享，原題“如何保障一場(chǎng)千萬級(jí)大型直播？”，有修訂和改動(dòng)。

1、引言

本文以TFBOYS“日光旅行”七周年這場(chǎng)直播演唱會(huì)為案例，為你分享大型直播系統(tǒng)后端架構(gòu)設(shè)計(jì)的方方面面，包括：基本架構(gòu)、穩(wěn)定性保障、安全性障、監(jiān)控報(bào)警、應(yīng)急預(yù)案等技術(shù)范疇。

案例中的這次演唱會(huì)采用了在線實(shí)時(shí)互動(dòng)及演唱會(huì)現(xiàn)場(chǎng)的多場(chǎng)景導(dǎo)播切換，提供了主機(jī)位和三個(gè)藝人專屬機(jī)位流，同時(shí)每個(gè)機(jī)位流實(shí)時(shí)轉(zhuǎn)碼四個(gè)清晰度檔位，用戶可以根據(jù)喜好選擇自己想看的內(nèi)容。這場(chǎng)演唱會(huì)最高同時(shí)在線人數(shù)達(dá)78.6萬，打破線上付費(fèi)演唱會(huì)世界記錄。

學(xué)習(xí)交流：

- 移動(dòng)端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK?

（本文同步發(fā)布于：http://www.52im.net/thread-3875-1-1.html）

2、本文作者

費(fèi)曼：網(wǎng)易智企服務(wù)端開發(fā)工程師。碩士畢業(yè)于華中科技大學(xué)電信系，2016年加入網(wǎng)易云信，熱衷于大規(guī)模分布式系統(tǒng)和音視頻相關(guān)技術(shù)，愛好文學(xué)、體育和電影。

3、架構(gòu)方面

3.1 基本

?

上圖是該次TFBOYS在線演唱會(huì)的直播媒體架構(gòu)簡(jiǎn)圖。

可以看出一場(chǎng)大型活動(dòng)直播涵蓋的技術(shù)方案點(diǎn)非常龐雜，本節(jié)接下來的內(nèi)容我們將以推拉流鏈路、全局智能調(diào)度、流量精準(zhǔn)調(diào)度以及單元化部署，對(duì)這套直播方案做一個(gè)展開介紹。

3.2 推拉流鏈路

?

如上圖所示，直播技術(shù)架構(gòu)，分為幾大部分：

• 1）視頻直播中心（LMS——Live Manage Service）：負(fù)責(zé)直播流的邏輯管理和操作控制，包括存儲(chǔ)和下發(fā)實(shí)時(shí)轉(zhuǎn)碼、加密等媒體處理的配置信息；

• 2）實(shí)時(shí)互動(dòng)直播服：由連麥互動(dòng)和直播兩部分組成，主播和連麥者的音視頻數(shù)據(jù)在互動(dòng)直播高性能服務(wù)器合成為一道流后推流到直播流媒體服務(wù)器；

• 3）直播源站服務(wù)（LSS——Live Source Service）：網(wǎng)易云信自建的直播流媒體服務(wù)器節(jié)點(diǎn)，結(jié)合全局智能調(diào)度系統(tǒng)，提供第一公里的最佳鏈路選擇，同時(shí)融合支持接入多家CDN廠商；

• 4）媒體處理服務(wù)（MPS——Media Processing Service）：提供實(shí)時(shí)水印、實(shí)時(shí)轉(zhuǎn)碼、媒體數(shù)據(jù)加密等強(qiáng)大的流媒體處理能力；

• 5）融合CDN與全局智能調(diào)度（GSLB——Golabal Server Load Balancing）：提供敏捷智能的CDN調(diào)度策略和分配算法，結(jié)合全鏈路、端到端的流媒體控制，來達(dá)到最終端側(cè)優(yōu)良的用戶體驗(yàn)；

• 6）客戶端SDK：提供推流、拉流以及上下行的調(diào)度能力，便于用戶快速接入使用網(wǎng)易云信平臺(tái)一站式的音視頻解決方案。

3.3 融合CDN與智能調(diào)度

這是一個(gè)端到端的服務(wù)，通過平臺(tái)的SDK執(zhí)行一個(gè)類似HTTPDNS的調(diào)度，來做到真正根據(jù)用戶IP做就近的接入。

針對(duì)國(guó)內(nèi)相對(duì)復(fù)雜的運(yùn)營(yíng)商網(wǎng)絡(luò)環(huán)境，在直播上行方面通過BGP網(wǎng)絡(luò)以及與相關(guān)運(yùn)營(yíng)商在網(wǎng)絡(luò)接入方面的合作，能夠更加精準(zhǔn)地控制網(wǎng)絡(luò)鏈路的選擇。

而對(duì)于下行，也提供了播放端的SDK接入，通過端到端的調(diào)度策略就近選擇合適的下行鏈路。

調(diào)度的準(zhǔn)確性以及最終效果，依賴及時(shí)準(zhǔn)確的數(shù)據(jù)支撐。

我們有一個(gè)全鏈路、立體的數(shù)據(jù)監(jiān)控體系，一方面利用CDN上的一些實(shí)時(shí)日志，另一方面結(jié)合自建節(jié)點(diǎn)、客戶端側(cè)上報(bào)收集鏈路上探測(cè)的數(shù)據(jù)，然后整合做一個(gè)實(shí)時(shí)計(jì)算來支撐整個(gè)調(diào)度的策略。

融合CDN方案，通過調(diào)度、監(jiān)控、高可用等技術(shù)和手段來解決CDN網(wǎng)絡(luò)方面的問題。但是對(duì)于技術(shù)人員來說，就和在使用一個(gè)傳統(tǒng)的CDN網(wǎng)絡(luò)一樣沒有大的差異，這些技術(shù)細(xì)節(jié)對(duì)技術(shù)人員透明無感知。

3.4 流量精準(zhǔn)調(diào)度

大型演唱會(huì)直播活動(dòng)，尤其是正式開播時(shí)的進(jìn)場(chǎng)階段，突發(fā)流量峰值會(huì)非常高，這就需要實(shí)時(shí)精準(zhǔn)的智能調(diào)度策略。

融合CDN的智能調(diào)度包含兩大部分：CDN分配調(diào)度和節(jié)點(diǎn)調(diào)度。

節(jié)點(diǎn)調(diào)度：比較常見的是DNS協(xié)議解析調(diào)度和IP調(diào)度（302/HTTPDNS）。前者由于DNS協(xié)議原因，調(diào)度生效時(shí)間較慢，而后者則可以做到請(qǐng)求級(jí)別的調(diào)度，也就是支持任意比例的負(fù)載均衡，更加及時(shí)精準(zhǔn)。在我們的智能調(diào)度的場(chǎng)景里，正常情況下會(huì)遵循IP調(diào)度，在IP調(diào)度解析失敗時(shí)，客戶端上會(huì)啟動(dòng)loacl DNS解析邏輯，兩者的結(jié)合確保了調(diào)度的精準(zhǔn)和穩(wěn)定可靠。

Don't put all your eggs in one basket.

“永遠(yuǎn)不要將雞蛋放在同一個(gè)籃子里”。

從風(fēng)險(xiǎn)管控的角度來說：大型活動(dòng)保障的CDN廠商資源，通常沒法通過一家CDN資源進(jìn)行滿足。融合CDN方案則是將多家CDN廠商進(jìn)行整合與流量分配調(diào)度。

通常在一次大型直播中，多家CDN廠商提供的容量（區(qū)域帶寬、最高帶寬）、質(zhì)量會(huì)各不相同。我們則是通過動(dòng)態(tài)調(diào)整調(diào)度比例，在確保不超過最大帶寬的前提下，精確化按比例分配流量，以及盡可能地確保體驗(yàn)。

我們?cè)O(shè)計(jì)了一套針對(duì)CDN廠商的打分算法：影響因子包含當(dāng)前帶寬、保底帶寬、最大帶寬、帶寬預(yù)測(cè)、帶寬質(zhì)量。

算法遵循以下原則：

• 1）沒超保底的帶寬，比超過保底的帶寬，得分更高；

• 2）沒超保底的時(shí)候，剩余保底和剩余總帶寬越大，得分更高；

• 3）超過保底的時(shí)候，剩余總帶寬越大、質(zhì)量越好，得分更高。

各CDN的分?jǐn)?shù)之比決定了調(diào)度比例，CDN打分算法是在持續(xù)地迭代更新計(jì)算，最大化分配使用各家CDN的帶寬，然后再分配各家CDN廠商的保障之外的資源。同時(shí)優(yōu)先選擇質(zhì)量較好的廠家，避免單價(jià)CDN廠商超分配。

3.5 單元化部署

上面所說，在大型直播活動(dòng)中，短時(shí)間大量涌入的用戶請(qǐng)求，對(duì)以全局智能調(diào)度服務(wù)為主的相關(guān)非媒體流鏈路應(yīng)用，也提出了更高的并發(fā)處理挑戰(zhàn)。

除了上行的推流鏈路我們做了主備兩個(gè)單元的部署，非媒體數(shù)據(jù)鏈路上的服務(wù)也采用了單元化的部署方案。

在此部署方案下，可用性做到任意單元機(jī)房故障，不影響整體可用性，即異地多活。

單元化部署遵循以下原則：

• 1）單元化的依賴也必須單元化（核心業(yè)務(wù)）；

• 2）單元化粒度為應(yīng)用，非api；

• 3）單元化技術(shù)棧對(duì)應(yīng)用盡量避免產(chǎn)生侵入性。

?

如上圖所示：非單元化的業(yè)務(wù)部署在主機(jī)房，單元化的業(yè)務(wù)則部署在主機(jī)房和單元機(jī)房。

4、穩(wěn)定性保障

4.1 上行鏈路穩(wěn)定

超大型直播方案最核心的訴求就是直播穩(wěn)定性，下面我們將以該次在線演唱會(huì)為案例，重點(diǎn)闡述一下直播的全鏈路穩(wěn)定性架構(gòu)。

上圖是我們直播的媒體流鏈路示意簡(jiǎn)圖：整體方案可以承受任何單節(jié)點(diǎn)、單線路、單機(jī)房網(wǎng)絡(luò)出口的故障。

如直播源站部分：采用了多線策略收流，包含機(jī)房專線和4G背包方案，一主一備兩個(gè)線路。同時(shí)每個(gè)單元的源站集群都有4層負(fù)載均衡，一臺(tái)機(jī)器宕機(jī)不會(huì)影響整體可用性。LMS、LSS、MPS都是跨機(jī)房部署，所有服務(wù)模塊都可配置專有資源池供使用，保證不會(huì)受其他租戶影響。

整個(gè)推流鏈路：采用雙路熱流、互為主備，且部署上是互相獨(dú)立的兩個(gè)單元，能做到支持Rack級(jí)別的故障災(zāi)備。雙路熱流實(shí)現(xiàn)了自動(dòng)主備切換，端上無需專門添加應(yīng)用層的線路切換邏輯。當(dāng)任何一個(gè)鏈路出現(xiàn)問題的時(shí)候，觀眾的直播流不會(huì)受到影響，端上平均卡頓感知時(shí)間在1s以內(nèi)。

除了推流鏈路的整體主備單元容災(zāi)，每個(gè)單元的服務(wù)本身也會(huì)有容災(zāi)手段。比如UPS接入，可以接受30min的供電故障，比如當(dāng)實(shí)時(shí)互動(dòng)流出現(xiàn)問題時(shí)，導(dǎo)播臺(tái)會(huì)推墊片流以保證鏈路數(shù)據(jù)不中斷。

4.2 下行鏈路穩(wěn)定

在訪次直播活動(dòng)中，全局智能調(diào)度服務(wù)會(huì)承受較大的峰值壓力，在單元化部署的基礎(chǔ)上，我們經(jīng)過多輪壓測(cè)和性能調(diào)優(yōu)，模型上可支撐千萬級(jí)用戶在半分鐘內(nèi)全部進(jìn)入直播間。

除了上述關(guān)于推流鏈路的高可用，下行鏈路也有相關(guān)的容災(zāi)策略。當(dāng)GSLB智能調(diào)度服務(wù)整體不可用，在客戶端SDK預(yù)埋了融合CDN的local DNS災(zāi)備邏輯與比例配置，將云端的全局智能調(diào)度fail-over到客戶端的本地兜底調(diào)度，并保持大數(shù)據(jù)統(tǒng)計(jì)層面的各CDN廠商的流量分配均衡。

同時(shí)：客戶端也會(huì)有播放體驗(yàn)方面的容災(zāi)策略，諸如清晰度降級(jí)、線路調(diào)整等。

5、安全性保障

除了直播全鏈路的穩(wěn)定之外，直播安全也很重要。

該次直播活動(dòng)中，為TFBOYS活動(dòng)鏈路多環(huán)節(jié)都提供了安全保障機(jī)制（如防盜鏈鑒權(quán)、IP黑白名單、HTTPS等能力），以及地區(qū)、運(yùn)營(yíng)商等下行調(diào)度的動(dòng)態(tài)限制，實(shí)現(xiàn)全鏈路安全保障。

在此基礎(chǔ)上：此次活動(dòng)采用了端到端的視頻流數(shù)據(jù)加密。

直播場(chǎng)景的加密有幾點(diǎn)基本要求：壓縮比不變、實(shí)時(shí)性和低計(jì)算復(fù)雜度。

除此之外：在融合多cdn的方案背景下，視頻流的加密必須考慮到CDN廠商的兼容性。

比如須滿足以下要求：

• 1）不破壞流媒體協(xié)議格式、視頻容器格式；

• 2）metadata/video/audio tag的header部分不加密；

• 3）對(duì)于avcSequenceHeader和aacSequenceHeader tag整體不加密。

具體加密算法，可以采用一些流式加密算法，這里我們不再贅述。

?

6、監(jiān)控與報(bào)警

6.1 概述

一場(chǎng)大型直播將會(huì)有大量的計(jì)算節(jié)點(diǎn)參與，除了媒體數(shù)據(jù)處理與分發(fā)的各個(gè)服務(wù)器節(jié)點(diǎn)，還有分布在國(guó)內(nèi)外的海量客戶端。

我們對(duì)網(wǎng)絡(luò)鏈路、服務(wù)節(jié)點(diǎn)、設(shè)備端的健康與質(zhì)量感知，都離不開數(shù)據(jù)監(jiān)控系統(tǒng)。

同時(shí)：我們?cè)诂F(xiàn)有系統(tǒng)無法自動(dòng)fail-over的故障場(chǎng)景下，需要人工預(yù)案介入，而后者的決策判斷，也強(qiáng)依賴于完善的全鏈路數(shù)據(jù)質(zhì)量監(jiān)控與報(bào)警系統(tǒng)。

6.2 全鏈路監(jiān)控

整個(gè)直播鏈路的監(jiān)控包含了：

• 1）上行推流鏈路的流質(zhì)量；

• 2）媒體流實(shí)時(shí)轉(zhuǎn)碼處理；

• 3）端上播放質(zhì)量；

• 4）智能調(diào)度系統(tǒng)的可用性；

• 5）業(yè)務(wù)量水位等相關(guān)監(jiān)控?cái)?shù)據(jù)。

上行鏈路常見的QoS指標(biāo)有：幀率、碼率、RTT等，其維度包含主備線路、出口運(yùn)營(yíng)商、CDN廠商節(jié)點(diǎn)等。

端上的QoS指標(biāo)則包含了：拉流成功率、首幀時(shí)長(zhǎng)、卡頓率、httpdns緩存命中率，維度則覆蓋包含CDN廠商、國(guó)家、省份、運(yùn)營(yíng)商、直播流、清晰度檔位、客戶端等。

此次直播中：內(nèi)容上支持了多種機(jī)位流以及多個(gè)清晰度的轉(zhuǎn)碼輸出流，同時(shí)通過多個(gè)CDN廠商進(jìn)行分發(fā)，我們把上行鏈路中節(jié)點(diǎn)的碼率、幀率，直觀地通過N個(gè)指標(biāo)卡集中展示在單個(gè)大盤頁面上，并且通過增加預(yù)警值進(jìn)行異常顯示和彈窗消息告警?；顒?dòng)作戰(zhàn)室現(xiàn)場(chǎng)，我們采用了多個(gè)大屏展示，非常直觀地展現(xiàn)當(dāng)前主備雙推流鏈路的實(shí)時(shí)幀率、碼率等情況，為現(xiàn)場(chǎng)地指揮保障提供了強(qiáng)大的數(shù)據(jù)決策支撐。

以下圖為例：藍(lán)色表示上行幀率，綠色表示正常的上行碼率，紅色表示碼率值過低，N/A表示當(dāng)前沒有上行推流數(shù)據(jù)。

而在下行播放鏈路中，比較常用的指標(biāo)就是卡頓率。

下面是我們對(duì)卡頓相關(guān)的描述：

• 1）一次卡頓：播放器持續(xù)2s發(fā)生緩沖區(qū)空，即播放器2s沒有拉到流；

• 2）一分鐘用戶卡頓：1分鐘窗口內(nèi)，用戶只要卡頓一次，則該用戶計(jì)作卡頓用戶；

• 3）一分鐘用戶卡頓率：1分鐘窗口內(nèi)，卡頓用戶數(shù)/總的用戶數(shù)；

• 4）一分鐘用戶零卡頓率：1分鐘窗口內(nèi)，(總的用戶數(shù) - 卡頓用戶數(shù))/總的用戶數(shù)。

為什么會(huì)選擇用戶卡頓率這個(gè)指標(biāo)，而不是使用整體的卡頓采樣點(diǎn)/總采樣數(shù)呢？

是因?yàn)椋?/strong>我們更想看到有多少用戶沒有出現(xiàn)過卡頓現(xiàn)象，這更能直觀體現(xiàn)優(yōu)質(zhì)網(wǎng)絡(luò)的整體占比。通過對(duì)各省份用戶零卡頓率、用戶數(shù)排行，以及各省用戶卡頓率的觀察，我們可以非常直觀地找到卡頓嚴(yán)重的地區(qū)，以便重點(diǎn)關(guān)注，進(jìn)行資源調(diào)度優(yōu)化。