在我們之前設(shè)計(jì)的一個(gè)供應(yīng)鏈系統(tǒng)中,它包含了商品、銷售訂單、加盟商、門店運(yùn)營(yíng)、門店工單等服務(wù),涉及了各種用戶角色,比如總部商品管理、總部門店管理、加盟商員工、門店人員等,而且每個(gè)部門的角色還會(huì)進(jìn)行細(xì)分。而且這個(gè)系統(tǒng)中還包含了兩個(gè)客戶端 App:一個(gè)面向客戶,另一個(gè)面向公司員工和加盟商。
此時(shí),整個(gè)供應(yīng)鏈系統(tǒng)的架構(gòu)如下圖所示:
上圖中的網(wǎng)關(guān)層主要負(fù)責(zé)路由、認(rèn)證、監(jiā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ì)門店運(yùn)營(yíng)人員,需要顯示工單數(shù)量、最近的工單、銷售訂單數(shù)據(jù)、最近待處理的訂單、低于庫(kù)存安全值的商品等信息。
此時(shí)第一個(gè)問(wèn)題來(lái)了,在接口設(shè)計(jì)過(guò)程中,我們經(jīng)常糾結(jié)將兩個(gè)客戶端 App 調(diào)用的接口存放在哪個(gè)服務(wù)中?以至于決策效率低下,而且還會(huì)出現(xiàn)職責(zé)劃分不統(tǒng)一的情況。
最終我們決定將第一個(gè)接口存放在門店服務(wù)中,此時(shí)調(diào)用關(guān)系如下圖所示:
并將第二個(gè)接口存放在工單服務(wù)中,此時(shí)調(diào)用關(guān)系如下圖所示:
一個(gè)用戶的提交操作常常需要修改多個(gè)服務(wù)數(shù)據(jù),比如一個(gè)提交工單的操作,我們需要修改庫(kù)存、銷售訂單狀態(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ù)之間的依賴非常混亂,最終服務(wù)調(diào)用關(guān)系如下圖所示:
通過(guò)上圖,我們發(fā)現(xiàn)服務(wù)間的依賴問(wèn)題給技術(shù)迭代帶來(lái)了地獄般的體驗(yàn),關(guān)于這點(diǎn)我們已經(jīng)在 15 講中進(jìn)行了細(xì)致講解,這里就不過(guò)多贅述。
為了解決這 2 個(gè)問(wèn)題,最終我們決定抽象一個(gè) API 層。
一般來(lái)說(shuō),客戶端的接口需要滿足聚合、分布式調(diào)用、裝飾這三種需求。
因此,我們決定在客戶端與后臺(tái)服務(wù)之間增加一個(gè)新的 API 層,專門用來(lái)滿足上面的三點(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)題就得到了很多地解決。
此時(shí),我們的設(shè)計(jì)方案完美了吧?別高興得太早,還會(huì)出現(xiàn)新的問(wèn)題。
在這個(gè)供應(yīng)鏈系統(tǒng)中,一系列的接口主要供各種客戶端(比如 App、H5、PC 網(wǎng)頁(yè)、小程序等)進(jìn)行調(diào)用,此時(shí)的調(diào)用關(guān)系如下圖所示:
不過(guò),這種設(shè)計(jì)方案會(huì)存在三個(gè)問(wèn)題:
這時(shí)該如何解決呢?我們就可以考慮使用 BFF 了。
BFF 不是一個(gè)架構(gòu),而是一個(gè)設(shè)計(jì)模式,它的主要職責(zé)是為前端設(shè)計(jì)出優(yōu)雅的后臺(tái)服務(wù),即一個(gè) API。一般而言,每個(gè)客戶端都有自己的 API 服務(wù),此時(shí)整個(gè)架構(gòu)如下圖所示:
從上圖可以看到:不同的客戶端請(qǐng)求經(jīng)過(guò)同一個(gè)網(wǎng)關(guān)后,它們都將分別重定向到為對(duì)應(yīng)客戶端設(shè)計(jì)的 API 服務(wù)中。因?yàn)槊總€(gè) API 服務(wù)只能針對(duì)一種客戶端,所以它們可以對(duì)特定的客戶端進(jìn)行專門優(yōu)化。而去除了兼容邏輯的 API 顯得更輕便,響應(yīng)速度還比通用的 API 服務(wù)更快(因?yàn)樗恍枰袛嗖煌蛻舳说倪壿嫞?span style="display:none">JEa28資訊網(wǎng)——每日最新資訊28at.com
除此之外,每種客戶端還可以實(shí)現(xiàn)自己發(fā)布,不需要再跟著其他客戶端一起排期。
此時(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ù)解耦和分開排期,每個(gè)部門需要各自維護(hù)自己的 API 服務(wù),而且 App 與 PC 前端也需要根據(jù)部門實(shí)現(xiàn)組件化,此時(shí)的架構(gòu)如下圖所示。
針對(duì)以上需求,我們?nèi)绾卧诩夹g(shù)架構(gòu)上進(jìn)行實(shí)現(xiàn)呢?下面具體來(lái)看看。
我們的整套架構(gòu)還是基于 Spring Cloud 設(shè)計(jì)的,如下圖所示:
下面我們簡(jiǎn)單介紹下圖中網(wǎng)關(guān)、API服務(wù)、后臺(tái)服務(wù)的作用。
此時(shí)的方案看著很完美了,不過(guò)它會(huì)出現(xiàn) API 之間代碼重復(fù)問(wèn)題。此時(shí)我們?cè)撊绾谓鉀Q?且往下看。
雖然 H5 與小程序的布局不同,但是頁(yè)面中很多功能一致,也就是說(shuō)重復(fù)的代碼邏輯主要存在 PC API 和 App API 中。
然而,針對(duì)重復(fù)代碼的問(wèn)題,不同部門在設(shè)計(jì)時(shí)會(huì)呈現(xiàn) 3 種不同的邏輯:
假如某些 API 服務(wù)提供接口的出入?yún)⑴c后臺(tái)服務(wù)的一致,此時(shí)該怎么辦? 此時(shí) API 服務(wù)的接口無(wú)須做任何事情,因?yàn)樗皇且粋€(gè)簡(jiǎn)單的代理層。
于是,有同事提出:“每次一看到這些純代理的 API 接口就不爽,我們能不能想辦法把它們?nèi)サ簟!鞭k法倒是有幾個(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)更麻煩且收益不大。而寫這些無(wú)腦代碼不僅成本低,整體的接口列表還更可控。
綜合考慮后,最終我們決定保留無(wú)腦的代碼。
最后我們是這樣分工的:專門的 API 開發(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)久留不住人。
本文鏈接:http://www.www897cc.com/showinfo-26-85542-0.html如何處理好微服務(wù)之間千絲萬(wàn)縷的關(guān)系?到BFF大顯身手了
聲明:本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí),若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。郵件:2376512515@qq.com
上一篇: C# 讀寫 JSON 配置文件詳解