微服務(wù)設(shè)計(jì)中，BFF層是個什么東西？

2025-02-27 11:05:03

在 API 服務(wù)層做一個攔截器，如果 URI 找不到對應(yīng) API 服務(wù)中的 controller mapping，就會直接通過 URI 找后臺服務(wù)并進(jìn)行調(diào)用。

在我們之前設(shè)計(jì)的一個供應(yīng)鏈系統(tǒng)中，它包含了商品、銷售訂單、加盟商、門店運(yùn)營、門店工單等服務(wù)，涉及了各種用戶角色，比如總部商品管理、總部門店管理、加盟商員工、門店人員等，而且每個部門的角色還會進(jìn)行細(xì)分。而且這個系統(tǒng)中還包含了兩個客戶端 App：一個面向客戶，另一個面向公司員工和加盟商。

此時，整個供應(yīng)鏈系統(tǒng)的架構(gòu)如下圖所示：

圖片

上圖中的網(wǎng)關(guān)層主要負(fù)責(zé)路由、認(rèn)證、監(jiān)控、限流熔斷等工作。

路由：所有的請求都需要通過網(wǎng)關(guān)層進(jìn)行處理，網(wǎng)關(guān)層再根據(jù) URI 將請求指向?qū)?yīng)的后臺服務(wù)，如果同一個服務(wù)存在多個服務(wù)器節(jié)點(diǎn)，網(wǎng)關(guān)層還將承擔(dān)負(fù)載均衡的工作。
認(rèn)證：對所有的請求進(jìn)行集中認(rèn)證鑒權(quán)。
監(jiān)控：記錄所有的 API 請求數(shù)據(jù)，API 管理系統(tǒng)能對 API 調(diào)用實(shí)現(xiàn)管理和性能監(jiān)控。
限流熔斷：流量過大時，我們可以在網(wǎng)關(guān)層實(shí)現(xiàn)限流。如果后臺服務(wù)響應(yīng)延時或故障，我們可以主動在調(diào)用端的上游服務(wù)做熔斷，以此保護(hù)后端服務(wù)資源，同時不影響用戶體驗(yàn)。

此時，我們的架構(gòu)看起來是不是挺完美？且市面上標(biāo)準(zhǔn)的 Spring Cloud 架構(gòu)都是這樣做的。不過，這個架構(gòu)會出現(xiàn)一些問題，下面我們先通過幾個例子來看看。

案例一：

在這個供應(yīng)鏈系統(tǒng)中，很多界面都需要顯示多個服務(wù)數(shù)據(jù)，比如在一個 App 首頁中，針對門店運(yùn)營人員，需要顯示工單數(shù)量、最近的工單、銷售訂單數(shù)據(jù)、最近待處理的訂單、低于庫存安全值的商品等信息。

此時第一個問題來了，在接口設(shè)計(jì)過程中，我們經(jīng)常糾結(jié)將兩個客戶端 App 調(diào)用的接口存放在哪個服務(wù)中？以至于決策效率低下，而且還會出現(xiàn)職責(zé)劃分不統(tǒng)一的情況。

最終我們決定將第一個接口存放在門店服務(wù)中，此時調(diào)用關(guān)系如下圖所示：

圖片

并將第二個接口存放在工單服務(wù)中，此時調(diào)用關(guān)系如下圖所示：

圖片

案例二：

一個用戶的提交操作常常需要修改多個服務(wù)數(shù)據(jù)，比如一個提交工單的操作，我們需要修改庫存、銷售訂單狀態(tài)、工單等數(shù)據(jù)。

此時第二個問題出現(xiàn)了，因?yàn)檫@樣的需求非常多，所以服務(wù)經(jīng)常被其他多個服務(wù)調(diào)來調(diào)去，導(dǎo)致服務(wù)之間的依賴非常混亂，最終服務(wù)調(diào)用關(guān)系如下圖所示：

圖片

通過上圖，我們發(fā)現(xiàn)服務(wù)間的依賴問題給技術(shù)迭代帶來了地獄般的體驗(yàn)，關(guān)于這點(diǎn)我們已經(jīng)在 15 講中進(jìn)行了細(xì)致講解，這里就不過多贅述。

為了解決這 2 個問題，最終我們決定抽象一個 API 層。

API 層

一般來說，客戶端的接口需要滿足聚合、分布式調(diào)用、裝飾這三種需求。

聚合：一個接口需要聚合多個后臺服務(wù)返回的數(shù)據(jù)，并將數(shù)據(jù)返回給客戶端。

