微服務(wù)概述

微服務(wù)架構(gòu)是一種架構(gòu)風(fēng)格，它將一個大的系統(tǒng)構(gòu)建為多個微服務(wù)的集合，這些微服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，服務(wù)關(guān)注單一的業(yè)務(wù)功能，這些服務(wù)具有以下特點：

• 高度可維護(hù)和可測試
• 松散的耦合
• 可獨立部署
• 圍繞業(yè)務(wù)功能進(jìn)行構(gòu)建
• 由不同的小團(tuán)隊進(jìn)行維護(hù)

微服務(wù)架構(gòu)能夠快速、頻繁、可靠地交付大型、復(fù)雜的應(yīng)用程序，通過業(yè)務(wù)拆分實現(xiàn)服務(wù)組件化，使用組件進(jìn)行組合從而快速開發(fā)系統(tǒng)。

服務(wù)劃分

我們首先進(jìn)行微服務(wù)的劃分，在實際的項目開發(fā)中，我們通常采用兩種微服務(wù)劃分策略，第一種方式是通過業(yè)務(wù)職能進(jìn)行微服務(wù)邊界的劃分，第二種方式是通過DDD的界限上下文進(jìn)行微服務(wù)邊界的劃分，我們這里采用大家比較容易理解的業(yè)務(wù)職能的方式進(jìn)行微服務(wù)劃分，再次貼上我們電商項目的思維導(dǎo)圖：

從以上思維導(dǎo)圖可以看出整個電商系統(tǒng)功能還是比較多的，我們根據(jù)業(yè)務(wù)職能做如下微服務(wù)的劃分：

• 商品服務(wù)(product) - 商品的添加、信息查詢、庫存管理等功能
• 購物車服務(wù)(cart) - 購物車的增刪改查
• 訂單服務(wù)(order) - 生成訂單，訂單管理
• 支付服務(wù)(pay) - 通過調(diào)用第三方支付實現(xiàn)支付功能
• 賬號服務(wù)(user) - 用戶信息、等級、封禁、地址管理
• 推薦服務(wù)(recommend) - 首頁商品推薦
• 評論服務(wù)(reply) - 商品的評論功能、評論的回復(fù)功能

BFF層

一般對客戶端我們都會采用HTTP接口的方式提供服務(wù)，那是不是以上劃分的這些微服務(wù)都需要直接提供HTTP接口對外提供服務(wù)呢？這樣當(dāng)然可以，架構(gòu)整體看起來也比較簡單。

• 但對于一個復(fù)雜的高并發(fā)的系統(tǒng)來說，我們需要處理各種異常的場景，比如某個頁面需要依賴多個微服務(wù)提供的數(shù)據(jù)，為了避免串行請求導(dǎo)致的耗時過長，我們一般會并行的請求多個微服務(wù)，這個時候其中的某個服務(wù)請求異常的話我們可能需要做一些特殊的處理，比如提供一些降級的數(shù)據(jù)等。還有我們的頁面展示的數(shù)據(jù)往往都是面向業(yè)務(wù)功能的，而不是單單某一個微服務(wù)的數(shù)據(jù)，這時候我們往往需要組裝多個微服務(wù)的數(shù)據(jù)來滿足需求，如果我們每個微服務(wù)都直接對外提供HTTP接口的話，那么這些復(fù)雜的數(shù)據(jù)組裝和異常處理等工作只能由客戶端來完成。
• 眾所周知客戶端是不宜做復(fù)雜的業(yè)務(wù)邏輯的，客戶端的重點應(yīng)該更多是做交互體驗上的優(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層的引入解決了我們上面遇到的問題，但增加一層就會增加架構(gòu)的復(fù)雜度，所以如果你的服務(wù)是一個單體應(yīng)用的話，那么BFF是不必要的，引入它不會增加任何價值。對于我們這個項目來說，我們的應(yīng)用程序依賴于微服務(wù)，同時我們需要面向業(yè)務(wù)功能提供HTTP接口和要保證接口的高可用，所以BFF對于我們這個項目來說是一個合適的選擇。

我們可以提供多個BFF嗎？答案是當(dāng)然可以。BFF的目的是為客戶端提供一個集中的接口，例如移動端頁面和瀏覽器頁面的數(shù)據(jù)協(xié)議不同，這種情況下為了更好的表示數(shù)據(jù)，可以使用兩個BFF，同時只供一個BFF如果該BFF異常就會導(dǎo)致所有的業(yè)務(wù)受影響，提供多個BFF也可以提高服務(wù)的可用性，降低業(yè)務(wù)異常的影響面。多個BFF架構(gòu)圖如下：

我們的這個項目為了簡化只會采用一個BFF服務(wù)。

工程結(jié)構(gòu)

我們采用集中管理的方式，把所有的服務(wù)放到一個大倉庫中，倉庫的目錄結(jié)構(gòu)如下：

lebron為工程名，lebron下面有apps和pkg兩個目錄，其中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ù)

