聊聊微服務中的 BFF 架構
大家好,我是不才陳某~
在我們之前設計的一個供應鏈系統中,它包含了商品、銷售訂單、加盟商、門店運營、門店工單等服務,涉及了各種用戶角色,比如總部商品管理、總部門店管理、加盟商員工、門店人員等,而且每個部門的角色還會進行細分。而且這個系統中還包含了兩個客戶端 App:一個面向客戶,另一個面向公司員工和加盟商。
此時,整個供應鏈系統的架構如下圖所示:
上圖中的網關層主要負責路由、認證、監控、限流熔斷等工作。
-
路由:所有的請求都需要通過網關層進行處理,網關層再根據 URI 將請求指向對應的後臺服務,如果同一個服務存在多個服務器節點,網關層還將承擔負載均衡的工作。
-
認證:對所有的請求進行集中認證鑑權。
-
監控:記錄所有的 API 請求數據,API 管理系統能對 API 調用實現管理和性能監控。
-
限流熔斷:流量過大時,我們可以在網關層實現限流。如果後臺服務響應延時或故障,我們可以主動在調用端的上游服務做熔斷,以此保護後端服務資源,同時不影響用戶體驗。
此時,我們的架構看起來是不是挺完美?且市面上標準的 Spring Cloud 架構都是這樣做的。不過,這個架構會出現一些問題,下面我們先通過幾個例子來看看。
案例一
在這個供應鏈系統中,很多界面都需要顯示多個服務數據,比如在一個 App 首頁中,針對門店運營人員,需要顯示工單數量、最近的工單、銷售訂單數據、最近待處理的訂單、低於庫存安全值的商品等信息。
此時第一個問題來了,在接口設計過程中,我們經常糾結將兩個客戶端 App 調用的接口存放在哪個服務中?以至於決策效率低下,而且還會出現職責劃分不統一的情況。
最終我們決定將第一個接口存放在門店服務中,此時調用關係如下圖所示:
並將第二個接口存放在工單服務中,此時調用關係如下圖所示:
案例二
一個用戶的提交操作常常需要修改多個服務數據,比如一個提交工單的操作,我們需要修改庫存、銷售訂單狀態、工單等數據。
此時第二個問題出現了,因爲這樣的需求非常多,所以服務經常被其他多個服務調來調去,導致服務之間的依賴非常混亂,最終服務調用關係如下圖所示:
通過上圖,我們發現服務間的依賴問題給技術迭代帶來了地獄般的體驗,講解,這裏就不過多贅述。
爲了解決這 2 個問題,最終我們決定抽象一個 API 層。
API 層
一般來說,客戶端的接口需要滿足聚合、分佈式調用、裝飾這三種需求。
-
聚合:一個接口需要聚合多個後臺服務返回的數據,並將數據返回給客戶端。
-
分佈式調用:一個接口可能需要依次調用多個後臺服務,才能實現多個後臺服務的數據修改。
-
裝飾:一個接口需要重新裝飾後臺返回的數據,比如刪除一些字段或者對某些字段進行封裝,然後組成客戶端需要的數據。
因此,我們決定在客戶端與後臺服務之間增加一個新的 API 層,專門用來滿足上面的三點需求,此時整個架構如下圖所示。
從圖中我們發現,所有請求經過網關後,全部交由一個共用的 API 層進行處理,而該 API 層沒有自己的數據庫,它的主要職責是調用其他後臺服務。
通過這樣的設計方案後,以上兩個問題就得到了很多地解決。
-
應該將某個接口放在哪個服務的糾結次數減少了:如果是聚合、裝飾、分佈式的調用邏輯,我們直接把它們放在 API 層。如果是要落庫或者查詢數據庫的邏輯,目標數據在哪個服務中,我們就把數據和邏輯放在哪個服務中。
-
後臺服務之間的依賴也大幅減少了:目前的依賴關係只有 API 層調用各個後臺服務。
此時,我們的設計方案完美了吧?別高興得太早,還會出現新的問題。
客戶端適配問題
在這個供應鏈系統中,一系列的接口主要供各種客戶端(比如 App、H5、PC 網頁、小程序等)進行調用,此時的調用關係如下圖所示:
不過,這種設計方案會存在 3 個問題:
不同客戶端的頁面細節的需求可能不一樣,比如 App 的功能比重大,就會要求頁面中多放一些信息,而小程序的功能比重小,同樣的頁面就會要求少放一些信息,以至於後臺服務中同一個 API 需要針對不同客戶端實現不同適配;
客戶端經常需要進行一些輕微的改動,比如增加一個字段 / 刪除一個字段,此時我們必須採取數據最小化原則來縮減客戶端接口的響應速度。而且,爲了客戶端這種細微而頻繁的改動,後臺服務經常需要同步發版;
結合 #1 和 #2 我們發現,在後臺服務的發版過程中,常常需要綜合考慮不同客戶端的兼容問題,這無形中增加了 API 層爲不同客戶端做兼容的複雜度。
這時該如何解決呢?我們就可以考慮使用 BFF 了。
BFF(Backend for Front)
BFF 不是一個架構,而是一個設計模式,它的主要職責是爲前端設計出優雅的後臺服務,即一個 API。一般而言,每個客戶端都有自己的 API 服務,此時整個架構如下圖所示:
從上圖可以看到:不同的客戶端請求經過同一個網關後,它們都將分別重定向到爲對應客戶端設計的 API 服務中。因爲每個 API 服務只能針對一種客戶端,所以它們可以對特定的客戶端進行專門優化。而去除了兼容邏輯的 API 顯得更輕便,響應速度還比通用的 API 服務更快(因爲它不需要判斷不同客戶端的邏輯)。
除此之外,每種客戶端還可以實現自己發佈,不需要再跟着其他客戶端一起排期。
此時的方案挺完美了吧?還不完美,因爲上面的方案屬於一個通用架構。在實際業務中,我們還需要結合實際業務來定,下面我們深入說明一下實際業務需求。
前面我們列出了 5 種服務,實際上,整個供應鏈系統將近有 100 種服務。因爲它是一個非常龐大的系統,且整個業務鏈條的所有工作都包含在這個系統中,比如新零售、供應鏈、財務、加盟商、售後、客服等,,這就需要幾百號研發人員同時進行維護。
因爲我們共同維護一個 App、PC 界面、新零售、售後、加盟商,還有各自的小程序和 H5,所以爲了實現業務解耦和分開排期,每個部門需要各自維護自己的 API 服務,而且 App 與 PC 前端也需要根據部門實現組件化,此時的架構如下圖所示。
針對以上需求,我們如何在技術架構上進行實現呢?下面具體來看看。
技術架構上如何實現?
我們的整套架構還是基於 Spring Cloud 設計的,如下圖所示:
下面我們簡單介紹下圖中網關、API 服務、後臺服務的作用。
-
網關:網關使用的是 Spring Cloud Zuul,Zuul 將拉取的註冊存放在 ZooKeeper 的 API 服務中,然後通過 Feign 調用 API 服務。
-
API 服務:API 服務其實就是一個 Spring Web 服務,它沒有自己的數據庫,主要職責是聚合、分佈式調用及裝飾數據,並通過 Feign 調用後臺服務。
-
後臺服務:後臺服務其實也是一個 Spring Web 服務,它有自己的數據庫和緩存。
此時的方案看着很完美了,不過它會出現 API 之間代碼重複問題。此時我們該如何解決?且往下看
如何解決 API 之間代碼重複問題?
雖然 H5 與小程序的佈局不同,但是頁面中很多功能一致,也就是說重複的代碼邏輯主要存在 PC API 和 App API 中。
然而,針對重複代碼的問題,不同部門在設計時會呈現 3 種不同的邏輯:
-
某些部門將這些重複的代碼存放在一個 JAR 中,讓幾個 API 服務實現共用;
-
某些部門將這些重複的代碼抽取出來,然後存放在一個叫 CommonAPI 的獨立 API 服務中,其他 API 服務直接調用這個 Common API 就行;
-
某些部門因爲重複邏輯少,通過評估後,他們發現維護這些重複代碼的成本小於維護 #1 中的 JAR 或者 #2 中的 CommonAPI 服務,所以會繼續讓這些重複代碼存在。
假如某些 API 服務提供接口的出入參與後臺服務的一致,此時該怎麼辦? 此時 API 服務的接口無須做任何事情,因爲它只是一個簡單的代理層。
於是,有同事提出:“每次一看到這些純代理的 API 接口就不爽,我們能不能想辦法把它們去掉。” 辦法倒是有幾個,我們一起來看看。
-
網關直接繞過 API 服務調用後臺服務,不過這樣就會破壞分層,所以很快被否掉了。
-
在 API 服務層做一個攔截器,如果 URI 找不到對應 API 服務中的 controller mapping,就會直接通過 URI 找後臺服務並進行調用。不過這種方式將大大增加系統的複雜度,出問題時調查起來更麻煩且收益不大。而寫這些無腦代碼不僅成本低,整體的接口列表還更可控。
綜合考慮後,最終我們決定保留無腦的代碼。
後臺服務與 API 服務的開發團隊如何進行分工?
最後我們是這樣分工的:專門的 API 開發團隊負責 API 服務,而後臺服務需要根據領域再劃分小組的職責。
這種劃分方式的好處在於 API 團隊能對所有服務有個整體認識,且不會出現後臺服務劃分不清晰、工作重複的情況。而壞處在於 API 團隊整體業務邏輯偏簡單,長久留不住人。
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/HjhIMkWer9q7E_K8o_qNvg