背景和目標(biāo)

英雄聯(lián)盟全球總決賽是英雄聯(lián)盟賽事每年度最受矚目的節(jié)點，也是B站全年賽事熱度最高的時段。第13屆英雄聯(lián)盟全球總決賽（下文簡稱S13）今年繼續(xù)在B站進行直播，本文主要分享S13賽事保障的實踐和思考。

S13的業(yè)務(wù)主目標(biāo)是觀賽用戶達(dá)到1.2億，可拆解到賽前、賽中、賽后三個階段：

• 賽前重在流量蓄水，擴大目標(biāo)用戶，通過賽事活動預(yù)熱、資源位投放、預(yù)約/Push召回，將流量引流到S13賽事主房間（下文簡稱主房間）觀賽。
• 賽中用戶集中在主房間，重點在提升用戶觀賽以及互動體驗，提高用戶的轉(zhuǎn)化率和留存率。
• 賽后引導(dǎo)觀賽用戶會到稿件播放頁觀看回放，在評論區(qū)參與選手打分，在動態(tài)/話題持續(xù)發(fā)表自己對賽事的觀后感。

圖1 S13整體介紹

因此，我們的保障目標(biāo)是保證系統(tǒng)在洪峰流量下為用戶提供穩(wěn)定的功能和流暢的觀賽體驗，配合業(yè)務(wù)側(cè)達(dá)成業(yè)務(wù)目標(biāo)。面臨的挑戰(zhàn)概括為兩點：

1. 洪峰流量大：難點在如何估算業(yè)務(wù)指標(biāo)、如何正確將業(yè)務(wù)指標(biāo)轉(zhuǎn)換為技術(shù)指標(biāo)、以及如何應(yīng)對高并發(fā)流量。
2. 牽扯的業(yè)務(wù)范圍廣：難點在如何不缺不漏、以及如何在業(yè)務(wù)迭代壓力大的背景下盡可能提效的完成保障。

接下來讓我們一起探討本次保障是如何落地的，以及在大型活動保障上帶來了怎樣的思考。

制定保障計劃的思路

通過上文對業(yè)務(wù)主目標(biāo)的介紹和拆解，可看到業(yè)務(wù)目標(biāo)的達(dá)成依托于賽事各階段為用戶提供的功能和體驗，保障業(yè)務(wù)主目標(biāo)達(dá)成也就是保障S13所有要落地使用的業(yè)務(wù)功能。因此，制定技術(shù)保障計劃的思路是：首先確定S13要使用的業(yè)務(wù)功能范圍和各功能的業(yè)務(wù)指標(biāo)（如曝光量/轉(zhuǎn)化率等），其次將其轉(zhuǎn)化為技術(shù)鏈路和技術(shù)指標(biāo)（如QPS/TPS），最后運用技術(shù)手段對齊進行保障。

下圖為S13的保障計劃和時間線，下文也將逐步介紹我們是實踐和落地的：

圖2 S13整體保障計劃

業(yè)務(wù)場景地圖和核心業(yè)務(wù)指標(biāo)

業(yè)務(wù)場景地圖指的是S13所有落地要使用的業(yè)務(wù)功能，圈定了我們要保障的業(yè)務(wù)范圍；核心業(yè)務(wù)指標(biāo)在S13中指的是PCU（Peak Concurrent Users 直播間峰值在線人數(shù))，作為直播場景重要的指標(biāo)，決定了我們要保障的高并發(fā)量級。

項目立項后的第一時間，產(chǎn)運研測各方一起討論敲定了業(yè)務(wù)場景地圖，共60+的業(yè)務(wù)功能，為便于下文具體講解如何將業(yè)務(wù)場景地圖/業(yè)務(wù)指標(biāo)轉(zhuǎn)化為技術(shù)鏈路/技術(shù)指標(biāo)、以及使用的技術(shù)保障手段，首先將S13核心功能介紹下：

表1 業(yè)務(wù)場景示意圖

