業(yè)務(wù)背景

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

圖片

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

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

圖片

（圖2：視頻詳情頁聚集了視頻關(guān)聯(lián)的多種信息與功能入口）

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

現(xiàn)狀與問題

在技術(shù)實現(xiàn)上，B站面向用戶的應(yīng)用架構(gòu)主要分為四層：

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

圖片

（圖3：應(yīng)用架構(gòu)分層）

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

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

圖片

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

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

圖片

（圖4.a fanout數(shù)與超時率的相關(guān)性，摘自《The Tail At Scale》）

圖片

1. （圖 4.b 視頻詳情頁BFF的fanout實際情況，通過內(nèi)部Trace系統(tǒng)繪制）

分析與建模

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

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

圖片

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

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

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

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

圖片

（圖6：視頻id與所關(guān)聯(lián)業(yè)務(wù)的索引模型）

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

實現(xiàn)

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

圖片

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

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

HMSET index_vid1234 biz1 0 biz2 1 bizM "hot"

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

圖片

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

架構(gòu)擴展

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

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

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

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

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

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

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

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

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

綜上所述，我們將通用數(shù)據(jù)聚合服務(wù)命名為DAGW(Data Aggregate Gateway)，DAGW的內(nèi)部結(jié)構(gòu)以及與BFF層以及Service的交互如下圖所示：

圖片

（圖9：引入通用數(shù)據(jù)聚合網(wǎng)關(guān)層DAGW統(tǒng)一滿足聚合場景需求）

效果

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

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

圖片

2.  粉絲勛章是用戶通過長期觀看主播直播以及參與互動獲取的可佩戴的鐵桿粉絲榮譽，因為獲得門檻較高且只有在特定主播內(nèi)容下才展示，通過接入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

本期作者

黃山成

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

夏琳娟

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

趙丹丹

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