微服務概述
微服務架構是一種架構風格，它將一個大的系統構建為多個微服務的集合，這些微服務是圍繞業務功能構建的，服務關注單一的業務功能，這些服務具有以下特點：
- 高度可維護和可測試
- 鬆散的耦合
- 可獨立部署
- 圍繞業務功能進行構建
- 由不同的小團隊進行維護
微服務架構能夠快速、頻繁、可靠地交付大型、複雜的應用程式，通過業務拆分實現服務元件化，使用元件進行組合從而快速開發系統。
服務劃分
我們首先進行微服務的劃分，在實際的專案開發中，我們通常採用兩種微服務劃分策略，第一種方式是通過業務職能進行微服務邊界的劃分，第二種方式是通過DDD的界限上下文進行微服務邊界的劃分，我們這裡採用大家比較容易理解的業務職能的方式進行微服務劃分，再次貼上我們電商專案的思維導圖：
從以上思維導圖可以看出整個電商系統功能還是比較多的，我們根據業務職能做如下微服務的劃分：
- 商品服務(product) - 商品的新增、資訊查詢、庫存管理等功能
- 購物車服務(cart) - 購物車的增刪改查
- 訂單服務(order) - 生成訂單，訂單管理
- 支付服務(pay) - 通過呼叫第三方支付實現支付功能
- 賬號服務(user) - 使用者資訊、等級、封禁、地址管理
- 推薦服務(recommend) - 首頁商品推薦
- 評論服務(reply) - 商品的評論功能、評論的回覆功能
BFF層
一般對客戶端我們都會採用HTTP介面的方式提供服務，那是不是以上劃分的這些微服務都需要直接提供HTTP介面對外提供服務呢？這樣當然可以，架構整體看起來也比較簡單。
但對於一個複雜的高併發的系統來說，我們需要處理各種異常的場景，比如某個頁面需要依賴多個微服務提供的資料，為了避免序列請求導致的耗時過長，我們一般會並行的請求多個微服務，這個時候其中的某個服務請求異常的話我們可能需要做一些特殊的處理，比如提供一些降級的資料等。還有我們的頁面展示的資料往往都是面向業務功能的，而不是單單某一個微服務的資料，這時候我們往往需要組裝多個微服務的資料來滿足需求，如果我們每個微服務都直接對外提供HTTP介面的話，那麼這些複雜的資料組裝和異常處理等工作只能由客戶端來完成。眾所周知客戶端是不宜做複雜的業務邏輯的，客戶端的重點應該更多是做互動體驗上的優化，我們的整體架構需要做到前輕後重，即客戶端邏輯儘量少而把比較重的業務處理邏輯下沉到服務端，而服務端又根據業務職能拆分成了不同的微服務，這些微服務只關注單一的業務，那麼這些面向業務場景的複雜邏輯的處理應該放到哪裡呢？我們的解決方案就是加一層，即BFF層，通過BFF對外提供HTTP介面，客戶端只與BFF進行互動。
BFF層的引入解決了我們上面遇到的問題，但增加一層就會增加架構的複雜度，所以如果你的服務是一個單體應用的話，那麼BFF是不必要的，引入它不會增加任何價值。對於我們這個專案來說，我們的應用程式依賴於微服務，同時我們需要面向業務功能提供HTTP介面和要保證介面的高可用，所以BFF對於我們這個專案來說是一個合適的選擇。
我們可以提供多個BFF嗎？答案是當然可以。BFF的目的是為客戶端提供一個集中的介面，例如移動端頁面和瀏覽器頁面的資料協議不同，這種情況下為了更好的表示資料，可以使用兩個BFF，同時只供一個BFF如果該BFF異常就會導致所有的業務受影響，提供多個BFF也可以提高服務的可用性，降低業務異常的影響面。多個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 - 也是對內的服務，區別於rpc，更多的是面向運營側的且資料許可權較高，通過隔離可帶來更好的程式碼級別的安全，直接提供HTTP介面
apps目錄下每個服務的結構如下：
大多服務都會拆分成rpc、rmq和admin來滿足對內提供rpc介面和運營資料的需求，同時通過rmq來處理流式任務。比較特殊的是app下只有api服務，因為app是BFF所有隻有api服務，後面可能會增加rmq服務，比如來流式處理使用者每天首次登陸加經驗之類的邏輯，我們後面可以隨時擴充套件，暫時先只提供api服務。recommend只有rpc服務，因為推薦服務需要依賴AI團隊或者大資料團隊提供的資料，我們只需要請求對應的資料介面和做一些滿足業務的處理即可，所以這裡recommend只有rpc服務。
程式碼初始化
整個工程的結構已經定義清楚了，下面我們做服務程式碼的初始化
我們使用goctl來進行專案的初始化，比如我們先初始化order，先進入order目錄下：
$ cd lebron/apps/order執行如下命令即可初始化order rpc程式碼
$ goctl rpc new rpc生成的程式碼結構如下：
執行如下命令即可初始化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服務的程式碼初始化已經完成，其他服務和order服務類似，這裡就不再贅述了。
pkg下目前不需要初始化，當我們需要提供業務通用功能的時候我們再進行新增。
結束語
本篇我們講解了微服務的定義，微服務是圍繞業務功能構建的，服務關注單一的業務，服務間採用輕量級的通訊機制，每個微服務都可以獨立的部署和測試。
我們根據商城功能進行了微服務的拆分，主要拆分了購物車、訂單、支付、商品、評論、推薦、賬號等服務，然後我們又說明了為什麼需要引入BFF服務，BFF本質上是一個用於做資料組裝的服務，對外提供面向業務功能的或者說面向客戶端UI的HTTP介面。
接著我們定義了我們這個工程的目錄結構，主要分為api、rpc、rmq和admin等服務，不同服務的職責不同，api對外提供HTTP介面，rpc對內提供RPC介面，rmq做流式資料的處理，admin面向運營後臺提供HTTP介面。
最後我們通過goctl對專案做了初始化，使用goctl可一鍵生成專案框架程式碼，大大提供了生產力。
希望本篇文章對你有所幫助，謝謝。
每週一、週四更新
程式碼倉庫：github.com/zhoushuguang/lebron
參考
blog.bitsrc.io/bff-pattern-backend...
專案地址
歡迎使用 go-zero 並 star 支援我們！
微信交流群
關注『微服務實踐』公眾號並點選 交流群 獲取社群群二維碼。
本作品採用《CC 協議》，轉載必須註明作者和本文連結