從軟體開發早期（1960 年代）開始，應對大型軟體系統中的復雜性一直是一項令人生畏的任務。多年來為了應對軟體系統的復雜性，軟體工程師和架構師們做了許多嘗試：David Parnas 的模組化和封裝 （1972）， Edsger W. Dijkstra （1974）的關註點分離以及 SOA（1988）。

他們都是使用分而治之這項成熟的傳統技術來應對大型系統的復雜性。自 2010 年開始，這些技術被證實無法繼續應對 Web 級套用或者現代大型企業級套用的復雜性。因此架構師和工程師們發展出了一種全新的現代方式來解決這個問題，就是微服務架構。它雖然延續了分而治之的思想，但卻是以全新的方式來實作的。

軟體設計模式是解決軟體設計中常見問題的通用、可復用的解決方案。設計模式讓我們可以分享通用詞匯並使用經實戰檢驗的方案，以免重復造輪子。我先簡單介紹下微服務架構。

透過閱讀這篇文章，你會學到：

最重要的微服務架構設計模式，包括其優缺點、用例、上下文、技術棧範例及可用資源。

「 請註意，本清單中的大部份設計模式常出現在多種語境中，並且可以在非微服務架構中使用。而我將在微服務這個特定語境中介紹它們。

# 微服務架構

我在之前的部落格【微服務架構概述及為什麽要套用在下個計畫】和【單體軟體架構真的終結了嗎？】中對微服務架構有非常詳盡的介紹。如果你感興趣，可以閱讀這兩篇部落格來深入了解。

那到底什麽是微服務架構？有很多種定義方法。我的定義是這這樣的：

微服務架構指的是將大型復雜系統按功能或者業務需求垂直切分成更小的子系統，這些子系統以獨立部署的子行程存在，它們之間透過輕量級的、跨語言的同步（比如 REST，gRPC）或者異步（訊息）網路呼叫進行通訊。

下面是基於微服務架構的商業 Web 套用的元件檢視：

微服務架構的優點

微服務架構的缺點

何時使用微服務架構

# 微服務架構的設計模式

獨享資料庫（Database per Microservice）

當一家公司將大型單體系統替換成一組微服務，首先要面臨的最重要決策是關於資料庫。單體架構會使用大型中央資料庫。即使轉移到微服務架構許多架構師仍傾向於保持資料庫不變。雖然有一些短期收益，但它卻是反模式的，特別是在大規模系統中，微服務將在資料庫層嚴重耦合，整個遷移到微服務的目標都將面臨失敗（例如，團隊授權、獨立開發等問題）。

更好的方法是為每個微服務提供自己的數據儲存，這樣服務之間在資料庫層就不存在強耦合。這裏我使用資料庫這一術語來表示邏輯上的數據隔離，也就是說微服務可以共享物理資料庫，但應該使用分開的數據結構、集合或者表，這還將有助於確保微服務是按照領域驅動設計的方法正確拆分的。

優點

缺點

何時使用獨享資料庫

何時不宜使用獨享資料庫

可用技術範例

事件源（Event Sourcing）

在微服務架構中，特別使用獨享資料庫時，微服務之間需要進行數據交換。對於彈性高可伸縮的和可容錯的系統，它們應該透過交換事件進行異步通訊。在這種情況，您可能希望進行類似更新資料庫並行送訊息這樣的原子操作，如果在大數據量的分布式場景使用關聯式資料庫，您將無法使用兩階段鎖協定（2PL），因為它無法伸縮。而 NoSQL 資料庫因為大多不支持兩階段鎖協定甚至無法實作分布式事務。

在這些場景，可以基於事件的架構使用事件源模式。在傳統資料庫中，直接儲存的是業務實體的當前「狀態」，而在事件源中任何「狀態」更新事件或其他重要事件都會被儲存起來，而不是直接儲存實體本身。這意味著業務實體的所有更改將被保存為一系列不可變的事件。因為數據是作為一系列事件儲存的，而非直接更新儲存，所以各項服務可以透過重放事件儲存中的事件來計算出所需的數據狀態。

優點

缺點

何時使用事件源

何時不宜使用事件源

可用技術範例

命令和查詢職責分離（CQRS）

如果我們使用事件源，那麽從事件儲存中讀取數據就變得困難了。要從數據儲存中獲取實體，我們需要處理所有的實體事件。有時我們對讀寫操作還會有不同的一致性和吞吐量要求。

這種情況，我們可以使用 CQRS 模式。在該模式中，系統的數據修改部份（命令）與數據讀取部份（查詢）是分離的。而 CQRS 模式有兩種容易令人混淆的模式，分別是簡單的和高級的。

在其簡單形式中，不同實體或 ORM 模型被用於讀寫操作，如下所示：

