DAGW：數據聚合網關的探索與實踐

2023.07.04

DAGW：數據聚合網關的探索與實踐

本文對B站訪問最頻繁的視頻詳情頁的實現技術與fanout read持續增長帶來的問題進行深入分析，提出了構建業務關聯索引的方案有效降低90%以上服務負載。同時針對更多的聚合展示場景提出並實現了一套通用數據聚合網關(DAGW)的解決方案。

業務背景

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》）

圖片

（圖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"1.

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

圖片

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

架構擴展

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

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

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

關於第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;
    // 可以持续增加新的场景
}1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

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

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

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

圖片