分布式調(diào)用：一個接口可能需要依次調(diào)用多個后臺服務(wù)，才能實(shí)現(xiàn)多個后臺服務(wù)的數(shù)據(jù)修改。

裝飾：一個接口需要重新裝飾后臺返回的數(shù)據(jù)，比如刪除一些字段或者對某些字段進(jìn)行封裝，然后組成客戶端需要的數(shù)據(jù)。

因此，我們決定在客戶端與后臺服務(wù)之間增加一個新的 API 層，專門用來滿足上面的三點(diǎn)需求，此時整個架構(gòu)如下圖所示。

圖片

從圖中我們發(fā)現(xiàn)，所有請求經(jīng)過網(wǎng)關(guān)后，全部交由一個共用的 API 層進(jìn)行處理，而該 API 層沒有自己的數(shù)據(jù)庫，它的主要職責(zé)是調(diào)用其他后臺服務(wù)。

通過這樣的設(shè)計(jì)方案后，以上兩個問題就得到了很多地解決。

應(yīng)該將某個接口放在哪個服務(wù)的糾結(jié)次數(shù)減少了：如果是聚合、裝飾、分布式的調(diào)用邏輯，我們直接把它們放在 API 層。如果是要落庫或者查詢數(shù)據(jù)庫的邏輯，目標(biāo)數(shù)據(jù)在哪個服務(wù)中，我們就把數(shù)據(jù)和邏輯放在哪個服務(wù)中。
后臺服務(wù)之間的依賴也大幅減少了：目前的依賴關(guān)系只有 API 層調(diào)用各個后臺服務(wù)。

此時，我們的設(shè)計(jì)方案完美了吧？別高興得太早，還會出現(xiàn)新的問題。

客戶端適配問題

在這個供應(yīng)鏈系統(tǒng)中，一系列的接口主要供各種客戶端（比如 App、H5、PC 網(wǎng)頁、小程序等）進(jìn)行調(diào)用，此時的調(diào)用關(guān)系如下圖所示：

圖片

不過，這種設(shè)計(jì)方案會存在 3 個問題：

不同客戶端的頁面細(xì)節(jié)的需求可能不一樣，比如 App 的功能比重大，就會要求頁面中多放一些信息，而小程序的功能比重小，同樣的頁面就會要求少放一些信息，以至于后臺服務(wù)中同一個 API 需要針對不同客戶端實(shí)現(xiàn)不同適配；
客戶端經(jīng)常需要進(jìn)行一些輕微的改動，比如增加一個字段/刪除一個字段，此時我們必須采取數(shù)據(jù)最小化原則來縮減客戶端接口的響應(yīng)速度。而且，為了客戶端這種細(xì)微而頻繁的改動，后臺服務(wù)經(jīng)常需要同步發(fā)版；
結(jié)合 #1 和 #2 我們發(fā)現(xiàn)，在后臺服務(wù)的發(fā)版過程中，常常需要綜合考慮不同客戶端的兼容問題，這無形中增加了 API 層為不同客戶端做兼容的復(fù)雜度。

這時該如何解決呢？我們就可以考慮使用 BFF 了。

BFF（Backend for Front）

BFF 不是一個架構(gòu)，而是一個設(shè)計(jì)模式，它的主要職責(zé)是為前端設(shè)計(jì)出優(yōu)雅的后臺服務(wù)，即一個 API。一般而言，每個客戶端都有自己的 API 服務(wù)，此時整個架構(gòu)如下圖所示：

圖片

從上圖可以看到：不同的客戶端請求經(jīng)過同一個網(wǎng)關(guān)后，它們都將分別重定向到為對應(yīng)客戶端設(shè)計(jì)的 API 服務(wù)中。因?yàn)槊總€ API 服務(wù)只能針對一種客戶端，所以它們可以對特定的客戶端進(jìn)行專門優(yōu)化。而去除了兼容邏輯的 API 顯得更輕便，響應(yīng)速度還比通用的 API 服務(wù)更快（因?yàn)樗恍枰袛嗖煌蛻舳说倪壿嫞?/p>

除此之外，每種客戶端還可以實(shí)現(xiàn)自己發(fā)布，不需要再跟著其他客戶端一起排期。

此時的方案挺完美了吧？還不完美，因?yàn)樯厦娴姆桨笇儆谝粋€通用架構(gòu)。在實(shí)際業(yè)務(wù)中，我們還需要結(jié)合實(shí)際業(yè)務(wù)來定，下面我們深入說明一下實(shí)際業(yè)務(wù)需求。