它有助於強化單一職責原則和分離關註點，從而實作更簡潔的設計。

在其高級形式中，會有不同的數據儲存用於讀寫操作。高級的 CQRS 通常結合事件源模式。根據不同情況，會使用不同型別的寫數據儲存和讀數據儲存。寫數據儲存是「記錄的系統」，也就是整個系統的核心源頭。

對於讀頻繁的應用程式或微服務架構，OLTP 資料庫（任何提供 ACID 事務保證的關系或非關聯式資料庫）或分布式訊息系統都可以被用作寫儲存。對於寫頻繁的應用程式（寫操作高可伸縮性和大吞吐量），需要使用寫可水平伸縮的資料庫（如全球托管的公共雲資料庫）。標準化的數據則保存在寫數據儲存中。

對搜尋（例如 Apache Solr、Elasticsearch）或讀操作（KV 資料庫、文件資料庫）進行最佳化的非關聯式資料庫常被用作讀儲存。許多情況會在需要 SQL 查詢的地方使用讀可伸縮的關聯式資料庫。非標準化和特殊最佳化過的數據則保存在讀儲存中。

數據是從寫儲存異步復制到讀儲存中的，所以讀儲存和寫儲存之間會有延遲，但最終是一致的。

優點

缺點

何時使用 CQRS

何時不宜使用 CQRS

可用技術範例

Saga

如果微服務使用獨享資料庫，那麽透過分布式事務管理一致性是一個巨大的挑戰。你無法使用傳統的兩階段送出協定，因為它要麽不可伸縮（關聯式資料庫），要麽不被支持（多數非關聯式資料庫）。

但您還是可以在微服務架構中使用 Saga 模式實作分布式事務。Saga 是 1987 年開發的一種古老模式，是關聯式資料庫中關於大事務的一個替代概念。但這種模式的一種現代變種對分布式事務也非常有效。Saga 模式是一個本地事務序列，其每個事務在一個單獨的微服務內更新數據儲存並釋出一個事件或訊息。

Saga 中的第一個事務是由外部請求（事件或動作）初始化的，一旦本地事務完成（數據已保存在數據儲存且訊息或事件已釋出），那麽釋出的訊息或事件則會觸發 Saga 中的下一個本地事務。

如果本地事務失敗，Saga 將執行一系列補償事務來回滾前面本地事務的更改。

Saga 事務協調管理主要有兩種形式：

優點

缺點

何時使用 Saga

何時不宜使用 Saga

可用技術範例

面向前端的後端 （BFF）

在現代商業套用開發，特別是微服務架構中，前後端套用是分離和獨立的服務，它們透過 API 或 GraphQL 連線。如果應用程式還有移動 App 客戶端，那麽 Web 端和移動客戶端使用相同的後端微服務就會出現問題。因為移動客戶端和 Web 客戶端有不同的螢幕尺寸、顯示器、效能、能耗和網路頻寬，它們的 API 需求不同。

面向前端的後端模式適用於需要為特殊 UI 客製單獨後端的場景。它還提供了其他優勢，比如作為下遊微服務的封裝，從而減少 UI 和下遊微服務之間的頻繁通訊。此外，在高安全要求的場景中，BFF 為部署在 DMZ 網路中的下遊微服務提供了更高的安全性。

優點

缺點

何時使用 BFF

何時不宜使用 BFF

可用技術範例

API 閘道器

在微服務架構中，UI 通常連線多個微服務。如果微服務是細粒度的（FaaS） ，那麽客戶端可能需要連線非常多的微服務，這將變得繁雜和具有挑戰性。此外，這些服務包括它們的 API 還將不斷前進演化。大型企業還希望能有其他橫切關註點（SSL 終止、身份驗證、授權、節流、日誌記錄等）。

一個解決這些問題的可行方法是使用 API 閘道器。API 閘道器位於客戶端 APP 和後端微服務之間充當 facade，它可以是反向代理，將客戶端請求路由到適當的後端微服務。它還支持將客戶端請求扇出到多個微服務，然後將響應聚合後返回給客戶端。它還支持必要的橫切關註點。

優點

缺點

何時使用 API 閘道器

何時不宜使用 API 閘道器

可用技術範例

Strangler

如果想在執行中的計畫中使用微服務架構，我們需要將遺留的或現有的單體套用遷移到微服務。將現有的大型線上單體應用程式遷移到微服務是相當有挑戰性的，因為這可能破壞應用程式的可用性。

一個解決方案是使用 Strangler 模式。Strangler 模式意味著透過使用新的微服務逐步替換特定功能，將單體應用程式增量地遷移到微服務架構。此外，新功能只在微服務中添加，而不再添加到遺留的單體套用中。

