基於grpc的微服務實踐

簡介

近一兩年來，微服務架構已經成爲熱門話題（microservices.io)，與傳統的一體化應用架構相比，微服務架構在開發、測試、部署方面都有衆多吸引人之處，愈來愈多沒有歷史包袱的新項目都啓用微服務架構的模式來開發。

咱們這個團隊通過深刻思考以後，決定在一塊兒美這個APP的後端開發中，選擇go做爲開發語言，採用微服務模式來實現，通過近半年的實踐，造成了一些心得，簡單總結後分享出來，但願可以給你們一些幫助。

框架選擇

不一樣的團隊在選擇基礎框架（庫）時考慮的要素不一樣，咱們團隊更喜歡小而美的框架，儘量不要讓框架侵入業務，易於升級、維護和替換，因此咱們更願意選擇Library而不是Framework。

在web方面，咱們選擇了negroni做爲middleware庫，採用性能不錯的httprouter替換go標準庫的mux，而沒有用任何web相關的框架。

在微服務之間的rpc調用方面，爲了未來的擴展性、跨語言調用等因素，咱們沒有直接用go標準庫的rpc模塊，而是採納了google最新推出的grpc。但grpc自己屬於比較重型的rpc框架，對業務代碼有必定的侵入性， 咱們作了一系列的庫（包括worpc、worc、wonaming等）來屏蔽這些沒必要要的業務代碼侵入 ，保持了業務代碼自己的整潔。

微服務劃分

在微服務體系中，如何切分微服務也是一個重要的話題，在咱們的實踐中，咱們遵循了以下一些原則：

1. 邏輯獨立、邊界清晰的模塊做爲一個獨立的微服務
2. 每一個table只由一個微服務操做（包括插入、讀取、更改、刪除等）
3. table之間不引入外鍵約束，id字段所有采用uuid
4. 將須要保持數據一致性的操做放在一個微服務中，避免跨服務帶來的數據一致性難題
5. 微服務之間的通訊，儘量採用消息隊列實現鬆耦合，當須要同步調用時再借助於rpc
6. 微服務獨立部署，經過etcd實現服務的註冊與發現

整體架構

Gateway

Gateway是微服務對外提供服務的一個屏障，它的核心點在於：

1. 屏蔽微服務之間經過消息隊列、rpc等通訊方式，爲Web頁面和移動APP提供基於HTTP協議的RESTful API接口
2. 對每個http業務請求進行必要的鑑權和數據完整性、合法性檢查，以減小微服務的負擔，讓微服務的代碼更純粹
3. 微服務部署體系中，每一個微服務可能會部署多個實例，Gateway還承擔着在這些實例中進行負載均衡的功能
4. 進行必要的日誌輸出、監控打點等功能，對每個來自於APP和頁面的http請求，生成一個惟一的trace id，並將trace id傳導到每個後續的微服務中，以便後續的查錯和性能調優
5. Gateway的每個http請求都是無狀態的，採用JWT（Json Web Token）機制實現一個客戶端的請求狀態信息的傳遞

服務的註冊與發現wonaming

微服務體系中，服務的註冊和發現對總體架構很是重要，尤爲對於同步的rpc調用，每一個服務有多少實例，每一個實例的地址等，都須要有一個統一的管理。咱們採用etcd保存服務信息，同時封裝了wonaming做爲微服務註冊和發現的中間件，它的主要功能包括：

1. 服務在啓動時，調用wonaming向etcd註冊包含TTL的服務「索引」、
2. 註冊後，服務與etcd保持定時心跳，當微服務主動退出或超時，服務解註冊並「下線」
3. 在Gateway中，經過resolver進行服務發現，配合grpc提供的balancer實現負載均衡，resolver啓動後會對etcd中的 /wonaming 目錄進行監控，當有服務註冊或者解註冊時，動態維護可用服務清單。

1. r := wonaming.NewResolver(name)
2. b := grpc.RoundRobin(r)
3. conn, err := grpc.Dial(etcd, grpc.WithInsecure(), grpc.WithBalancer(b))

服務的rpc調用worc

grpc是一個比較重的rpc框架，當客戶端經過grpc調用服務端時，須要大量的重複性代碼來創建鏈接、調用、處理錯誤返回等，影響業務代碼的整潔性，而且對業務代碼具備很強的侵入性，爲了規避這個問題，咱們封裝了worc，以實現便捷的grpc調用：

1. resp, err := worc.CallRPC(ctx, "hello", "Hello", req)

grpc的中間件鏈worpc

grpc提供了interceptor機制，但並無提供chain來實現不一樣的中間件的順序執行，爲了將不一樣的中間件功能（如鑑權、日誌、recover）封裝在不一樣的函數裏，worpc提供了組合gprc interceptor爲一個chain的能力，能夠根據自身業務的須要，撰寫不一樣的grpc中間件進行組合，好比實現 grpc 的 recovery 與 log 中間件：

1. func Recovery(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (resp interface{}, err error) {
2. defer func() {
3. if r := recover(); r != nil {
4. // log stack
5. stack := make([]byte, MAXSTACKSIZE)
6. stack = stack[:runtime.Stack(stack, false)]
7. log.CtxErrorf(ctx, "panic grpc invoke: %s, err=%v, stack:\n%s", info.FullMethod, r, string(stack))
8. // if panic, set custom error to 'err', in order that client and sense it.
9. err = grpc.Errorf(codes.Internal, "panic error: %v", r)
10. }
11. }()
12. return handler(ctx, req)
13. }
14.  
15. func Logging(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (resp interface{}, err error) {
16. start := time.Now()
17.  
18. log.CtxInfof(ctx, "calling %s, req=%s", info.FullMethod, marshal(req))
19. resp, err = handler(ctx, req)
20. log.CtxInfof(ctx, "finished %s, took=%v, resp=%v, err=%v", info.FullMethod, time.Since(start), marshal(resp), err)
21.  
22. return resp, err
23. }

1. s := grpc.NewServer(grpc.UnaryInterceptor(worpc.UnaryInterceptorChain(worpc.Recovery, worpc.Logging)))

經過以上組合，可爲微服務提供panic恢復能力，保障服務穩定可用；同時還將上文中提到的注入context中的trace id取出，這樣Gateway與微服務的日誌經過就銜接了起來，方便查錯、調優等。

其它經驗

1. 使用grpc.Errorf封裝業務中的邏輯錯誤，隨grpc服務調用一塊兒返回，將業務response與error 分離。
2. 數據可在Gateway中完成組裝工做，但無需刻意避免微服務互調，理清依賴關係，尤爲當protobuf升級時，根據具體業務來判斷引用微服務是否須要同步重部署。
3. 微服務雖好，但必定程度上會加大實施難度，要根據業務體量合理入坑。

總結

以上是微服務架構在咱們團隊的實踐方案，麻雀雖小，五臟俱全。經過各中間件的靈活組合，保障業務有序與服務的高可用，還不抓緊實踐起來？在後續的文章中，咱們還會介紹目前微服務測試、運維及部署方案。