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

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

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

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

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

案例一

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

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

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

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

案例二

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

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

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

為了解決這 2 個(gè)問(wèn)題，最終我們決定抽象一個(gè) API 層。

API 層

一般來(lái)說(shuō)，客戶(hù)端的接口需要滿(mǎn)足聚合、分布式調(diào)用、裝飾這三種需求。

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

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

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

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

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

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

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

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

客戶(hù)端適配問(wèn)題

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

不過(guò)，這種設(shè)計(jì)方案會(huì)存在 3 個(gè)問(wèn)題：

不同客戶(hù)端的頁(yè)面細(xì)節(jié)的需求可能不一樣，比如 App 的功能比重大，就會(huì)要求頁(yè)面中多放一些信息，而小程序的功能比重小，同樣的頁(yè)面就會(huì)要求少放一些信息，以至于后臺(tái)服務(wù)中同一個(gè) API 需要針對(duì)不同客戶(hù)端實(shí)現(xiàn)不同適配；

客戶(hù)端經(jīng)常需要進(jìn)行一些輕微的改動(dòng)，比如增加一個(gè)字段/刪除一個(gè)字段，此時(shí)我們必須采取數(shù)據(jù)最小化原則來(lái)縮減客戶(hù)端接口的響應(yīng)速度。而且，為了客戶(hù)端這種細(xì)微而頻繁的改動(dòng)，后臺(tái)服務(wù)經(jīng)常需要同步發(fā)版；

結(jié)合 #1 和 #2 我們發(fā)現(xiàn)，在后臺(tái)服務(wù)的發(fā)版過(guò)程中，常常需要綜合考慮不同客戶(hù)端的兼容問(wèn)題，這無(wú)形中增加了 API 層為不同客戶(hù)端做兼容的復(fù)雜度。

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

BFF（Backend for Front）

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

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

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

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

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

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

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

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

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

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

網(wǎng)關(guān)：網(wǎng)關(guān)使用的是 Spring Cloud Zuul，Zuul 將拉取的注冊(cè)存放在 ZooKeeper 的 API 服務(wù)中，然后通過(guò) Feign 調(diào)用 API 服務(wù)。

API 服務(wù)：API 服務(wù)其實(shí)就是一個(gè) Spring Web 服務(wù)，它沒(méi)有自己的數(shù)據(jù)庫(kù)，主要職責(zé)是聚合、分布式調(diào)用及裝飾數(shù)據(jù)，并通過(guò) Feign 調(diào)用后臺(tái)服務(wù)。

后臺(tái)服務(wù)：后臺(tái)服務(wù)其實(shí)也是一個(gè) Spring Web 服務(wù)，它有自己的數(shù)據(jù)庫(kù)和緩存。

此時(shí)的方案看著很完美了，不過(guò)它會(huì)出現(xiàn) API 之間代碼重復(fù)問(wèn)題。此時(shí)我們?cè)撊绾谓鉀Q？且往下看

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

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

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

• 某些部門(mén)將這些重復(fù)的代碼存放在一個(gè) JAR 中，讓幾個(gè) API 服務(wù)實(shí)現(xiàn)共用；
• 某些部門(mén)將這些重復(fù)的代碼抽取出來(lái)，然后存放在一個(gè)叫 CommonAPI 的獨(dú)立 API 服務(wù)中，其他 API 服務(wù)直接調(diào)用這個(gè) Common API 就行；
• 某些部門(mén)因?yàn)橹貜?fù)邏輯少，通過(guò)評(píng)估后，他們發(fā)現(xiàn)維護(hù)這些重復(fù)代碼的成本小于維護(hù) #1 中的 JAR 或者 #2 中的 CommonAPI 服務(wù)，所以會(huì)繼續(xù)讓這些重復(fù)代碼存在。

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

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

• 網(wǎng)關(guān)直接繞過(guò) API 服務(wù)調(diào)用后臺(tái)服務(wù)，不過(guò)這樣就會(huì)破壞分層，所以很快被否掉了。
• 在 API 服務(wù)層做一個(gè)攔截器，如果 URI 找不到對(duì)應(yīng) API 服務(wù)中的 controller mapping，就會(huì)直接通過(guò) URI 找后臺(tái)服務(wù)并進(jìn)行調(diào)用。不過(guò)這種方式將大大增加系統(tǒng)的復(fù)雜度，出問(wèn)題時(shí)調(diào)查起來(lái)更麻煩且收益不大。而寫(xiě)這些無(wú)腦代碼不僅成本低，整體的接口列表還更可控。

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

后臺(tái)服務(wù)與 API 服務(wù)的開(kāi)發(fā)團(tuán)隊(duì)如何進(jìn)行分工？

最后我們是這樣分工的：專(zhuān)門(mén)的 API 開(kāi)發(fā)團(tuán)隊(duì)負(fù)責(zé) API 服務(wù)，而后臺(tái)服務(wù)需要根據(jù)領(lǐng)域再劃分小組的職責(zé)。

這種劃分方式的好處在于 API 團(tuán)隊(duì)能對(duì)所有服務(wù)有個(gè)整體認(rèn)識(shí)，且不會(huì)出現(xiàn)后臺(tái)服務(wù)劃分不清晰、工作重復(fù)的情況。而壞處在于 API 團(tuán)隊(duì)整體業(yè)務(wù)邏輯偏簡(jiǎn)單，長(zhǎng)久留不住人。