然後配置一個 Facade （API 閘道器）來路由遺留單體套用和微服務間的請求。當某個功能從單體套用遷移到微服務，Facade 就會攔截客戶端請求並路由到新的微服務。一旦遷移了所有的功能，遺留單體應用程式就會被「扼殺（Strangler）」，即退休。

優點

缺點

何時使用 Strangler

可用技術範例

斷路器

在微服務架構中，微服務透過同步呼叫其他服務來滿足業務需求。服務呼叫會由於瞬時故障（網路連線緩慢、超時或暫時不可用） 導致失敗，這種情況重試可以解決問題。然而，如果出現了嚴重問題（微服務完全失敗），那麽微服務將長時間不可用，這時重試沒有意義且浪費寶貴的資源（執行緒被阻塞，CPU 周期被浪費）。此外，一個服務的故障還會引發整個套用系統的級聯故障。這時快速失敗是一種更好的方法。

在這種情況，可以使用斷路器模式挽救。一個微服務透過代理請求另一個微服務，其工作原理類似於電氣斷路器，代理透過統計最近發生的故障數量，並使用它來決定是繼續請求還是簡單的直接返回異常。

斷路器可以有以下三種狀態：

優點

缺點

何時使用斷路器

何時不宜使用斷路器

可用技術範例

外部化配置

每個業務套用都有許多用於各種基礎設施的配置參數（例如，資料庫、網路、連線的服務地址、憑據、證書路徑）。此外在企業應用程式通常部署在各種執行環境（Local、 Dev、 Prod）中，實作這些的一個方法是透過內部配置。這是一個致命糟糕實踐，它會導致嚴重的安全風險，因為生產憑證很容易遭到破壞。此外，配置參數的任何更改都需要重新構建應用程式，這在在微服務架構中會更加嚴峻，因為我們可能擁有數百個服務。

更好的方法是將所有配置外部化，使得構建過程與執行環境分離，生產的配置檔只在執行時或透過環境變量使用，從而最小化了安全風險。

優點

缺點

何時使用外部化配置

何時不宜使用外部化配置

可用技術範例

消費端驅動的契約測試

在微服務架構中，通常有許多有不同團隊開發的微服務。這些微型服務協同工作來滿足業務需求（例如，客戶請求），並相互進行同步或異步通訊。消費端微服務的整合測試具有挑戰性，通常用 TestDouble 以獲得更快、更低成本的測試執行。但是 TestDouble 通常並不能代表真正的微服務提供者，而且如果微服務提供者更改了它的 API 或 訊息，那麽 TestDouble 將無法確認這些。另一種選擇是進行端到端測試，盡管它在生產之前是強制性的，但卻是脆弱的、緩慢的、昂貴的且不能替代整合測試（Test Pyramid）。

在這方面消費端驅動的契約測試可以幫助我們。在這裏，負責消費端微服務的團隊針對特定的伺服端微服務，編寫一套包含了其請求和預期響應（同步）或訊息（異步）的測試套件，這些測試套件稱為顯式的約定。對於微服務伺服端，將其消費端所有約定的測試套件都添加到其自動化測試中。當特定伺服端微服務的自動化測試執行時，它將一起執行自己的測試和約定的測試並進行驗證。透過這種方式，契約測試可以自動的幫助維護微服務通訊的完整性。

優點

缺點

何時使用需求驅動的契約測試

何時不宜使用消費端驅動的契約測試

可用技術範例

# 總結

在現代大規模企業軟體開發中，微服務架構能夠幫助開發擴充套件規模並帶來很多長期收益。但是微服務架構並不是隨處可用的銀彈，如果套用在錯誤的應用程式型別，微服務架構將弊大於利。希望采用微服務架構的開發團隊應該遵循最佳實踐，並使用一系列可重用的、久經錘煉的設計模式。

微服務架構中至關重要的設計模式是獨享資料庫。實作這種設計模式具有挑戰性，需要其他幾種密切相關的設計模式（事件驅動、 CQRS、 Saga）來支持。在具有多個客戶端（Web、 Mobile、 Desktop、 Smart Devices）的典型業務應用程式中，客戶端和微服務之間的通訊量可能是很大的，並且需要統一的安全控制，在這種情況面向前端的後端和 API 閘道器的設計非常有用。

此外，斷路器模式可以大大地幫助應對這類應用程式的錯誤處理場景。遷移遺留的單體套用到微服務是極具挑戰性的，而 Strangler 模式可以幫助做到這點。消費端驅動的契約測試是微服務整合測試的基礎模式。另外外部化配置是任何現代化應用程式開發中的一種必備模式。

這個系列並不全面，在實際情況中您可能需要其他的設計模式，但這個系列能為您提供一個關於微服務架構設計模式的極好介紹。

熱門推薦