經常翻閱微服務材料的話，總會碰到 microservices.io 這個網站，總結了微服務方方面面的設計模式。網站的作者是 Chris Richardson。

這些相關的經驗在 2018 年成為了《微服務架構設計模式》這本書，并且 2019 年引進國內。當時我第一時間購入了這本書，中間斷斷續續地一直沒看完。最近準備分享內容的時候又翻起這本書，這次完整地讀完了一遍。感覺應該是目前微服務領域最好的一本書了。另一本《Building Microservices》也不錯，不過內容還是稍微單薄了一些。

這本書為我們提供了宏觀上俯瞰微服務整個生態的大圖，比如：

當然，18 年的時候，service mesh 之類的東西還沒有太火，所以后來在網站上有個更新的版本：

個人很喜歡這種大圖，不管什么領域，我只要照著圖去一點一點填坑就行了，沒有這樣的圖，總覺得是在望不見頭的技術森林里兜兜轉轉，找不到北。

下面簡單寫一寫我對這本書的總結，里面 saga 和測試的部分我就先省略了。

單體服務的困境

在單體時代，大家在一個倉庫里開發，代碼沖突解決起來很麻煩，上線的 CI/CD pipeline 也是等待到死。

拆分了以后，至少大家有各自的代碼庫，各自的上線流程，各自的線上服務。這樣上線不打架了，上線以后也可以自己玩自己的灰度流程，一般不會互相影響。

服務拆分

雖然說是拆了，不過拆分也是要講究方法的。

書里提供了兩種思路，一種是按照業務/商業能力拆分，一種是按照 DDD 中的 sub domain 拆分。

• 供應商管理

• • 送餐員信息管理

  • 餐館信息管理：管理餐館的訂單、營業時間、營業地點

• 消費者管理

• • 管理消費者信息

• 訂單獲取和履行

• • 消費者訂單管理：讓消費者可以創建、管理訂單

  • 餐館訂單管理：讓餐館可以管理訂單的準備過程

• 送餐管理

• • 送餐員狀態管理：管理可以進行接單操作的送餐員的實時狀態

  • 配送管理：訂單配送追蹤

• 會計

• • 消費者記賬：管理消費者的訂單記錄

  • 餐館記賬：管理餐館的支付記錄

  • 配送員記賬：管理配送員的收入信息

最終大概會形成上面這些服務。

用 DDD 來做分析，其實我們得到的結果也差不多：

在拆分時，我們還應該用 SOLID 中的 SRP 原則和另外一個閉包原則 CCP(common closure principle) 來進行指導。

在拆分后，也要注意微服務的拆分會額外給我們帶來的問題：

• 網絡延遲

• 服務間同步通信導致可用性降低

• 在服務間維持數據一致性

• 獲取一致的數據視圖

• 阻塞拆分的上帝類

服務集成

分布式服務通信大概可以分為 one-to-one 和 one-to-many：

RPC 很好理解，同步的 request/response。異步通信，一種是回調式的 request/response，一種是一對多的 pub/sub。

具體到 RPC 的話，可以使用多種協議和框架：

不過當 API 更新時，應該遵循 semver 的規范進行更新。社區里 gRPC 很多次更新都沒有遵守 semver，給它的依賴方都造成了不小的麻煩。感興趣的同學應該可以搜到一些相關的事件。

不得不說 Google 的程序員也并不是事事靠譜。

RPC 進行服務集成的時候，要注意不要被某些不穩定的服務慢響應拖死，要注意設置超時，熔斷。

服務與服務之間要能找得到彼此，有兩種方式，一種是基于服務注冊中心的服務發現。

一種是基于 dns 的服務發現。基于 DNS 的現在應該不太多了。

除了 RPC 以外，還可以使用消息來進行服務間的集成。

使用 MQ 也可以模擬 RPC 的 request/response，不過這樣會使你的服務強依賴于 MQ，如果 MQ 故障，那整個系統隨之崩潰。

一般我們使用的是 broker-based mq 通信，但也有無 broker 的異步通信，書中這里舉了個 ZeroMQ 的例子，之前個人不是很了解，需要再調研一下。

Event Sourcing

event sourcing 是一種特殊的設計模式，不記錄實體的終態，而是記錄所有狀態修改的事件。然后通過對事件進行計算來得到實體最終的狀態。

但這樣事件累積太多以后會有性能問題，所以可以對一部分歷史數據進行計算，得到一個中間的快照，之后的計算在快照的基礎上再疊加。

看起來方案很酷，我們在實際工作中也確實在一些下游的計算邏輯中使用過這種設計模式，不過它也是有缺陷的：

• 事件本身結構變化時，新老版本兼容比較難做

• 如果代碼中要同時處理新老版本數據，那么升級幾次后會非常難維護

• 因為容易追溯，所以刪除數據變得非常麻煩，GDPR 類的法規要求用戶注銷時必須將歷史數據刪除干凈，這對 Event Sourcing 是一個巨大的挑戰

在使用異步消息來做解耦的時候，我們也會遇到一些實際的業務問題：

• 這個數據我需要，你能不能在消息里幫我透傳一下

• 你重構的時候怎么把這個字段刪了，我還要用呢

• 你們原來的狀態機變更都有 event，本來有三個，怎么現在變成兩個了？

• 你們 API 故障的時候，怎么消息順序亂了？

這要求我們能有對上游的領域事件進行校驗的系統，這里可以參考 Google 的 schema validation 這個項目，之前我在 《MQ 正在變成臭水溝》一文中有詳述。這里就不提了。

查詢模式

