日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

本期作者

周佳輝

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

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)生的各類場(chǎng)景。

始終以簡(jiǎn)單為核心設(shè)計(jì)理念，追求極致簡(jiǎn)單有效的后端架構(gòu)。

背景

如果你在 2015 年就使用 B 站，那么你一定不會(huì)忘記那一年 B 站工作日選擇性崩潰，周末必然性崩潰的一段時(shí)間。也是那一年 B 站投稿量激增，訪問量隨之成倍上升，而過去的 php 全家桶也開始逐漸展露出頹勢(shì)，運(yùn)維難、監(jiān)控難、排查故障難、調(diào)用路徑深不見底，而也就是在這一年，B 站開始正式用 Go 重構(gòu) B 站。

B站第一個(gè) Go 項(xiàng)目：bilizone 由冠冠老師（一個(gè)周末）編碼完成。

commit 4ccb1497ca6d94cec0ea1b2555dd1859e6f4f223Author: felixhao <g******[email protected]>Date: Wed Jul 1 18:55:00 2015 +0800 project initcommit 6e338bc0ee638621e01918adb183747cf2a9e567Author: 郝冠偉 <h*******@bilibili.com>Date: Wed Jul 1 11:21:18 2015 +0800 readme

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)：

• 代碼復(fù)雜度高

  方法被濫用、超時(shí)設(shè)置混亂、牽一發(fā)而動(dòng)全身

• 一掛全掛

  最常見的：超時(shí)設(shè)置不合理，goroutine 大量堆積，雪崩

• 測(cè)試及維護(hù)成本高

  小改動(dòng)都需要測(cè)試所有 case，運(yùn)維發(fā)布膽戰(zhàn)心驚

所以此時(shí)B站的崩潰頻率雖然已經(jīng)有所降低，但一炸全炸的問題依舊是一個(gè)心腹大患。

而再接下來的一次重構(gòu)，B站微服務(wù)的全局面貌就將初具雛形。

為了實(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)一的出口而面臨了不少困難：

• 客戶端與微服務(wù)直接通信，強(qiáng)耦合

• 需要多次請(qǐng)求，客戶端聚合數(shù)據(jù)，工作量巨大，延遲高。

• 協(xié)議不利于統(tǒng)一，各個(gè)部門間有差異，反而需要通過客戶端來兼容。

• 面向“端”的 API 適配，耦合到了內(nèi)部服務(wù)。

• 多終端兼容邏輯復(fù)雜，每個(gè)服務(wù)都需要處理。

• 統(tǒng)一邏輯無法收斂，比如安全認(rèn)證、限流。

基于上述問題和我們想要將對(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ù)場(chǎng)景來設(shè)計(jì)粗粒度的 API，給后續(xù)服務(wù)的演進(jìn)帶來的很多優(yōu)勢(shì)：

• 輕量交互：協(xié)議精簡(jiǎn)、聚合。

• 差異服務(wù)：數(shù)據(jù)裁剪以及聚合、針對(duì)終端定制化 API。

• 動(dòng)態(tài)升級(jí)：原有系統(tǒng)兼容升級(jí)，更新服務(wù)而非協(xié)議。

• 溝通效率提升，協(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ī)所有接口不可用。于是我們?cè)谏鲜龌A(chǔ)上進(jìn)一步迭代，將 app-interface 進(jìn)行業(yè)務(wù)拆分，進(jìn)而多套 BFF 的模式橫空出世：

由此模式開始，基本確定了 B 站微服務(wù)接口的對(duì)接模式，這套模式也隨之在全公司內(nèi)推廣開來。

垂直 BFF 時(shí)代 2016-2019