前面我們列出了 5 種服務(wù)，實(shí)際上，整個供應(yīng)鏈系統(tǒng)將近有 100 種服務(wù)。因?yàn)樗且粋€非常龐大的系統(tǒng)，且整個業(yè)務(wù)鏈條的所有工作都包含在這個系統(tǒng)中，比如新零售、供應(yīng)鏈、財務(wù)、加盟商、售后、客服等，，這就需要幾百號研發(fā)人員同時進(jìn)行維護(hù)。

因?yàn)槲覀児餐S護(hù)一個 App、PC 界面、新零售、售后、加盟商，還有各自的小程序和 H5，所以為了實(shí)現(xiàn)業(yè)務(wù)解耦和分開排期，每個部門需要各自維護(hù)自己的 API 服務(wù)，而且 App 與 PC 前端也需要根據(jù)部門實(shí)現(xiàn)組件化，此時的架構(gòu)如下圖所示。

圖片

針對以上需求，我們?nèi)绾卧诩夹g(shù)架構(gòu)上進(jìn)行實(shí)現(xiàn)呢？下面具體來看看。

技術(shù)架構(gòu)上如何實(shí)現(xiàn)？

我們的整套架構(gòu)還是基于 Spring Cloud 設(shè)計(jì)的，如下圖所示：

圖片

下面我們簡單介紹下圖中網(wǎng)關(guān)、API服務(wù)、后臺服務(wù)的作用。

網(wǎng)關(guān)：網(wǎng)關(guān)使用的是 Spring Cloud Zuul，Zuul 將拉取的注冊存放在 ZooKeeper 的 API 服務(wù)中，然后通過 Feign 調(diào)用 API 服務(wù)。
API 服務(wù)：API 服務(wù)其實(shí)就是一個 Spring Web 服務(wù)，它沒有自己的數(shù)據(jù)庫，主要職責(zé)是聚合、分布式調(diào)用及裝飾數(shù)據(jù)，并通過 Feign 調(diào)用后臺服務(wù)。
后臺服務(wù)：后臺服務(wù)其實(shí)也是一個 Spring Web 服務(wù)，它有自己的數(shù)據(jù)庫和緩存。

此時的方案看著很完美了，不過它會出現(xiàn) API 之間代碼重復(fù)問題。此時我們該如何解決？且往下看。

如何解決 API 之間代碼重復(fù)問題？

雖然 H5 與小程序的布局不同，但是頁面中很多功能一致，也就是說重復(fù)的代碼邏輯主要存在 PC API 和 App API 中。

然而，針對重復(fù)代碼的問題，不同部門在設(shè)計(jì)時會呈現(xiàn) 3 種不同的邏輯：

某些部門將這些重復(fù)的代碼存放在一個 JAR 中，讓幾個 API 服務(wù)實(shí)現(xiàn)共用；

某些部門將這些重復(fù)的代碼抽取出來，然后存放在一個叫 CommonAPI 的獨(dú)立 API 服務(wù)中，其他 API 服務(wù)直接調(diào)用這個 Common API 就行；

某些部門因?yàn)橹貜?fù)邏輯少，通過評估后，他們發(fā)現(xiàn)維護(hù)這些重復(fù)代碼的成本小于維護(hù) #1 中的 JAR 或者 #2 中的 CommonAPI 服務(wù)，所以會繼續(xù)讓這些重復(fù)代碼存在。

假如某些 API 服務(wù)提供接口的出入?yún)⑴c后臺服務(wù)的一致，此時該怎么辦？ 此時 API 服務(wù)的接口無須做任何事情，因?yàn)樗皇且粋€簡單的代理層。

于是，有同事提出：“每次一看到這些純代理的 API 接口就不爽，我們能不能想辦法把它們?nèi)サ簟！鞭k法倒是有幾個，我們一起來看看。

網(wǎng)關(guān)直接繞過 API 服務(wù)調(diào)用后臺服務(wù)，不過這樣就會破壞分層，所以很快被否掉了。

在 API 服務(wù)層做一個攔截器，如果 URI 找不到對應(yīng) API 服務(wù)中的 controller mapping，就會直接通過 URI 找后臺服務(wù)并進(jìn)行調(diào)用。不過這種方式將大大增加系統(tǒng)的復(fù)雜度，出問題時調(diào)查起來更麻煩且收益不大。而寫這些無腦代碼不僅成本低，整體的接口列表還更可控。

綜合考慮后，最終我們決定保留無腦的代碼。