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

作者：嗶哩嗶哩工程師 2023-06-30 13:10:54

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

業(yè)務背景

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

圖片

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

從圖一中看到，我們可以將APP上功能的頁面分為兩類：列表頁(ListView Page)，如推薦、搜索、動態(tài)、分區(qū)等等絕大多數頁面都是列表型的，它給用戶提供了豐富的內容篩選和預覽的場景；另一類是詳情頁(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邏輯分拆單獨的應用做到發(fā)布與部署的隔離，例如：app-feed(首頁)，app-view(視頻詳情頁)等。
業(yè)務Service：負責業(yè)務域或能力的接口，通常會按照功能/能力和業(yè)務領域拆分。

圖片

（圖3：應用架構分層）

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

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

圖片

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

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

圖片

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

圖片

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

分析與建模

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

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

圖片

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

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

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

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

圖片

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

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

實現

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

圖片

（圖7：優(yōu)化后的架構與處理流程）

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

HMSET index_vid1234 biz1 0 biz2 1 bizM "hot"

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

圖片

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

架構擴展

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

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

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

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

GraphQL：通過字段選擇器實現所需信息的篩選。GraphQL雖然功能全面且靈活，但是引入會使得系統實現和問題排查的復雜度急劇升高，不利于長期的維護和迭代。(詳見參考2)
Protobuf field mask：Google APIs提出的通過在請求參數中增加google.protobuf.FieldMask類型的字段來指定所需要的返回范圍，旨在減少不需要的返回字段帶來的網絡傳輸海和服務端計算成本。不過，Google APIs已經宣布了read_mask已經處于廢棄狀態(tài)。
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;
    // 可以持續(xù)增加新的場景
}

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

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

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

圖片