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

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

圖片

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

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

圖片

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

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

現(xiàn)狀與問題

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

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

圖片

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

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

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

圖片

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

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

圖片

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

圖片

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

分析與建模

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

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

圖片

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

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

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

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

圖片

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

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

實(shí)現(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實(shí)現(xiàn)，同時(shí)也使用了公司內(nèi)部的KV存儲(chǔ)做持久化和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)信息全量+增量導(dǎo)入構(gòu)建。為了方便下游業(yè)務(wù)的更高效的將異構(gòu)數(shù)據(jù)導(dǎo)入索引，我們提供了一套支持在線進(jìn)行業(yè)務(wù)變更消息清洗與導(dǎo)入函數(shù)編寫的后臺系統(tǒng)。如下圖所示：

圖片

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

架構(gòu)擴(kuò)展

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

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

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

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

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

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

enum ArchiveView {
    //未指定，不返回?cái)?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點(diǎn)，我們將聚合邏輯抽象成DAG圖，之所以使用DAG模型是因?yàn)椴糠謽I(yè)務(wù)Service之間會(huì)存在前后依賴，例如：一些視頻的屬性依賴與視頻基礎(chǔ)信息(通過訪問視頻基礎(chǔ)信息Service獲取)中的視頻作者信息。這樣任何新增的業(yè)務(wù)只需要：1. 指定依賴的其他節(jié)點(diǎn)，2. 編寫節(jié)點(diǎn)內(nèi)的邏輯，包括訪問Service服務(wù)和業(yè)務(wù)邏輯處理，3.配置該節(jié)點(diǎn)應(yīng)該在哪些View Enum的使用。

關(guān)于第3點(diǎn)，前面已經(jīng)介紹過實(shí)現(xiàn)原理，我們只需要：將索引從視頻-業(yè)務(wù)索引擴(kuò)展到直播、用戶-業(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個(gè)業(yè)務(wù)Service接入并平均幫助業(yè)務(wù)Service降低了超過90%的流量和負(fù)載。以下是視頻的高能看點(diǎn)業(yè)務(wù)和用戶的粉絲勛章業(yè)務(wù)接入效果：

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

圖片

2.  粉絲勛章是用戶通過長期觀看主播直播以及參與互動(dòng)獲取的可佩戴的鐵桿粉絲榮譽(yù)，因?yàn)楂@得門檻較高且只有在特定主播內(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ā)工程師