go-zero 微服務(wù)實(shí)戰(zhàn)系列（二、服務(wù)拆分）
微服務(wù)概述
微服務(wù)架構(gòu)是一種架構(gòu)風(fēng)格，它將一個(gè)大的系統(tǒng)構(gòu)建為多個(gè)微服務(wù)的集合，這些微服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，服務(wù)關(guān)注單一的業(yè)務(wù)功能，這些服務(wù)具有以下特點(diǎn)：
高度可維護(hù)和可測試 松散的耦合 可獨(dú)立部署 圍繞業(yè)務(wù)功能進(jìn)行構(gòu)建 由不同的小團(tuán)隊(duì)進(jìn)行維護(hù)
微服務(wù)架構(gòu)能夠快速、頻繁、可靠地交付大型、復(fù)雜的應(yīng)用程序，通過業(yè)務(wù)拆分實(shí)現(xiàn)服務(wù)組件化，使用組件進(jìn)行組合從而快速開發(fā)系統(tǒng)。
服務(wù)劃分
我們首先進(jìn)行微服務(wù)的劃分，在實(shí)際的項(xiàng)目開發(fā)中，我們通常采用兩種微服務(wù)劃分策略，第一種方式是通過業(yè)務(wù)職能進(jìn)行微服務(wù)邊界的劃分，第二種方式是通過DDD的界限上下文進(jìn)行微服務(wù)邊界的劃分，我們這里采用大家比較容易理解的業(yè)務(wù)職能的方式進(jìn)行微服務(wù)劃分，再次貼上我們電商項(xiàng)目的思維導(dǎo)圖：
從以上思維導(dǎo)圖可以看出整個(gè)電商系統(tǒng)功能還是比較多的，我們根據(jù)業(yè)務(wù)職能做如下微服務(wù)的劃分：
商品服務(wù)(product) - 商品的添加、信息查詢、庫存管理等功能 購物車服務(wù)(cart) - 購物車的增刪改查 訂單服務(wù)(order) - 生成訂單，訂單管理 支付服務(wù)(pay) - 通過調(diào)用第三方支付實(shí)現(xiàn)支付功能 賬號服務(wù)(user) - 用戶信息、等級、封禁、地址管理 推薦服務(wù)(recommend) - 首頁商品推薦 評論服務(wù)(reply) - 商品的評論功能、評論的回復(fù)功能
BFF層
一般對客戶端我們都會(huì)采用HTTP接口的方式提供服務(wù)，那是不是以上劃分的這些微服務(wù)都需要直接提供HTTP接口對外提供服務(wù)呢？這樣當(dāng)然可以，架構(gòu)整體看起來也比較簡單。
但對于一個(gè)復(fù)雜的高并發(fā)的系統(tǒng)來說，我們需要處理各種異常的場景，比如某個(gè)頁面需要依賴多個(gè)微服務(wù)提供的數(shù)據(jù)，為了避免串行請求導(dǎo)致的耗時(shí)過長，我們一般會(huì)并行的請求多個(gè)微服務(wù)，這個(gè)時(shí)候其中的某個(gè)服務(wù)請求異常的話我們可能需要做一些特殊的處理，比如提供一些降級的數(shù)據(jù)等。還有我們的頁面展示的數(shù)據(jù)往往都是面向業(yè)務(wù)功能的，而不是單單某一個(gè)微服務(wù)的數(shù)據(jù)，這時(shí)候我們往往需要組裝多個(gè)微服務(wù)的數(shù)據(jù)來滿足需求，如果我們每個(gè)微服務(wù)都直接對外提供HTTP接口的話，那么這些復(fù)雜的數(shù)據(jù)組裝和異常處理等工作只能由客戶端來完成。眾所周知客戶端是不宜做復(fù)雜的業(yè)務(wù)邏輯的，客戶端的重點(diǎn)應(yīng)該更多是做交互體驗(yàn)上的優(yōu)化，我們的整體架構(gòu)需要做到前輕后重，即客戶端邏輯盡量少而把比較重的業(yè)務(wù)處理邏輯下沉到服務(wù)端，而服務(wù)端又根據(jù)業(yè)務(wù)職能拆分成了不同的微服務(wù)，這些微服務(wù)只關(guān)注單一的業(yè)務(wù)，那么這些面向業(yè)務(wù)場景的復(fù)雜邏輯的處理應(yīng)該放到哪里呢？我們的解決方案就是加一層，即BFF層，通過BFF對外提供HTTP接口，客戶端只與BFF進(jìn)行交互。
BFF層的引入解決了我們上面遇到的問題，但增加一層就會(huì)增加架構(gòu)的復(fù)雜度，所以如果你的服務(wù)是一個(gè)單體應(yīng)用的話，那么BFF是不必要的，引入它不會(huì)增加任何價(jià)值。對于我們這個(gè)項(xiàng)目來說，我們的應(yīng)用程序依賴于微服務(wù)，同時(shí)我們需要面向業(yè)務(wù)功能提供HTTP接口和要保證接口的高可用，所以BFF對于我們這個(gè)項(xiàng)目來說是一個(gè)合適的選擇。
我們可以提供多個(gè)BFF嗎？答案是當(dāng)然可以。BFF的目的是為客戶端提供一個(gè)集中的接口，例如移動(dòng)端頁面和瀏覽器頁面的數(shù)據(jù)協(xié)議不同，這種情況下為了更好的表示數(shù)據(jù)，可以使用兩個(gè)BFF，同時(shí)只供一個(gè)BFF如果該BFF異常就會(huì)導(dǎo)致所有的業(yè)務(wù)受影響，提供多個(gè)BFF也可以提高服務(wù)的可用性，降低業(yè)務(wù)異常的影響面。多個(gè)BFF架構(gòu)圖如下：
我們的這個(gè)項(xiàng)目為了簡化只會(huì)采用一個(gè)BFF服務(wù)。
工程結(jié)構(gòu)
我們采用集中管理的方式，把所有的服務(wù)放到一個(gè)大倉庫中，倉庫的目錄結(jié)構(gòu)如下：
lebron為工程名，lebron下面有apps和pkg兩個(gè)目錄，其中apps存放的是我們所有的微服務(wù)，比如order為訂單相關(guān)的微服務(wù)，pkg目錄為所有服務(wù)共同依賴的包的存放路徑，比如所有的服務(wù)都需要依賴鑒權(quán)就可以放到pkg目錄下。
app - BFF服務(wù) cart - 購物車服務(wù) order - 訂單服務(wù) pay - 支付服務(wù) product - 商品服務(wù) recommend - 推薦服務(wù) reply - 評論服務(wù) user - 賬號服務(wù)
在每個(gè)服務(wù)目錄下我們又會(huì)分為多個(gè)服務(wù)，主要會(huì)有如下幾類服務(wù)：
api - 對外的BFF服務(wù)，接受來自客戶端的請求，暴露HTTP接口 rpc - 對內(nèi)的微服務(wù)，僅接受來自內(nèi)部其他微服務(wù)或者BFF的請求，暴露gRPC接口 rmq - 負(fù)責(zé)進(jìn)行流式任務(wù)處理，上游一般依賴消息隊(duì)列，比如kafka等 admin - 也是對內(nèi)的服務(wù)，區(qū)別于rpc，更多的是面向運(yùn)營側(cè)的且數(shù)據(jù)權(quán)限較高，通過隔離可帶來更好的代碼級別的安全，直接提供HTTP接口
apps目錄下每個(gè)服務(wù)的結(jié)構(gòu)如下：
大多服務(wù)都會(huì)拆分成rpc、rmq和admin來滿足對內(nèi)提供rpc接口和運(yùn)營數(shù)據(jù)的需求，同時(shí)通過rmq來處理流式任務(wù)。比較特殊的是app下只有api服務(wù)，因?yàn)閍pp是BFF所有只有api服務(wù)，后面可能會(huì)增加rmq服務(wù)，比如來流式處理用戶每天首次登陸加經(jīng)驗(yàn)之類的邏輯，我們后面可以隨時(shí)擴(kuò)展，暫時(shí)先只提供api服務(wù)。recommend只有rpc服務(wù)，因?yàn)橥扑]服務(wù)需要依賴AI團(tuán)隊(duì)或者大數(shù)據(jù)團(tuán)隊(duì)提供的數(shù)據(jù)，我們只需要請求對應(yīng)的數(shù)據(jù)接口和做一些滿足業(yè)務(wù)的處理即可，所以這里recommend只有rpc服務(wù)。
代碼初始化
整個(gè)工程的結(jié)構(gòu)已經(jīng)定義清楚了，下面我們做服務(wù)代碼的初始化
我們使用goctl來進(jìn)行項(xiàng)目的初始化，比如我們先初始化order，先進(jìn)入order目錄下：
$ cd lebron/apps/order
執(zhí)行如下命令即可初始化order rpc代碼
$ goctl rpc new rpc
生成的代碼結(jié)構(gòu)如下：
執(zhí)行如下命令即可初始化order admin代碼，注意order admin為api服務(wù)，直接對前端提供HTTP接口
$ goctl api new admin
生成的代碼結(jié)構(gòu)如下：
生成的服務(wù)代碼我們可以直接運(yùn)行，默認(rèn)偵聽在8888端口
$ go run admin.go
Starting server at 0.0.0.0:8888...
對于rmq服務(wù)我們會(huì)使用go-zero提供的 kq 功能，這里先初始化main.go
到這里order服務(wù)的代碼初始化已經(jīng)完成，其他服務(wù)和order服務(wù)類似，這里就不再贅述了。
pkg下目前不需要初始化，當(dāng)我們需要提供業(yè)務(wù)通用功能的時(shí)候我們再進(jìn)行添加。
結(jié)束語
本篇我們講解了微服務(wù)的定義，微服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，服務(wù)關(guān)注單一的業(yè)務(wù)，服務(wù)間采用輕量級的通訊機(jī)制，每個(gè)微服務(wù)都可以獨(dú)立的部署和測試。
我們根據(jù)商城功能進(jìn)行了微服務(wù)的拆分，主要拆分了購物車、訂單、支付、商品、評論、推薦、賬號等服務(wù)，然后我們又說明了為什么需要引入BFF服務(wù)，BFF本質(zhì)上是一個(gè)用于做數(shù)據(jù)組裝的服務(wù)，對外提供面向業(yè)務(wù)功能的或者說面向客戶端UI的HTTP接口。
接著我們定義了我們這個(gè)工程的目錄結(jié)構(gòu)，主要分為api、rpc、rmq和admin等服務(wù)，不同服務(wù)的職責(zé)不同，api對外提供HTTP接口，rpc對內(nèi)提供RPC接口，rmq做流式數(shù)據(jù)的處理，admin面向運(yùn)營后臺(tái)提供HTTP接口。
最后我們通過goctl對項(xiàng)目做了初始化，使用goctl可一鍵生成項(xiàng)目框架代碼，大大提供了生產(chǎn)力。
希望本篇文章對你有所幫助，謝謝。
每周一、周四更新
代碼倉庫：https://github.com/zhoushuguang/lebron
參考
https://microservices.io/index.html
https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf
推薦閱讀