業務背景

B站是一個以PUGV為主的視頻社區，用戶使用的最主要場景是在視頻詳情頁觀看視頻。隨著業務發展壯大，在這個「主戰場」上會有越來越多的擴展業務，例如：話題、視頻榮譽、筆記、用戶裝扮等等。

圖片

(圖1：所有流量都會匯聚到視頻詳情頁)

從圖一中看到，我們可以將APP上功能的頁面分為兩類：列表頁(ListView Page)，如推薦、搜索、動態、分區等等絕大多數頁面都是列表型的，它給用戶提供了豐富的內容篩選和預覽的場景；另一類是詳情頁(DetailView Page)，當用戶在任何列表頁點擊感興趣的內容時，都會匯入到詳情頁觀看。

圖片

（圖2：視頻詳情頁聚集了視頻關聯的多種信息與功能入口）

從圖2可以看到，視頻詳情頁聚集了該視頻相關的屬性和功能入口，例如：熱門、全站排行榜、每周必看等稿件榮譽，視頻拍攝模板，視頻合集，視頻配樂以及所屬話題等等信息。這些信息以及入口可以幫助用戶進一步地探索相關的主題內容和功能。

現狀與問題

在技術實現上，B站面向用戶的應用架構主要分為四層：

• 終端層：直接與用戶交互的客戶端，包括手機APP、H5，PC上Web和客戶端，以及其他屏幕終端，例如：TV，車載，音響以及PS等等。
• 接入網關：一般為LB(Load Balance)加AGW(API-Gateway)， AGW主要會負責請求路由，協議轉換，協議卸載，限流熔斷，安全封禁等。
• BFF(Backend for Frontend)：由于終端的增加，為了保證client-specific的邏輯能夠做到比較好的隔離，通常實踐會按終端拆分應用，例如：web-interface(面向網頁)，app-interface(面向APP)，tv-interface(面向電視端)等等。除此之外，由于頁面邏輯越來越復雜，流量越來越大，也會將頁面的BFF邏輯分拆單獨的應用做到發布與部署的隔離，例如：app-feed(首頁)，app-view(視頻詳情頁)等。
• 業務Service：負責業務域或能力的接口，通常會按照功能/能力和業務領域拆分。

圖片

（圖3：應用架構分層）

由圖3可以看出，視頻詳情頁的主要邏輯集中在BFF層，隨著DAU增長以及業務的不斷擴展，我們面臨了兩個問題：

問題一：讀擴散(fanout read)的數量隨著業務擴展越來越大，對BFF自身以及下游業務都帶來巨大流量負載和復雜度。如下圖所示，為了展示關聯視頻的功能入口，業務Service需要一方面承載所有視頻詳情請求的流量以及帶來的CPU資源消耗；另一方面還需要通過實現類似bloom filter機制來避免所有未關聯視頻請求帶來的大量回源查詢。

圖片

（圖4：負載隨BFF的讀擴散無差別的放大到所有Service，并帶來Service的實現復雜化）

問題二：或許問題一我們可以通過增加機器和實現復雜度來解決，但是隨著fanout read的擴散數不斷增加，單個視頻詳情請求latency會持續惡化，直到用戶不可接受。(圖4.a【參考1】，fanout數增加會大幅增加整體請求超時的概率。圖4.b 是真實的Bilibili APP視頻詳情BFF的fanout請求拓撲，已經比較龐大(圖已經看不清了)，而且fanout個數還在不斷隨著業務增加而持續增加。)

圖片

（圖4.a fanout數與超時率的相關性，摘自《The Tail At Scale》）

圖片

1. （圖 4.b 視頻詳情頁BFF的fanout實際情況，通過內部Trace系統繪制）

分析與建模

如上文提到的，很多視頻詳情的下游業務Service僅僅覆蓋了部分視頻，即只有部分視頻有關聯數據，所以常常會使用類BloomFilter的機制來過濾未關聯視頻的請求。

我們對視頻詳情BFF請求下游的Response大小進行分桶打點(使用Prometheus Histogram打點)。進過分析發現，有較多的業務Service返回的Response呈現出下圖所示的分布：

圖片

（圖5：BFF請求Service返回包大小分布）

可以看出，BFF訪問的不少業務Service接口Response 90%以上都為“空”，即代表請求的視頻并沒有關聯該業務。但是在實現上，視頻詳情BFF在每次獲取視頻詳情信息都會請求這些業務，根本原因是在BFF層在處理請求時并不知道視頻關聯了哪些業務。

如果我們可以在BFF層提前知道本次請求的視頻關聯了哪些業務，就可以大幅降低BFF的讀擴散數量和業務Service的負載，做到按需訪問。

我們可以給每個視頻建立一個包含其關聯業務的稀疏向量，稱為視頻-業務索引。如下圖所示：

圖片

（圖6：視頻id與所關聯業務的索引模型）

在實際落地實現時，視頻業務索引并不一定以稀疏向量的方式存儲視頻與業務的關聯關系，可以使用一些現成的kv系統。例如我們是用redis的hash key來實現的。另外需要考慮的是，當業務與視頻關聯關系發生變化時，需要有全量(初始階段)和增量的將變更通知到索引服務進的機制。

實現

基于前面的問題分析與建模，我們將視頻詳情BFF的架構優化為如下圖所示：

圖片

（圖7：優化后的架構與處理流程）