• 活動頁：S13投放了多個活動頁提高用戶的參與度，如用戶可以在主活動頁上追蹤賽程信息，觀賽的同時參與預(yù)測、觀看、分享、簽到等任務(wù)。
• 流量入口：S13作為一年一度的重要活動，投放在多個資源位，用戶從這些入口進入主房間；賽后，用戶從主房間退出再次返回這些流量入口。該場景需要關(guān)注返回時的自動刷新機制帶來的尖刺流量。
• 主房間：S13最核心還是在直播間內(nèi)，包含流的觀看和功能互動兩部分。流觀看從穩(wěn)定性來看，上行流和下行流需要保證穩(wěn)定可靠容災(zāi)；從帶寬成本來看，還需要考慮P2P覆蓋率、轉(zhuǎn)碼技術(shù)。此外，每次進房需要獲取房間底層信息、功能數(shù)據(jù)（如榜單/運營位/底部Tab/歷史彈幕等），在比賽期間，還有天選時刻、熱力特效、Combo彈幕等互動玩法。其次，房間內(nèi)的發(fā)彈幕/送禮特效等功能均依賴長連接，而長連接的壓力是PCU級別的放大效應(yīng)。最后，終端的性能表現(xiàn)、播放的質(zhì)量監(jiān)控也是保證用戶觀賽體驗重要的一環(huán)。
• 稿件播放頁/動態(tài)等：S13不僅是觀賽后就結(jié)束了，B站作為一個業(yè)務(wù)形態(tài)十分豐富的平臺，用戶還可以去觀看直播回放、知名解說、在動態(tài)話題評論等參與討論。

圖3 S13核心業(yè)務(wù)場景

實際執(zhí)行中，我們建議利用表格形式將業(yè)務(wù)場景地圖和業(yè)務(wù)指標(biāo)羅列出來：

表2 S13業(yè)務(wù)場景地圖一覽表表頭參考

表3 S13賽事各階段PCU預(yù)估

流量預(yù)估模型與優(yōu)化

流量預(yù)估模型

將業(yè)務(wù)核心指標(biāo)轉(zhuǎn)化為技術(shù)指標(biāo)，指的是利用曝光量/轉(zhuǎn)化率/點擊率等轉(zhuǎn)換成技術(shù)指標(biāo)QPS/TPS。S13的業(yè)務(wù)指標(biāo)PCU可等價于曝光量，一個業(yè)務(wù)功能對房間在線用戶同時曝光。根據(jù)我們的經(jīng)驗，基本可以按照目標(biāo)QPS=曝光量*轉(zhuǎn)化率1*......*轉(zhuǎn)化率n/分?jǐn)倳r長=PCU*轉(zhuǎn)化率1*......*轉(zhuǎn)化率n/分?jǐn)倳r長。

圖4 技術(shù)指標(biāo)QPS/TPS的流量預(yù)估模型

下面通過幾個典型場景具體說明該模型的運用，以及主房間這類高在線房間遇到的瓶頸問題，我們是如何通過熱門房間緩存、流量打散、流量隔離和下滑預(yù)加載等技術(shù)手段解決的：

進房場景

功能概述：用戶從閃屏、首頁推薦、全量Push、小黃條等資源位進入主房間時，終端向服務(wù)端請求流地址/房間底層信息/歷史彈幕等數(shù)據(jù)，使主房間成為高在線房間，帶來單房間熱點問題。

QPS預(yù)估：總進房QPS=各資源位進房QPS之和。以全量Push為例，Push進房QPS=全量用戶數(shù)*送達(dá)率*點擊率/推送時長（全量用戶數(shù)*送達(dá)率=Push曝光量，推送時長=分?jǐn)倳r長）。

圖5 進房場景QPS趨勢圖

技術(shù)優(yōu)化：單房間熱點問題使得系統(tǒng)內(nèi)獲取房間維度數(shù)據(jù)成為瓶頸，優(yōu)化手段是通過PCU指標(biāo)高低判定是否為高在線房間，通過將高在線房間加入熱門房間內(nèi)存緩存來承接高并發(fā)請求。

圖6 高在線房間進房場景優(yōu)化

圖7 進房場景緩存命中率

天選時刻

功能概述：開啟天選時刻，主房間彈出天選參與框，用戶若點擊一鍵參與則參與本次天選，用戶若點擊關(guān)閉則放棄本次天選，到達(dá)設(shè)定時間后，從所有參與本次天選的用戶中選出中獎用戶。

