背景和目標

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

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

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

圖1 S13整體介紹

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

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

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

制定保障計劃的思路

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

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

圖2 S13整體保障計劃

業(yè)務場景地圖和核心業(yè)務指標

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

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

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

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

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

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

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

表3 S13賽事各階段PCU預估

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

流量預估模型

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

圖4 技術指標QPS/TPS的流量預估模型

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

進房場景

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

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

圖5 進房場景QPS趨勢圖

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

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

圖7 進房場景緩存命中率

天選時刻

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

圖8 直播間天選時刻

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

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

圖9 天選時刻打散

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

長連接

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

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

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

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

散場場景

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

QPS預估：

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

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

圖12 散場場景的尖刺流量

技術優(yōu)化：

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

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

全局維度關注流量

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

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

保障任務分工

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

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

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

實踐和思考

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

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

圖15 重點保障事項時間線

技術鏈路梳理

技術鏈路梳理需要得到：

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

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

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

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

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

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

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

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

表3 Advisor場景管理

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

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

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

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

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

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

圖18 基于完整鏈路擇選

故障演練

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

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

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

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

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

圖19 Step2示意圖

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

全鏈路壓測

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

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

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

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

圖21 全鏈路提效示意圖

預案SOP

針對故障演練識別到的強依賴路徑，需要做好預案SOP?？梢钥s短MTTR為目標，從1分鐘發(fā)現(xiàn)、5分鐘定位、10分鐘恢復的原則準備預案：

表4 預案SOP模版

變更管控

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

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

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

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

賽中跟蹤

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

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

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

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

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

展望

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

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

本期作者

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

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