在BFF請求處理流程中，①引入了業務關聯索引服務，在BFF請求下游業務Service前通過獲取視頻關聯業務的索引，②提前獲取本次請求應該訪問的哪些業務Service將不相關的業務請求過濾掉。索引是通過redis的hashmap實現，同時也使用了公司內部的KV存儲做持久化和redis故障降級。redis的key設置示例如下：

HMSET index_vid1234 biz1 0 biz2 1 bizM "hot"

視頻關聯業務的索引構建是通過將下游業務的關聯信息全量+增量導入構建。為了方便下游業務的更高效的將異構數據導入索引，我們提供了一套支持在線進行業務變更消息清洗與導入函數編寫的后臺系統。如下圖所示：

圖片

（圖8：業務變更事件處理函數與索引更新推送后臺）

架構擴展

經過我們進一步的調研發現：不僅僅是視頻詳情，Story(短視頻)、直播、動態和我的頁等詳情頁都呈現出類似的聚合場景，而且如圖3這些聚合場景也會同時出現在APP、TV、Web等多個端對應的BFF中。那是否可以通過一套更加標準且通用的方案來統一解決類似視頻詳情的聚合問題？

如前文圖3所示，BFF的主要處理邏輯分為：參數處理，聚合邏輯，返回對象(VO)的組裝。我們可以將視頻、直播、用戶等復雜的聚合邏輯抽象成更為通用聚合服務，提供給所有BFF使用。要做到這點，通用聚合服務需要具備以下能力：

1. 支持不同終端BFF按需獲取聚合模型。
2. 支持更加靈活的擴展聚合模型，即在滿足1的基礎上拓展一個新業務的成本盡可能的低。
3. 支持前面基于業務關聯索引進行降低負載的能力。

關于第1點，業界常見的做法包括以下幾種：

• GraphQL：通過字段選擇器實現所需信息的篩選。GraphQL雖然功能全面且靈活，但是引入會使得系統實現和問題排查的復雜度急劇升高，不利于長期的維護和迭代。(詳見參考2)
• Protobuf field mask：Google APIs提出的通過在請求參數中增加google.protobuf.FieldMask類型的字段來指定所需要的返回范圍，旨在減少不需要的返回字段帶來的網絡傳輸海和服務端計算成本。不過，Google APIs已經宣布了read_mask已經處于廢棄狀態。
• View Enum：為了滿足field mask的按需獲取機制，Google APIs提供了一種更好的替代方案(詳見參考3)。通過定義View Enum，由服務提供方定義常見的按需訪問場景，例如：BASIC返回基本信息并用于列表場景，ALL用于返回詳情用于詳情頁場景。同時也支持更加豐富的枚舉定義，這正好契合了我們的需求。

以下是我們針對視頻詳情頁的View Enum定義：

enum ArchiveView {
    //未指定，不返回數據
    UNSPECIFIED = 0;
    // 以下是最常見場景的視圖定義
    // 返回稿件簡易信息（用于信息查詢）
    SIMPLE = 1;
    // 返回稿件基礎信息（可用于首頁、搜索列表查詢）
    BASIC = 2;
    // 返回稿件基礎信息+分P信息（最簡版詳情，用于分享等場景）
    BASIC_WITH_PAGES = 3;
    // 返回APP端視頻詳情所有信息
    ALL_APP = 4;
    // 返回WEB端視頻詳情所有信息
    ALL_WEB = 5;
    // 返回TV端視頻詳情所有信息
    ALL_TV = 6;
    // 可以持續增加新的場景
}

關于第2點，我們將聚合邏輯抽象成DAG圖，之所以使用DAG模型是因為部分業務Service之間會存在前后依賴，例如：一些視頻的屬性依賴與視頻基礎信息(通過訪問視頻基礎信息Service獲取)中的視頻作者信息。這樣任何新增的業務只需要：1. 指定依賴的其他節點，2. 編寫節點內的邏輯，包括訪問Service服務和業務邏輯處理，3.配置該節點應該在哪些View Enum的使用。

關于第3點，前面已經介紹過實現原理，我們只需要：將索引從視頻-業務索引擴展到直播、用戶-業務的索引即可。

綜上所述，我們將通用數據聚合服務命名為DAGW(Data Aggregate Gateway)，DAGW的內部結構以及與BFF層以及Service的交互如下圖所示：

圖片

（圖9：引入通用數據聚合網關層DAGW統一滿足聚合場景需求）

效果

DAGW通用數據聚合網關以及業務關聯索引上線后，支持了視頻、用戶等信息聚合能力，已經有近30個業務Service接入并平均幫助業務Service降低了超過90%的流量和負載。以下是視頻的高能看點業務和用戶的粉絲勛章業務接入效果：

1.  視頻的高能看點業務Service的流量中，來自播放頁(app-view)的流量高峰時期達到100k+ QPS，經過接入DAGW優化后效果非常顯著，下圖監控中可以看出來請求QPS降低了99%。

圖片

2.  粉絲勛章是用戶通過長期觀看主播直播以及參與互動獲取的可佩戴的鐵桿粉絲榮譽，因為獲得門檻較高且只有在特定主播內容下才展示，通過接入DAGW后，可以有效降低85%以上的訪問流量。

參考

1. The Tail at Scale：https://research.google/pubs/pub40801/

2. GraphQL: From Excitement to Deception：https://betterprogramming.pub/graphql-from-excitement-to-deception-f81f7c95b7cf

3. View Enum：https://google.aip.dev/157

本期作者

黃山成

嗶哩嗶哩資深開發工程師

夏琳娟

嗶哩嗶哩資深開發工程師

趙丹丹

嗶哩嗶哩資深開發工程師