圖8 直播間天選時刻

QPS預(yù)估：參與天選接口的QPS=PCU*點擊參與轉(zhuǎn)化率。

技術(shù)優(yōu)化：當(dāng)PCU是百萬千萬級別時，該場景存在寫瓶頸。優(yōu)化手段是通過流量打散，將參與框?qū)τ脩舻膹棾鰰r間錯開，分?jǐn)傇谝欢〞r間內(nèi)對所有用戶展示完（分?jǐn)倳r間不會影響用戶的參與時間），并且根據(jù)PCU來自適應(yīng)調(diào)整分?jǐn)倳r長。經(jīng)調(diào)整，QPS=PCU*點擊參與轉(zhuǎn)化率/分?jǐn)倳r長，有效化解了尖刺流量超出系統(tǒng)承受能力的問題。

圖9 天選時刻打散

圖10 參與天選接口的尖刺流量

長連接

功能概述：主房間內(nèi)多項功能依賴長連接，例如用戶在主房間發(fā)送一條彈幕，長連接會將此條彈幕廣播到所有與主房間建立連接的終端。

QPS預(yù)估：長連接邊緣節(jié)點的壓力=N*PCU（N是同時發(fā)生的廣播事件）。一方面，N*PCU越大，帶寬成本越高；另一方面，實際并不會將所有事件都廣播出去，否則干擾用戶的觀看體驗。

技術(shù)優(yōu)化：我們將主房間這類高在線房間的監(jiān)控和控制與其他房間隔離，針對主房間各廣播事件的QPS和Size單獨監(jiān)控、單獨限流，通過單獨調(diào)控主房間使系統(tǒng)壓力、帶寬成本和用戶體驗達(dá)到一個平衡。

圖11 總帶寬和高在線房間帶寬隔離監(jiān)控

散場場景

功能概述：如前文介紹，主房間的散場路徑分別是退回至進入房間之前的流量入口頁面和下滑至另外一個直播間。

QPS預(yù)估：

1. 散場路徑一為流量入口帶來的QPS=PCU*退回點擊率；
2. 散場路徑二為下滑的下一個直播間帶來的QPS=PCU*下滑轉(zhuǎn)化率。

與電影散場時觀眾同一時間集中走出觀影廳類似，上述兩個散場路徑的QPS是非常明顯的尖刺流量。

圖12 散場場景的尖刺流量

技術(shù)優(yōu)化：

1. 散場路徑一：出于推薦效果的考量，用戶停留在主房間超過一定時間后再回退至流量入口，部分流量入口會觸發(fā)自動刷新機制。但并不是所有用戶回退后是繼續(xù)消費最新推薦內(nèi)容。因此，采取的手段是在部分時間段避免觸發(fā)自動刷新機制，更自動化的手段是當(dāng)超出系統(tǒng)承受值時，自動控制終端不觸發(fā)自動刷新。
2. 散場路徑二：由于主房間的PCU過高，導(dǎo)致下滑的下一個房間也成為一個高在線房間，依賴高在線房間SDK可使該房間自動進入熱門房間緩存。但根據(jù)對推薦結(jié)果的分析，我們發(fā)現(xiàn)推薦的下一個房間聚集在有限的幾個賽事房間。為更安全的防御這類瞬時尖刺流量，優(yōu)化手段是基于推薦結(jié)果，利用這幾個賽事房間作為主房間下滑的房間候選池，并提前加入熱門房間內(nèi)存緩存。

圖13 散場路徑二優(yōu)化后緩存命中率效果

全局維度關(guān)注流量

同一個下游，可能被多個業(yè)務(wù)場景同時調(diào)用，該下游的流量是所有被調(diào)用之和。因此除了關(guān)注某個指定接口的QPS，還需以業(yè)務(wù)場景維度和整場活動維度來關(guān)注，下文我們還會再探討實際操作上如何去做。

另外，從項目成本以及資源考慮，賽事期間的流量遠(yuǎn)高于日常，所需要的資源也遠(yuǎn)高于日常，需要提前盤點各階段成本、進行資源的采買，因此全局估算流量也是資源容量預(yù)估的前提。

保障任務(wù)分工

