微服務(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ù)和可測(cè)試
• 松散的耦合
• 可獨(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)支付功能
• 賬號(hào)服務(wù)(user) - 用戶信息、等級(jí)、封禁、地址管理
• 推薦服務(wù)(recommend) - 首頁商品推薦
• 評(píng)論服務(wù)(reply) - 商品的評(píng)論功能、評(píng)論的回復(fù)功能

BFF層

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

• 但對(duì)于一個(gè)復(fù)雜的高并發(fā)的系統(tǒng)來說，我們需要處理各種異常的場(chǎng)景，比如某個(gè)頁面需要依賴多個(gè)微服務(wù)提供的數(shù)據(jù)，為了避免串行請(qǐng)求導(dǎo)致的耗時(shí)過長(zhǎng)，我們一般會(huì)并行的請(qǐng)求多個(gè)微服務(wù)，這個(gè)時(shí)候其中的某個(gè)服務(wù)請(qǐng)求異常的話我們可能需要做一些特殊的處理，比如提供一些降級(jí)的數(shù)據(jù)等。還有我們的頁面展示的數(shù)據(jù)往往都是面向業(yè)務(wù)功能的，而不是單單某一個(gè)微服務(wù)的數(shù)據(jù)，這時(shí)候我們往往需要組裝多個(gè)微服務(wù)的數(shù)據(jù)來滿足需求，如果我們每個(gè)微服務(wù)都直接對(duì)外提供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ù)場(chǎng)景的復(fù)雜邏輯的處理應(yīng)該放到哪里呢？我們的解決方案就是加一層，即BFF層，通過BFF對(duì)外提供HTTP接口，客戶端只與BFF進(jìn)行交互。

BFF層的引入解決了我們上面遇到的問題，但增加一層就會(huì)增加架構(gòu)的復(fù)雜度，所以如果你的服務(wù)是一個(gè)單體應(yīng)用的話，那么BFF是不必要的，引入它不會(huì)增加任何價(jià)值。對(duì)于我們這個(gè)項(xiàng)目來說，我們的應(yīng)用程序依賴于微服務(wù)，同時(shí)我們需要面向業(yè)務(wù)功能提供HTTP接口和要保證接口的高可用，所以BFF對(duì)于我們這個(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)目為了簡(jiǎn)化只會(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 - 評(píng)論服務(wù)
• user - 賬號(hào)服務(wù)

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

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

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

大多服務(wù)都會(huì)拆分成rpc、rmq和admin來滿足對(duì)內(nèi)提供rpc接口和運(yùn)營(yíng)數(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ù)，我們只需要請(qǐng)求對(duì)應(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ù)，直接對(duì)前端提供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...

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

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

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

結(jié)束語

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

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

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

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

代碼倉庫：github.com/zhoushuguan…

參考

https://microservices.io/index.html

項(xiàng)目地址：https://github.com/zeromicro/go-zero

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

最新評(píng)論