很多查詢邏輯其實就是進行 API 的數據組合，這個涉及到需要組合數據的 API 組合器，和數據提供方：

• API 組合器：通過查詢數據提供方的服務實現查詢操作

• 數據提供方：提供數據

雖然看起來挺簡單，寫代碼的時候，下面這些問題還是難處理：

• 誰來負責拼裝這些數據？有時是應用，有時是外部的 API Gateway，難以定立統一的標準，在公司里也經常扯皮

• 增加額外的開銷-一個請求要查詢很多接口

• 可用性降低-每個服務可用性 99.5%，實際接口可能是 99.5^5=97.5

• 事務數據一致性難保障-需要使用分布式事務框架/使用事務消息和冪等消費

CQRS

業務開發經常自嘲是 CRUD 工程師，在架構設計里，CRUD 的 R 可以單獨拆出來，像下面這樣。

拆出來的好處？互聯網大多是寫少讀多的服務，將關注點分離之后，讀服務和寫服務的存儲可以做異構。

比如寫可以是 MySQL，而讀則可以是各種非常容易做橫向擴展的 NoSQL。碰到檢索需求，讀還可以是 Elasticsearch。

讀服務可以訂閱寫服務的 domain event，也可以是 MySQL 的 binlog。

在消費上游數據時，需要根據業務邏輯去判斷有些狀態機要怎么做處理。這里其實數據上是有耦合的，并不是放個 MQ 和 domain event 就能解耦干凈了。

CQRS 的缺點也比較明顯：

• 架構復雜

• 數據復制延遲問題

• 查詢一致性問題

• 并發更新問題處理

• 冪等問題需要處理

外部 API 模式

現在的互聯網公司一般客戶端都是多端，web、移動、向第三方開放的 open API。

如果我們直接把之前用拆分方法拆出來的這些內部 API 開放出去，那未來內部的 API 想升級就會非常非常地麻煩。

在單體時代，客戶端走弱網 internet，只需要一次調用。微服務化以后，如果不做任何優化，那在 internet 這種慢速網絡上就需要有多次調用。

這就是我們為什么需要中間有一個 API Gateway 的原因。

有了 Gateway 之后，在 internet 依然還是一次調用，在內部 IDC 強網絡的狀態下多次網路調用相對沒有那么糟糕。

API Gateway 涉及到這些不同端的 API Gateway 應該要誰來維護的問題。下面是一種理想的情況，Mobile 團隊負責維護他們在 Gateway 里的 API(也可能是單獨的 Gateway)，web 端團隊維護 web 的 Gateway，open API 團隊負責維護第三方應用的 Gateway API。

網關基礎設施團隊負責提供這三方都需要的基礎庫。

在研發 API Gateway 的時候，我們有多種可選項：

• 直接使用開源產品

• • Kong

  • APISix

  • Traefik

• 自研

• • Zuul

  • Spring Cloud Gateway

  • RESTFul 自己做一個

  • GraphQL 自己做一個

開源的 API Gateway 大多不支持 API 數據組合功能，所以公司內的 API Gateway 有時候有兩層，一層是 nginx 之類的負責簡單路由和鑒權的 gateway，后面還有一個業務的 BFF 來負責拼裝端上需要的數據。

如果我們都是自研，那就可以在一個模塊上把 API Gateway 需要的功能都實現。這里經常討論的一個問題是，我們是要使用 REST 還是類似 GraphQL 的圖查詢。

Netflix 的工程師在 2012 年發表過一篇文章：

《為什么 REST 讓我半夜睡不著》，老哥還挺幽默。內容大概是講 Netflix 要面對成百上千的終端設備，Netflix 曾經希望能給所有終端提供大一統的方案，大家使用統一的 REST API，但后來發現這種統一的方式是放棄了對任一有自己特性的設備的優化，比如有些設備內存小，有些設備屏幕小，這些設備上你返回的很多字段數據對他們來說根本就用不上，純粹是浪費網絡帶寬。有些設備用流式響應比返回完整響應性能更好，這也應該是要考慮的優化點。

所以 Netflix 做了一個叫 falcor 的方案，其實和后來 Facebook 的 GraphQL 非常類似，是用 JSON Graph 來描述內部 API 能提供的數據，然后用 JS 來定制圖上的查詢。

現在大多數人比較熟悉的還是 GraphQL：

GraphQL 是個好東西，但之前我個人對使用 GraphQL 一直持懷疑態度，主要是因為：

• 網關容易被客戶端的修改直接帶崩

• 穩定性非常難保障

• 中文互聯網上講 GraphQL 的基本都沒有提到限流，或者一筆帶過，這是不太負責任的

直到最近我發現國外某公司公開了他們的 GraphQL 限流方案，這個方案非常有意思，我會在下一篇文章進行分享。

這本《微服務架構模式》難能可貴的地方在于幾乎所有的技術方案，都很詳盡地給出了優劣，這在其它書里是比較少見的。我們在某些人的文章和方案里永遠只能看到優點，但在實踐中落地技術方案的時候，其實更關注缺陷。對缺陷有心理準備，才不會在新方案出問題的時候心慌。

個人覺得這本書，無論是對微服務剛入門，或是工作幾年的人，都值得一讀。

在本文最后做個簡單的抽獎活動，本文回復的第一、第三、第十、第三十個人，都能夠得到一本《微服務架構模式》，你需要寫寫自己對微服務的見解，或者簡短地分享一下自己在公司中碰到的微服務的坑就可以。

100 字以內就行，不用長篇大論~

沒抽到的老哥就只能自己買了，[doge]。

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的《微服务架构设计模式》总结，文末送书的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。