確定業(yè)務(wù)場景地圖后，參與人和團隊的確認(rèn)需要結(jié)合保障事項和組織架構(gòu)兩方面考慮。

參考RASIC原則，保障事項拆分為若干項子任務(wù)，每一項子任務(wù)需設(shè)立負(fù)責(zé)人以及明確責(zé)任邊界、目標(biāo)和DeadLine。另一方面，實際過程中不免存在交叉事項涉及多方資源協(xié)調(diào)，因此根據(jù)保障事項涉及到的部門，分別設(shè)立了部門級別的方向負(fù)責(zé)人，方向負(fù)責(zé)人被充分授權(quán)負(fù)責(zé)協(xié)調(diào)保障事宜。最后，建立定時定期同步進展和風(fēng)險的機制，也是整個項目順利運行的重點。

圖14 保障接口人思路示意圖

實踐和思考

除了前文所述用戶強感知到的業(yè)務(wù)功能之外，還有基礎(chǔ)建設(shè)部分，如業(yè)務(wù)功能底層使用到的流媒體、長連接、賬號、風(fēng)控等，我們將其歸納在業(yè)務(wù)基礎(chǔ)建設(shè)中分專項進行保障。以及從B站的整體基礎(chǔ)架構(gòu)來看，各層基礎(chǔ)組件如動態(tài)/靜態(tài)CDN、SLB、入侵防御WAF、統(tǒng)一網(wǎng)關(guān)APIGW、內(nèi)部服務(wù)發(fā)現(xiàn)Discovery、PaaS、存儲Redis/DB、異步消費Databus、網(wǎng)絡(luò)、大數(shù)據(jù)等的資源預(yù)備、多活容災(zāi)能力、應(yīng)急預(yù)案，我們將其歸納在技術(shù)基礎(chǔ)建設(shè)中整體保障（見圖2）。

接下來我們將重點討論技術(shù)鏈路的梳理、故障演練、全鏈路壓測、預(yù)案SOP、變更管控和賽中跟蹤的實踐和思考：

圖15 重點保障事項時間線

技術(shù)鏈路梳理

技術(shù)鏈路梳理需要得到：

1. 該業(yè)務(wù)場景涉及到的請求接口以及每個接口的鏈路依賴
2. 這些請求接口以及鏈路依賴的QPS/TPS

故障演練、全鏈路壓測以及后續(xù)的SOP、監(jiān)控都依賴技術(shù)鏈路的梳理結(jié)果。根據(jù)代碼梳理技術(shù)鏈路是常用的方法：

Step1：梳理該業(yè)務(wù)場景下，涉及哪些用戶在什么時機下，在哪些位置上做什么動作，即用戶、終端、服務(wù)端三者的交互。

Step2：根據(jù)交互流程，確定終端和服務(wù)端交互的接口。

Step3：下鉆每個交互接口的鏈路。

但在S13中，存在兩個問題：

1. 時間成本高：根據(jù)經(jīng)驗，完成一個場景的技術(shù)鏈路梳理需要0.5d~2d（與場景復(fù)雜度/熟悉程度相關(guān)），60+場景共需要100d左右。
2. 準(zhǔn)確性：人都有百密一疏，純靠人看代碼容易存在紕漏。

因此，聯(lián)同業(yè)務(wù)架構(gòu)團隊，我們在服務(wù)質(zhì)量保障平臺Advisor（下文簡稱Advisor）上集成了輔助工具：在Advisor上定義S13涉及到的業(yè)務(wù)場景，通過抓包走一遍該業(yè)務(wù)場景下用戶的行為路徑，將抓包結(jié)果錄入系統(tǒng)，并根據(jù)Trace自動輸出鏈路依賴，同時計算鏈路依賴的放大情況。

表3 Advisor場景管理

圖16 技術(shù)鏈路示意圖，其中每一個卡片標(biāo)記放大倍數(shù)

根據(jù)前文流量預(yù)估模型計算終端接口QPS和技術(shù)鏈路后，也可得到鏈路上各層依賴的QPS。也因為平臺上維護了技術(shù)鏈路元數(shù)據(jù)，讓前文提到的從業(yè)務(wù)場景維度和活動全局維度關(guān)注流量成為一件可能實現(xiàn)的事情，否則以文檔形式記載技術(shù)鏈路，很難做到這一點。