接上文當(dāng) B 站網(wǎng)關(guān)的架構(gòu)發(fā)展為多套垂直 BFF 之后，開發(fā)團(tuán)隊(duì)圍繞該模式平穩(wěn)迭代了相當(dāng)長(zhǎ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，這里可以簡(jiǎn)單細(xì)說一下粉板 App 上的所有業(yè)務(wù)組成：

主站業(yè)務(wù)

• 網(wǎng)關(guān)組維護(hù)的 BFF，如推薦、稿件播放頁等

• 業(yè)務(wù)層自行維護(hù)的 BFF，如評(píng)論、彈幕、賬號(hào)等

獨(dú)立業(yè)務(wù)

• 電商服務(wù)

• 直播服務(wù)

• 動(dòng)態(tài)服務(wù)

主站業(yè)務(wù)的 BFF 其實(shí)被分為兩類，一類是由網(wǎng)關(guān)組負(fù)責(zé)的 BFF，另一類是業(yè)務(wù)自行維護(hù)的 BFF。

而這兩類 BFF 的技術(shù)棧其實(shí)基本一致，基本功能職責(zé)也相差不多，如此劃分的原因是讓網(wǎng)關(guān)組可以更專注于迭代客戶端特性功能，免去理解部分獨(dú)立業(yè)務(wù)場(chǎng)景的接口，如登陸頁應(yīng)該讓對(duì)安全更專業(yè)賬號(hào)的同學(xué)自行維護(hù)。在這里我們也可以簡(jiǎn)述一下一個(gè)新需求應(yīng)該如何決定參與的 BFF ：

• 如果這個(gè)功能能由業(yè)務(wù)層的業(yè)務(wù) BFF 獨(dú)立完成，則網(wǎng)關(guān)組不需介入。

• 如果該功能是一個(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)行直接交互。

再談一談電商、直播和動(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ù)功能。因此我們可以簡(jiǎn)單理解為直播使用由 PHP 編寫的 BFF 網(wǎng)關(guān)。

動(dòng)態(tài)團(tuán)隊(duì)其實(shí)派生自直播團(tuán)隊(duì)，因此技術(shù)棧和直播當(dāng)時(shí)基本一致，這里可以簡(jiǎn)單省略。

而眾所周知，大部分電商團(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ù)的增長(zhǎng)，進(jìn)而經(jīng)歷了諸多線上故障、事故分析之后，大家慢慢發(fā)現(xiàn)了這套架構(gòu)下的問題：

• 單個(gè)復(fù)雜模塊也會(huì)導(dǎo)致后續(xù)業(yè)務(wù)集成的高難度，根據(jù)康威法則，復(fù)雜聚合型 BFF 和多團(tuán)隊(duì)之間就出現(xiàn)不匹配問題，團(tuán)隊(duì)之間溝通協(xié)調(diào)成本高，交付效率低下。

• 很多跨橫切面邏輯，比如安全認(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)而大家開始引入「統(tǒng)一 API 網(wǎng)關(guān)」。

在新的架構(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）。

從多個(gè)網(wǎng)關(guān)到最后一個(gè)統(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)營(yíng)方式不統(tǒng)一無法起到 API 網(wǎng)關(guān)所帶來的最佳收益。

因此微服務(wù)團(tuán)隊(duì)開發(fā)了一款 B 站內(nèi)部意義上的標(biāo)準(zhǔn) 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)階型 API 質(zhì)量治理的相關(guān)功能，這些功能業(yè)務(wù)團(tuán)隊(duì)在接入 API 網(wǎng)關(guān)后都可以一并獲得，為業(yè)務(wù)的迅速迭代做出力所能及的保障。

不僅僅是 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)，如：

• 規(guī)劃 API 業(yè)務(wù)域，簡(jiǎn)化 SRE 運(yùn)維

• 標(biāo)準(zhǔn) API 元信息平臺(tái)

• 精確的 API 文檔和調(diào)試工具

• 類型安全的 API 集成 SDK

• 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)行開發(fā)，在這里歡迎大家指導(dǎo)：
https://github.com/go-kratos/gateway

本文由高可用架構(gòu)翻譯。技術(shù)原創(chuàng)及架構(gòu)實(shí)踐文章，歡迎通過公眾號(hào)菜單「聯(lián)系我們」進(jìn)行投稿。

高可用架構(gòu)

改變互聯(lián)網(wǎng)的構(gòu)建方式