微服務概述

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

• 高度可維護和可測試
• 松散的耦合
• 可獨立部署
• 圍繞業(yè)務功能進行構建
• 由不同的小團隊進行維護

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

服務劃分

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

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

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

BFF層

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

• 但對于一個復雜的高并發(fā)的系統(tǒng)來說，我們需要處理各種異常的場景，比如某個頁面需要依賴多個微服務提供的數(shù)據(jù)，為了避免串行請求導致的耗時過長，我們一般會并行的請求多個微服務，這個時候其中的某個服務請求異常的話我們可能需要做一些特殊的處理，比如提供一些降級的數(shù)據(jù)等。還有我們的頁面展示的數(shù)據(jù)往往都是面向業(yè)務功能的，而不是單單某一個微服務的數(shù)據(jù)，這時候我們往往需要組裝多個微服務的數(shù)據(jù)來滿足需求，如果我們每個微服務都直接對外提供HTTP接口的話，那么這些復雜的數(shù)據(jù)組裝和異常處理等工作只能由客戶端來完成。
• 眾所周知客戶端是不宜做復雜的業(yè)務邏輯的，客戶端的重點應該更多是做交互體驗上的優(yōu)化，我們的整體架構需要做到前輕后重，即客戶端邏輯盡量少而把比較重的業(yè)務處理邏輯下沉到服務端，而服務端又根據(jù)業(yè)務職能拆分成了不同的微服務，這些微服務只關注單一的業(yè)務，那么這些面向業(yè)務場景的復雜邏輯的處理應該放到哪里呢？我們的解決方案就是加一層，即BFF層，通過BFF對外提供HTTP接口，客戶端只與BFF進行交互。

BFF層的引入解決了我們上面遇到的問題，但增加一層就會增加架構的復雜度，所以如果你的服務是一個單體應用的話，那么BFF是不必要的，引入它不會增加任何價值。對于我們這個項目來說，我們的應用程序依賴于微服務，同時我們需要面向業(yè)務功能提供HTTP接口和要保證接口的高可用，所以BFF對于我們這個項目來說是一個合適的選擇。

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

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

工程結構

我們采用集中管理的方式，把所有的服務放到一個大倉庫中，倉庫的目錄結構如下：

lebron為工程名，lebron下面有apps和pkg兩個目錄，其中apps存放的是我們所有的微服務，比如order為訂單相關的微服務，pkg目錄為所有服務共同依賴的包的存放路徑，比如所有的服務都需要依賴鑒權就可以放到pkg目錄下。

• app - BFF服務
• cart - 購物車服務
• order - 訂單服務
• pay - 支付服務
• product - 商品服務
• recommend - 推薦服務
• reply - 評論服務
• user - 賬號服務

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

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

apps目錄下每個服務的結構如下：

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

代碼初始化

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

我們使用goctl來進行項目的初始化，比如我們先初始化order，先進入order目錄下：

$ cd lebron/apps/order

執(zhí)行如下命令即可初始化order rpc代碼

$ goctl rpc new rpc

生成的代碼結構如下：

執(zhí)行如下命令即可初始化order admin代碼，注意order admin為api服務，直接對前端提供HTTP接口

$ goctl api new admin

生成的代碼結構如下：

生成的服務代碼我們可以直接運行，默認偵聽在8888端口

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

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

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

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

結束語

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

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

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

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

代碼倉庫：github.com/zhoushuguan…

參考

https://microservices.io/index.html

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

更多關于go zero服務拆分的資料請關注腳本之家其它相關文章！

最新評論