圖17 Advisor上技術(shù)鏈路元數(shù)據(jù)模型

遺留的問題是，某個業(yè)務(wù)場景可能由于版本不同、用戶身份不同導(dǎo)致技術(shù)鏈路不同，這里提供兩種解決方案：

方式1：構(gòu)造不同版本、不同用戶身份多次抓包，Advisor支持將多次抓包合并作為最終結(jié)果；在此基礎(chǔ)上，通過代碼檢查梳理結(jié)果是否全面。

方式2：Advisor根據(jù)線上真實請求匯總成完整的請求鏈路，再由技術(shù)同學(xué)從中擇選S13涉及到的鏈路。

圖18 基于完整鏈路擇選

故障演練

S13中希望通過故障演練平臺Fault（下文簡稱Fault）達(dá)到的目的是：正確識別到技術(shù)鏈路上的強弱依賴，強依賴應(yīng)當(dāng)確保有發(fā)現(xiàn)機制和預(yù)案手段，弱依賴應(yīng)當(dāng)確?？梢宰詣咏导?，且降級后不影響該業(yè)務(wù)場景的核心功能。建議故障演練放在前置工作：

1. 通過故障演練可識別S13的強依賴路徑，便于更有針對性的進行壓測、SOP。
2. 故障演練發(fā)現(xiàn)的問題涉及代碼改動，壓測應(yīng)當(dāng)基于改動后的代碼。

日常演練的做法是以接口維度將其中的故障點依次注入故障（可參考B站故障演練平臺實踐）。但S13的60+業(yè)務(wù)功能，逐一驗證接口，時間成本太大。因此，將演練優(yōu)化為兩大步驟：

Step1：優(yōu)先確定面向終端的接口的強弱。如果某個接口故障并不影響該業(yè)務(wù)場景的核心功能，則定義為弱依賴。例如進房場景，通過驗證全屏/豎屏觀看、喚起禮物面板送禮、在彈幕區(qū)發(fā)送彈幕互動等幾個核心功能，從20+個接口最終確定4個強依賴接口（見表3的強弱依賴標(biāo)注）。

Step2：針對Step1篩選出來的強依賴接口，聯(lián)同質(zhì)量工程效率團隊建設(shè)了面向業(yè)務(wù)場景的故障演練，以業(yè)務(wù)場景維度整體驗證。將Advisor的技術(shù)鏈路導(dǎo)入Fault，F(xiàn)ault自動將標(biāo)注預(yù)期是弱依賴的依賴點組合排列，自動依次注入故障和調(diào)用自動化用例驗證表現(xiàn)。

圖19 Step2示意圖

圖20 Fault業(yè)務(wù)場景演練

全鏈路壓測

S13通過全鏈路壓測平臺Melloi（下文簡稱Melloi）來發(fā)現(xiàn)和驗證高性能/高并發(fā)帶來的問題，高在線房間存在的問題也非常具有共性：

1. 熱點Key問題：用戶集中在主房間，以房間Id/主播Id為 Key的緩存成為熱點Key。
2. 空緩存問題：賽事期間用戶量相比平時翻了幾十上百倍，且存在不少一段時間內(nèi)沒有訪問過直播的冷數(shù)據(jù)用戶，需要空緩存或者使用布隆過濾器防止緩存穿透造成DB的高并發(fā)，甚至部分場景需要預(yù)熱。
3. 消費積壓問題：賽事活動與用戶行為強相關(guān)，例如觀看達(dá)到X分鐘可獲獎勵，主房間的觀看量百萬千萬級別，要求高性能消費和削峰。

本文重點探討基于Advisor的技術(shù)鏈路信息，在壓測環(huán)節(jié)可做的優(yōu)化：

1. 提高壓測數(shù)據(jù)準(zhǔn)備的效率：純讀接口可根據(jù)Advisor信息從線上錄制流量回放作為壓測流量
2. 提高壓測結(jié)果回收的效率：可根據(jù)Advisor信息，與壓測流量對比，檢測壓測流量是否已覆蓋需要覆蓋的鏈路，以及技術(shù)鏈路上各層的指標(biāo)是否處于健康水位，并根據(jù)具體情況提供標(biāo)準(zhǔn)化解決方案的參考（例如熱Key問題，可以提供統(tǒng)一的熱Key識別和解決方案）。

