本文由B站微服務(wù)技術(shù)團(tuán)隊(duì)資深開發(fā)工程師周佳輝原創(chuàng)分享。
1、引言
如果你在 2015 年就使用 B 站，那么你一定不會(huì)忘記那一年 B 站工作日選擇性崩潰，周末必然性崩潰的一段時(shí)間。
也是那一年 B 站投稿量激增，訪問量隨之成倍上升，而過去的 PHP 全家桶也開始逐漸展露出頹勢，運(yùn)維難、監(jiān)控難、排查故障難、調(diào)用路徑深不見底。
也就是在這一年，B 站開始正式用 Go 重構(gòu) B 站，從此B站的API網(wǎng)關(guān)技術(shù)子開始了從0到1的持續(xù)演進(jìn)。。。
* 補(bǔ)充說明：本次 API 網(wǎng)關(guān)演進(jìn)也以開源形式進(jìn)行了開發(fā)，源碼詳見本文“12、本文源碼”。
PS：本文分享的API網(wǎng)關(guān)涉及到的主要是HTTP短連接，雖然跟長連接技術(shù)有些差異，但從架構(gòu)設(shè)計(jì)思路和實(shí)踐上是一脈相承的，所以也就收錄到了本《長連接網(wǎng)關(guān)技術(shù)專題》系列文章中。
學(xué)習(xí)交流：
（本文已同步發(fā)布于：http://www.52im.net/thread-3941-1-1.html）
2、關(guān)于作者
周佳輝：嗶哩嗶哩資深開發(fā)工程師。始終以簡單為核心的技術(shù)設(shè)計(jì)理念，追求極致簡單有效的后端架構(gòu)。
2017 年加入 B 站，先后從事賬號(hào)、網(wǎng)關(guān)、基礎(chǔ)庫等開發(fā)工作。編碼 C/V 技能傳授者，技術(shù)文檔背誦者。開源社區(qū)愛好者，安全技術(shù)愛好者，云計(jì)算行業(yè)活躍用戶，網(wǎng)絡(luò)工程熟練工。史詩級(jí) bug 生產(chǎn)者，熟練掌握 bug 產(chǎn)生的各類場景。
3、專題目錄
本文是專題系列文章的第8篇，總目錄如下：
4、正式用Go重構(gòu)B站
鑒于引言中所列舉的各種技術(shù)問題，也是在2015年，財(cái)隊(duì)開始正式用 Go 重構(gòu) B 站。
B站第一個(gè) Go 項(xiàng)目——bilizone，由冠冠老師（郝冠偉）花了一個(gè)周末時(shí)間編碼完成。
commit 4ccb1497ca6d94cec0ea1b2555dd1859e6f4f223
Author: felixhao <g******[url=mailto:1@gmail.com]1@gmail.com[/url]>
Date: Wed Jul 1 18:55:00 2015 +0800
project init
commit 6e338bc0ee638621e01918adb183747cf2a9e567
Author: 郝冠偉 <h*******@bilibili.com>
Date: Wed Jul 1 11:21:18 2015 +0800
readme
▲ 郝冠偉：嗶哩嗶哩主站技術(shù)中心架構(gòu)師
bilizone 其實(shí)還是一個(gè)大而全的應(yīng)用，bilizone 在當(dāng)時(shí)重構(gòu)的主要意義是將誰也理不清的 PHP 邏輯梳理成了一個(gè)比較標(biāo)準(zhǔn)的 Go 應(yīng)用。
bilizone 在當(dāng)時(shí)最大的意義就是為用戶終端提供了基本穩(wěn)定的數(shù)據(jù)結(jié)構(gòu)、相對(duì)可靠的接口和比較有效的監(jiān)控。
但因 bilizone 依舊是一個(gè)單體應(yīng)用，所以它依舊繼承了單體應(yīng)用所具有的缺點(diǎn)：
- 1）代碼復(fù)雜度高：方法被濫用、超時(shí)設(shè)置混亂、牽一發(fā)而動(dòng)全身；
- 2）一掛全掛：最常見的比如，超時(shí)設(shè)置不合理、goroutine 大量堆積、雪崩；
- 3）測試及維護(hù)成本高：小改動(dòng)都需要測試所有 case，運(yùn)維發(fā)布膽戰(zhàn)心驚。
所以此時(shí)B站的崩潰頻率雖然已經(jīng)有所降低，但一炸全炸的問題依舊是一個(gè)心腹大患。
5、基于微服務(wù)的B站架構(gòu)初具雛形
鑒于bilizone所面臨的單體應(yīng)用技術(shù)缺點(diǎn)，接下來的一次重構(gòu)，讓B站基于微服務(wù)的全局架構(gòu)面貌就將初具雛形。
為了實(shí)現(xiàn)微服務(wù)模式下的 bilibili，我們將一個(gè) bilizone 應(yīng)用拆分成多個(gè)獨(dú)立業(yè)務(wù)應(yīng)用，如賬號(hào)、稿件、廣告等等，這些業(yè)務(wù)通過 SLB 直接對(duì)外提供 API。
當(dāng)時(shí)的調(diào)用模式如下圖所示：
但是隨著功能拆分后，我們對(duì)外暴露了一批微服務(wù)，但是因?yàn)槿狈y(tǒng)一的出口而面臨了不少困難。
這些困難主要是：
- 1）客戶端與微服務(wù)直接通信，強(qiáng)耦合；
- 2）需要多次請(qǐng)求，客戶端聚合數(shù)據(jù)，工作量巨大，延遲高；
- 3）協(xié)議不利于統(tǒng)一，各個(gè)部門間有差異，反而需要通過客戶端來兼容；
- 4）面向“端”的 API 適配，耦合到了內(nèi)部服務(wù)；
- 5）多終端兼容邏輯復(fù)雜，每個(gè)服務(wù)都需要處理；
- 6）統(tǒng)一邏輯無法收斂，比如安全認(rèn)證、限流。
6、基于BFF模式的微服務(wù)架構(gòu)
基于上節(jié)的初階微服務(wù)架構(gòu)帶來的技術(shù)問題，以及我們想要將對(duì)端的處理進(jìn)行內(nèi)聚的想法，我們自然的而然的就想到在客戶端與后端服務(wù)之間加一個(gè) app-interface 的組件，這就是接下來的 BFF（Backend for Frontend）模式。
app-interface 的工作模式如下圖所示：
有了這個(gè) BFF 之后，我們可以在該服務(wù)內(nèi)進(jìn)行大量的數(shù)據(jù)聚合，按照業(yè)務(wù)場景來設(shè)計(jì)粗粒度的 API。
這樣，后續(xù)服務(wù)的演進(jìn)也帶來了很多優(yōu)勢：
- 1）輕量交互：協(xié)議精簡、聚合；
- 2）差異服務(wù)：數(shù)據(jù)裁剪以及聚合、針對(duì)終端定制化 API；
- 3）動(dòng)態(tài)升級(jí)：原有系統(tǒng)兼容升級(jí)，更新服務(wù)而非協(xié)議；
- 4）溝通效率提升：協(xié)作模式演進(jìn)為移動(dòng)業(yè)務(wù)和網(wǎng)關(guān)小組。
BFF 可以認(rèn)為是一種適配服務(wù)，將后端的微服務(wù)為客戶端的需要進(jìn)行適配（主要包括聚合裁剪和格式適配等邏輯），向終端設(shè)備暴露友好和統(tǒng)一的 API，方便無線設(shè)備接入訪問后端服務(wù)，在其中可能還伴隨有埋點(diǎn)、日志、統(tǒng)計(jì)等需求。
然而，這個(gè)時(shí)期的 BFF 還有一個(gè)致命的一個(gè)問題是——整個(gè) app-interface 屬于 single point of failure，嚴(yán)重代碼缺陷或者流量洪峰可能引發(fā)集群宕機(jī)所有接口不可用。
7、基于多套BFF模式的微服務(wù)架構(gòu)
針對(duì)上節(jié)中BFF模式下架構(gòu)的技術(shù)問題，于是我們?cè)谏鲜龌A(chǔ)上進(jìn)一步迭代，將 app-interface 進(jìn)行業(yè)務(wù)拆分。
進(jìn)而多套 BFF 的模式橫空出世：
由此模式開始，基本確定了 B 站微服務(wù)接口的對(duì)接模式，這套模式也隨之在全公司內(nèi)推廣開來。
8、垂直BFF模式時(shí)代（2016年至2019年）
接上節(jié)，當(dāng) B 站網(wǎng)關(guān)的架構(gòu)發(fā)展為多套垂直 BFF 之后，開發(fā)團(tuán)隊(duì)圍繞該模式平穩(wěn)迭代了相當(dāng)長的一段時(shí)間。
而后隨著B站業(yè)務(wù)的發(fā)展，團(tuán)隊(duì)人員的擴(kuò)充和幾次組織架構(gòu)調(diào)整，此時(shí)開始出現(xiàn)直播、電商等獨(dú)立業(yè)務(wù)，這些業(yè)務(wù)的發(fā)展我們之后再細(xì)說。
而在這些調(diào)整之后，有一個(gè)團(tuán)隊(duì)的職責(zé)越來越清晰：主站網(wǎng)關(guān)組。
主站網(wǎng)關(guān)組的主要職責(zé)就是維護(hù)上述各類功能的 BFF 網(wǎng)關(guān)，此時(shí) bilibili 的主要流量入口為粉板 App。這里可以簡單細(xì)說一下粉板 App 上的所有業(yè)務(wù)組成。
主站業(yè)務(wù)：
- 1）網(wǎng)關(guān)組維護(hù)的 BFF，如推薦、稿件播放頁等；
- 2）業(yè)務(wù)層自行維護(hù)的 BFF，如評(píng)論、彈幕、賬號(hào)等。
獨(dú)立業(yè)務(wù)：
- 1）電商服務(wù)；
- 2）直播服務(wù)；
- 3）動(dòng)態(tài)服務(wù)。
主站業(yè)務(wù)的 BFF 其實(shí)被分為兩類：
- 1）一類是由網(wǎng)關(guān)組負(fù)責(zé)的 BFF；
- 2）另一類是業(yè)務(wù)自行維護(hù)的 BFF。
而這兩類 BFF 的技術(shù)棧其實(shí)基本一致，基本功能職責(zé)也相差不多。如此劃分的原因是讓網(wǎng)關(guān)組可以更專注于迭代客戶端特性功能，免去理解部分獨(dú)立業(yè)務(wù)場景的接口，如登陸頁應(yīng)該讓對(duì)安全更專業(yè)賬號(hào)的同學(xué)自行維護(hù)。
在這里我們也可以簡述一下，一個(gè)新需求應(yīng)該如何決定參與的 BFF ：
- 1）如果這個(gè)功能能由業(yè)務(wù)層的業(yè)務(wù) BFF 獨(dú)立完成，則網(wǎng)關(guān)組不需介入；
- 2）如果該功能是一個(gè)客戶端特性需求，如推薦流等復(fù)合型業(yè)務(wù)，需要對(duì)接公司大量部門時(shí)，則由網(wǎng)關(guān)同學(xué)參與開發(fā) BFF。
當(dāng)時(shí)主站技術(shù)部的后端同學(xué)遵循以上兩個(gè)規(guī)則，基本能夠滿足業(yè)務(wù)的快速開發(fā)和迭代。
我把這段時(shí)間稱為垂直 BFF 時(shí)代，因?yàn)榛局髡久總€(gè)業(yè)務(wù)或多或少都有各種形式的網(wǎng)關(guān)存在，大家通過這個(gè)網(wǎng)關(guān)向外提供接口，該網(wǎng)關(guān)和 SLB 進(jìn)行直接交互。
9、基于業(yè)務(wù)的統(tǒng)一API網(wǎng)關(guān)架構(gòu)
接上節(jié)，我們?cè)賮碚勔徽剮醉?xiàng)重要的業(yè)務(wù)：電商、直播和動(dòng)態(tài)。
電商和直播其實(shí)并不是同一時(shí)期衍生的，直播在主站 PHP 時(shí)期就誕生了，而電商相對(duì)更晚一些。
當(dāng)時(shí)直播的技術(shù)棧組成有 C++、PHP、Go，其中早期大部分業(yè)務(wù)邏輯由 PHP 和 C++ 實(shí)現(xiàn)，稍晚一些也開始逐步試用主站的 Go 實(shí)現(xiàn)部分業(yè)務(wù)邏輯。其中 PHP 負(fù)責(zé)對(duì)終端提供接口，C++ 主要實(shí)現(xiàn)核心業(yè)務(wù)功能。因此我們可以簡單理解為直播使用由 PHP 編寫的 BFF 網(wǎng)關(guān)。
動(dòng)態(tài)團(tuán)隊(duì)其實(shí)派生自直播團(tuán)隊(duì)，因此技術(shù)棧和直播當(dāng)時(shí)基本一致，這里可以簡單省略。
而眾所周知，大部分電商團(tuán)隊(duì)的技術(shù)棧都是 Java 和 Spring 或 Dubbo。
因這幾個(gè)業(yè)務(wù)實(shí)現(xiàn)上幾乎沒有相似的地方，且大家對(duì) gRPC 協(xié)議逐漸地認(rèn)同，因此技術(shù)棧上大家基本沒有大一統(tǒng)的想法，互相能調(diào)通即可。
而隨著 B 站團(tuán)隊(duì)進(jìn)一步的壯大、流量持續(xù)的增長，進(jìn)而經(jīng)歷了諸多線上故障、事故分析之后，大家慢慢發(fā)現(xiàn)了這套架構(gòu)下的各種問題。
這些問題主要是：
- 1）單個(gè)復(fù)雜模塊也會(huì)導(dǎo)致后續(xù)業(yè)務(wù)集成的高難度，根據(jù)康威法則，復(fù)雜聚合型 BFF 和多團(tuán)隊(duì)之間就出現(xiàn)不匹配問題，團(tuán)隊(duì)之間溝通協(xié)調(diào)成本高，交付效率低下；
- 2）很多跨橫切面邏輯，比如安全認(rèn)證，日志監(jiān)控，限流熔斷等。隨著時(shí)間的推移，功能的迭代，代碼變得越來越復(fù)雜，技術(shù)債越堆越多。
此時(shí)：我們可能還需要一個(gè)能協(xié)調(diào)橫跨切面的組件，將路由、認(rèn)證、限流、安全等組件全部上提，能夠統(tǒng)一更新發(fā)布，把業(yè)務(wù)集成度高的 BFF 層和通用功能服務(wù)層進(jìn)行分層，進(jìn)而大家開始引入基于業(yè)務(wù)的“統(tǒng)一API網(wǎng)關(guān)”架構(gòu)（如下圖所示）。
在新的架構(gòu)中：統(tǒng)一網(wǎng)關(guān)承擔(dān)了重要的角色，它是解耦拆分和后續(xù)升級(jí)遷移的利器。
在統(tǒng)一網(wǎng)關(guān)的配合下：單塊 BFF 實(shí)現(xiàn)了解耦拆分，各業(yè)務(wù)線團(tuán)隊(duì)可以獨(dú)立開發(fā)和交付各自的微服務(wù)，研發(fā)效率大大提升。
另外：把跨橫切面邏輯從 BFF 剝離到網(wǎng)關(guān)上去以后，BFF 的開發(fā)人員可以更加專注業(yè)務(wù)邏輯交付，實(shí)現(xiàn)了架構(gòu)上的關(guān)注分離（Separation of Concerns）。
10、從基于業(yè)務(wù)的多網(wǎng)關(guān)到全局統(tǒng)一網(wǎng)關(guān)（2022年至今）
在這兩三年的時(shí)間里，各個(gè)業(yè)務(wù)團(tuán)隊(duì)或多或少都有自己業(yè)務(wù)網(wǎng)關(guān)組建獨(dú)立的維護(hù)團(tuán)隊(duì)，也為網(wǎng)關(guān)的功能作出過相當(dāng)多的投入。
但隨著 B 站業(yè)務(wù)的發(fā)展，公司級(jí)中間件功能的不斷更替演進(jìn)，如果將對(duì)接各個(gè)中間件的工作在每個(gè)網(wǎng)關(guān)上都實(shí)現(xiàn)一次的話帶來的人力投入和溝通成本會(huì)相當(dāng)巨大，且實(shí)現(xiàn)標(biāo)準(zhǔn)不統(tǒng)一、運(yùn)營方式不統(tǒng)一無法起到 API 網(wǎng)關(guān)所帶來的最佳收益。
因此微服務(wù)團(tuán)隊(duì)開發(fā)了一款 B 站內(nèi)部意義上的標(biāo)準(zhǔn) API 網(wǎng)關(guān)（全局統(tǒng)一API網(wǎng)關(guān)），該 API 網(wǎng)關(guān)匯集以往各型網(wǎng)關(guān)中流量治理的優(yōu)秀經(jīng)驗(yàn)，對(duì)相關(guān)功能做出完善設(shè)計(jì)改進(jìn)。
該 API 網(wǎng)關(guān)的目前的主要功能除了常規(guī)的限流、熔斷、降級(jí)、染色外，還會(huì)基于這些基礎(chǔ)功能和公司各類中間件的基礎(chǔ)上，提供各種額外能力。
這些額外進(jìn)階型AP 質(zhì)量治理的相關(guān)功能主要是：
- 1）全鏈路灰度；
- 2）流量采樣分析、回放；
- 3）流量安全控制；
- ...
業(yè)務(wù)團(tuán)隊(duì)在接入 API 網(wǎng)關(guān)后都可以一并獲得這些功能，為業(yè)務(wù)的迅速迭代做出力所能及的保障。
11、不僅僅是 API 網(wǎng)關(guān)
在開發(fā) API 網(wǎng)關(guān)的同時(shí)，我們也會(huì)更進(jìn)一步關(guān)注業(yè)務(wù)團(tuán)隊(duì)開發(fā)、對(duì)接 API 時(shí)的體驗(yàn)，我們將以網(wǎng)關(guān)作為統(tǒng)一標(biāo)準(zhǔn) API 規(guī)范的起點(diǎn)，為業(yè)務(wù)團(tuán)隊(duì)提供更有效的 API 開發(fā)生態(tài)。
這些API 開發(fā)生態(tài)可能是：
- 1）規(guī)劃 API 業(yè)務(wù)域，簡化 SRE 運(yùn)維；
- 2）標(biāo)準(zhǔn) API 元信息平臺(tái)；
- 3）精確的 API 文檔和調(diào)試工具；
- 4）類型安全的 API 集成 SDK；
- 5）API 兼容性保障服務(wù)。
API 網(wǎng)關(guān)是我們 API 治理生態(tài)中的一個(gè)標(biāo)志性里程碑，我們希望在 API 網(wǎng)關(guān)的開發(fā)中能夠多多傾聽大家的意見，希望能有更多的聲音來幫助我們理清思路。
本次 API 網(wǎng)關(guān)演進(jìn)也以開源形式進(jìn)行了開發(fā)，在這里歡迎大家指導(dǎo)（本次源碼詳見本文“12、本文源碼”）。
12、本文源碼
主地址：https://github.com/go-kratos/gateway
備地址：https://github.com/52im/gateway
或從原文鏈接中下載附件：http://www.52im.net/thread-3941-1-1.html
13、參考資料
[1] 喜馬拉雅自研億級(jí)API網(wǎng)關(guān)技術(shù)實(shí)踐
[2] 手淘億級(jí)移動(dòng)端接入層網(wǎng)關(guān)的技術(shù)演進(jìn)之路
[3] 從100到1000萬高并發(fā)的架構(gòu)演進(jìn)之路
[4] 一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面
[5] 零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐
（本文已同步發(fā)布于：http://www.52im.net/thread-3941-1-1.html）