在每個服務(wù)目錄下我們又會分為多個服務(wù)，主要會有如下幾類服務(wù)：

• api - 對外的BFF服務(wù)，接受來自客戶端的請求，暴露HTTP接口
• rpc - 對內(nèi)的微服務(wù)，僅接受來自內(nèi)部其他微服務(wù)或者BFF的請求，暴露gRPC接口
• rmq - 負(fù)責(zé)進(jìn)行流式任務(wù)處理，上游一般依賴消息隊列，比如kafka等
• admin - 也是對內(nèi)的服務(wù)，區(qū)別于rpc，更多的是面向運營側(cè)的且數(shù)據(jù)權(quán)限較高，通過隔離可帶來更好的代碼級別的安全，直接提供HTTP接口

apps目錄下每個服務(wù)的結(jié)構(gòu)如下：

大多服務(wù)都會拆分成rpc、rmq和admin來滿足對內(nèi)提供rpc接口和運營數(shù)據(jù)的需求，同時通過rmq來處理流式任務(wù)。比較特殊的是app下只有api服務(wù)，因為app是BFF所有只有api服務(wù)，后面可能會增加rmq服務(wù)，比如來流式處理用戶每天首次登陸加經(jīng)驗之類的邏輯，我們后面可以隨時擴(kuò)展，暫時先只提供api服務(wù)。recommend只有rpc服務(wù)，因為推薦服務(wù)需要依賴AI團(tuán)隊或者大數(shù)據(jù)團(tuán)隊提供的數(shù)據(jù)，我們只需要請求對應(yīng)的數(shù)據(jù)接口和做一些滿足業(yè)務(wù)的處理即可，所以這里recommend只有rpc服務(wù)。

代碼初始化

整個工程的結(jié)構(gòu)已經(jīng)定義清楚了，下面我們做服務(wù)代碼的初始化

我們使用goctl來進(jìn)行項目的初始化，比如我們先初始化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ù)代碼我們可以直接運行，默認(rèn)偵聽在8888端口

$ go run admin.go
Starting server at 0.0.0.0:8888...

對于rmq服務(wù)我們會使用go-zero提供的 kq 功能，這里先初始化main.go

到這里order服務(wù)的代碼初始化已經(jīng)完成，其他服務(wù)和order服務(wù)類似，這里就不再贅述了。

pkg下目前不需要初始化，當(dāng)我們需要提供業(yè)務(wù)通用功能的時候我們再進(jìn)行添加。

結(jié)束語

本篇我們講解了微服務(wù)的定義，微服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，服務(wù)關(guān)注單一的業(yè)務(wù)，服務(wù)間采用輕量級的通訊機(jī)制，每個微服務(wù)都可以獨立的部署和測試。

我們根據(jù)商城功能進(jìn)行了微服務(wù)的拆分，主要拆分了購物車、訂單、支付、商品、評論、推薦、賬號等服務(wù)，然后我們又說明了為什么需要引入BFF服務(wù)，BFF本質(zhì)上是一個用于做數(shù)據(jù)組裝的服務(wù)，對外提供面向業(yè)務(wù)功能的或者說面向客戶端UI的HTTP接口。

接著我們定義了我們這個工程的目錄結(jié)構(gòu)，主要分為api、rpc、rmq和admin等服務(wù)，不同服務(wù)的職責(zé)不同，api對外提供HTTP接口，rpc對內(nèi)提供RPC接口，rmq做流式數(shù)據(jù)的處理，admin面向運營后臺提供HTTP接口。

最后我們通過goctl對項目做了初始化，使用goctl可一鍵生成項目框架代碼，大大提供了生產(chǎn)力。

代碼倉庫：github.com/zhoushuguan…

參考

https://microservices.io/index.html

項目地址：https://github.com/zeromicro/go-zero

更多關(guān)于go zero服務(wù)拆分的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論