圖21 全鏈路提效示意圖

預(yù)案SOP

針對故障演練識別到的強依賴路徑，需要做好預(yù)案SOP。可以縮短MTTR為目標(biāo)，從1分鐘發(fā)現(xiàn)、5分鐘定位、10分鐘恢復(fù)的原則準(zhǔn)備預(yù)案：

表4 預(yù)案SOP模版

變更管控

基于安全變更要求，賽事直播保障期間，我們也啟用了變更管控封網(wǎng)，嚴(yán)格控制線上變更

數(shù)量，同時也需要支持必要的需求迭代變更，我們采取了以下措施：

1. 整個活動保障期間：非強變更管控，根據(jù)前期場景梳理涉及到的業(yè)務(wù)功能，對其業(yè)務(wù)需求和技術(shù)需求上線變更要求進行郵件報備。報備內(nèi)容需要包括變更內(nèi)容、變更的風(fēng)險、如有問題是否支持回滾、預(yù)案SOP等；
2. 關(guān)鍵賽事直播當(dāng)天：強變更管控，同樣來自前期場景梳理設(shè)計的業(yè)務(wù)應(yīng)用，通過“變更管控 ChangePilot”平臺進行創(chuàng)建業(yè)務(wù)+服務(wù)等級的封網(wǎng)策略。同時支持緊急情況下的變更需求提供綠色通道。

圖22 強變更管控策略創(chuàng)建

賽中跟蹤

穩(wěn)定性可觀測：基于SLO體系的持續(xù)建設(shè)，我們實現(xiàn)了服務(wù)可用率、服務(wù)飽和度的觀測/告警覆蓋。賽事過程中通過穩(wěn)定性大盤我們能夠非常直觀的觀測到全站業(yè)務(wù)的穩(wěn)定性情況；當(dāng)服務(wù)出現(xiàn)可用率的下跌（10分鐘平均可用率N2），相關(guān)協(xié)同群會立即推送預(yù)警工單。同時提供相關(guān)錯誤詳情和錯誤根因推薦，大幅提高問題排查定位效率；

圖23 SLO全網(wǎng)業(yè)務(wù)大盤

實時監(jiān)控大盤：除了全局業(yè)務(wù)穩(wěn)定性的觀測，賽事過程也同樣會關(guān)注PCU情況、核心場景的QPS、P90耗時、限流情況；以及核心場景涉及服務(wù)的容量水位；通過應(yīng)用APPID進行元信息關(guān)聯(lián)，獲取直播場景下相關(guān)的緩存集群、數(shù)據(jù)庫實例、消息隊列等組件的信息，關(guān)聯(lián)實現(xiàn)組件容量水位的實時觀測。以上指標(biāo)均配置了不同檔位的閾值，能夠快速發(fā)現(xiàn)基礎(chǔ)資源容量風(fēng)險。

圖24 賽事保障實時監(jiān)控大盤

基礎(chǔ)數(shù)據(jù)同步：基于業(yè)務(wù)SLO視角和大盤資源視角，我們會在賽事直播過程中進行告警的應(yīng)急響應(yīng)處置、核心資源水位數(shù)據(jù)定時同步。直播后對告警事件處置情況以時間線方式導(dǎo)出，相關(guān)監(jiān)控數(shù)據(jù)也會進行持久化存儲，支持后續(xù)分析復(fù)盤。

展望

英雄聯(lián)盟總決賽今年已經(jīng)走到了第13個年頭，B站在每年的S賽保障上也逐漸積累了越來越多寶貴的經(jīng)驗。此外，直播每年的大型活動還有跨晚、拜年紀(jì)等，大型活動保障的經(jīng)驗如何以平臺化的方式沉淀下來，為后續(xù)的保障提高效率是我們需要進一步考慮的?；诒敬谓?jīng)驗，以及前文探討的直播特性問題，對于一場活動的保障可以考慮如下流程：

圖25 大型直播活動保障平臺化

本期作者

趙丹丹嗶哩嗶哩資深開發(fā)工程師

吉翔 嗶哩嗶哩資深運維工程師