與面向對象設計模式一樣，微服務模式也是一種經過驗證的解決方案，用于解決開發、部署和擴展微服務時遇到的常見問題。

舉例來說，SAGA模式解決了分布式事務失敗的問題，而API網關則簡化了客戶端代碼，并充當許多微服務的前端控制器和負載均衡器，提高了微服務的可維護性。

本文介紹一些常見的微服務設計模式，每個從事微服務開發或將單體應用程序拆分為微服務以分離代碼、數據和接口的開發人員都應該了解和學習。

1 服務注冊模式

服務注冊模式提供了一個中央存儲庫，用于按名稱發現微服務。它是一種微服務架構模式，使服務能夠發現其他微服務并相互通信。

在這種模式中，使用一個中央服務注冊表或目錄來記錄可用服務及其位置。微服務可以向注冊表注冊自己，其他微服務可以查找注冊表以找到所需服務的位置。

舉個例子，假設有一個大型電子商務網站，包含許多微服務，如訂單服務、支付服務、物流服務和客戶服務。每個服務都有自己的REST API，其他服務可以使用它來進行通信。

為了讓這些服務更容易相互發現，可以使用服務注冊模式。我們可以設置一個服務注冊表，例如Consul或Eureka（Spring Cloud提供此功能），它維護著所有可用服務及其終點的列表。

當一個服務啟動時，它可以通過提供自己的名稱和終點來向注冊表注冊自己。

例如，訂單服務可以將自己注冊為“order-service”，終點為“http://order-service:8080”。其他需要與訂單服務通信的服務可以通過在注冊表中查找其名稱來獲取其終點。

例如，支付服務可以在注冊表中查找“order-service”的終點，以向訂單服務發送支付信息。同樣，物流服務可以在注冊表中查找“order-service”的終點，以獲取訂單的物流信息。

這樣，每個服務可以獨立開發和部署，而不需要在其代碼中硬編碼其他服務的終點。服務注冊模式使得服務能夠動態地相互定位，使系統更具靈活性和適應變化的能力。

圖片

2 斷路器模式

顧名思義，斷路器模式通過斷開電路來防止級聯故障，并使應用程序在一個或多個服務失敗時繼續運行。用于處理微服務架構中可能發生的故障。

在這種模式中，斷路器充當客戶端和服務之間的安全網，保護客戶端免受服務故障的影響。斷路器監視服務的狀態，如果檢測到服務失敗，它可以打開斷路器，并阻止進一步的請求發送到服務，直到服務恢復正常。

舉個例子，假設一個微服務應用程序正在使用一個不可靠的外部服務，而且即使外部服務失敗，應用程序也需要繼續運行。

在這種情況下，可以使用斷路器模式來檢測外部服務是否不可用，并切換到備用服務或降級服務，直到外部服務再次可用。

圖片

在微服務架構中，可以使用Netflix的Hystrix或Spring Cloud Circuit Breaker等工具來實現斷路器模式，這些工具提供了一種管理斷路器行為的方式，允許應用程序以可控的方式對服務故障做出反應。

3 API網關模式

API網關模式是微服務架構中常用的設計模式之一，涉及到一個API網關，它充當所有傳入API請求的入口點。它為所有微服務提供了一個統一的入口點，并充當客戶端和微服務之間的代理，將請求路由到適當的服務。

API網關的主要目的是解耦客戶端和微服務，將系統的復雜性抽象到一個簡化和一致的API后面。這也意味著您不需要查找和記住100多個微服務REST API的地址。

它還提供了額外的安全性和治理層，允許組織控制和管理對其服務的訪問，監控系統的性能，并在所有服務中強制執行策略。

以下是一個簡單電子商務系統中API網關模式的工作示例：

假設一個電子商務系統有多個微服務來處理不同的功能，如訂單管理、產品目錄和用戶身份驗證。每個微服務都有自己的處理請求的API終點。然而，客戶端（可以是Web或移動應用程序）需要通過一個入口點訪問所有這些微服務。

這就是API網關發揮作用的地方。API網關充當反向代理，接收來自客戶端的所有傳入請求。然后，它根據請求的終點將每個請求路由到適當的微服務。

例如，API網關可能會將請求路由到/orders終點的訂單管理微服務，將請求路由到/products終點的產品目錄微服務。

圖片

API網關還可以執行其他功能，如請求和響應轉換、速率限制、身份驗證和授權以及緩存。

它還可以提供統一的API，隱藏微服務的內部細節，并向客戶端呈現更簡單和一致的接口。

總的來說，API網關模式提供了一種在復雜系統中管理微服務的可擴展、靈活和安全的方式，使得開發、部署和維護基于微服務的應用程序更加容易。

圖片

4 Saga模式

Saga模式提供了一種管理涉及多個微服務的事務的方式。它用于確保跨多個服務的一系列事務成功完成，如果失敗，則回滾或撤銷到目前為止所做的所有更改。

Saga模式由一系列本地事務組成，每個事務更新單個服務的狀態，以及一組相應的補償事務，用于在發生故障時撤銷原始事務的影響。

以下是在基于微服務的電子商務應用程序中使用Saga模式的示例：

假設您有兩個微服務，一個負責處理訂單，另一個負責發貨。

當下訂單時，訂單處理服務負責驗證訂單并確保貨物有庫存，而發貨服務負責將訂單打包并發送給客戶。

如果訂單處理服務確定訂單有效且所有商品有庫存，它會向發貨服務發送消息以啟動發貨流程。此時，Saga模式就會發揮作用。

發貨服務將創建一個新的事務來打包和發貨訂單，如果事務成功，它將標記訂單為已發貨。

另一方面，如果事務失敗（例如與發貨提供商的問題），發貨服務將啟動一個補償事務來撤銷原始事務的影響，例如取消發貨并重新補充庫存。

圖片

同時，訂單處理服務也使用Saga模式來管理自己的事務。如果發貨服務報告訂單已成功發貨，訂單處理服務將標記訂單為已完成。

如果發貨服務報告失敗，訂單處理服務將啟動一個補償事務來取消訂單并退還支付的款項。

總體而言，Saga模式提供了一種管理跨多個微服務的復雜事務的方式，以確保一致性和可靠性。如果您只想學習一種模式，最好學習Saga模式，因為它在微服務應用程序中非常有幫助。

5 事件溯源模式

事件溯源是一種用于在應用程序中持久化和查詢數據的微服務模式。它不存儲對象的當前狀態，而是持久化應用程序中發生的所有事件，從而可以在任意時間點重構對象的狀態。

在這種模式中，應用程序中的每個狀態變化都被捕獲為一個事件，并存儲為事件日志。通過回放這些事件，可以重新構建應用程序的狀態。這意味著事件溯源提供了應用程序中所有變更的審計日志。

例如，考慮一個電子商務應用程序。當用戶下訂單時，會生成并存儲一個OrderPlaced事件到日志中。當訂單發貨時，會生成并存儲一個ShipmentMade事件到日志中。

如果訂單被取消，則會生成并存儲一個OrderCanceled事件到日志中。通過回放這些事件，可以確定訂單的當前狀態。

事件溯源有幾個優點：

• 審計性：可以審計和追溯系統的所有更改，找到其來源。
• 可擴展性：可以并行處理事件，提供更好的可擴展性。
• 靈活性：因為事件是真實的數據源，可以在不改變數據本身的情況下更改數據的查詢和持久化方式。
• 容錯性：因為事件是不可變的，它們無法被修改，確保數據始終正確。

然而，實現事件溯源可能會很復雜，并且需要仔細的規劃。此外，查詢數據可能會較慢，因為涉及回放所有事件，所以在使用之前要確保真正需要。

6 命令查詢責任分離 (CQRS) 模式

命令查詢責任分離 (CQRS) 模式是另一種流行的微服務設計模式，將命令（寫操作）和查詢（讀操作）分別分離到不同的模型中，每個模型都有自己的數據庫。

該模式基于這樣一個思想：用于寫入數據的模型與用于讀取數據的模型不同。

在這種模式中，命令模型接收來自客戶端的命令并寫入數據庫。查詢模型從數據庫中讀取數據并將數據發送給客戶端。該模式可以用于提高系統的性能和可擴展性，因為每個模型可以針對其特定任務進行優化。

例如，考慮一個使用傳統的CRUD（創建、讀取、更新、刪除）方法來管理產品信息的電子商務應用程序。同一模型和數據庫被用于處理產品信息的讀取和寫入。隨著應用程序的增長，模型變得越來越復雜，數據庫成為性能瓶頸。

使用CQRS，應用程序將具有一個專門用于寫入產品信息的命令模型，以及一個專門用于讀取產品信息的查詢模型。命令模型針對快速寫入進行優化，而查詢模型針對快速讀取進行優化。

命令模型將數據存儲在一個針對寫入進行優化的數據庫中，而查詢模型將數據存儲在一個針對讀取進行優化的數據庫中。這兩個模型通過事件總線或消息隊列進行通信。

總體而言，CQRS可以提高系統的可擴展性和性能，并通過分離關注點簡化代碼庫。然而，它也可能增加復雜性，并需要更多的開發工作，因為需要使用獨立的模型和數據庫。

7 隔離模式

隔離設計模式是一種將系統的不同部分隔離開來的方式，以防止一個部分的故障影響到系統的其他部分。在微服務架構中，隔離模式可以用于隔離不同的微服務，以防止一個微服務的故障導致整個系統崩潰。

這個模式與斷路器模式有些相似，都是為了防止級聯故障，但是隔離模式更側重于隔離和自給自足的微服務，如下圖所示，Service A擁有自己的連接池，與Service B和Service C不共享。

8 面向前端的后端 (BFF) 模式

面向前端的后端 (BFF) 是一種在微服務架構中使用的設計模式，用于處理多個用戶界面下的客戶端-服務器通信的復雜性。它建議為每個前端界面創建一個單獨的后端服務，以處理該界面的特定需求。

這樣可以讓開發人員針對前端的特定需求優化數據流、緩存和身份驗證機制，同時保持后端服務的模塊化和解耦。

例如，假設您有一個需要訪問相同一組服務的Web應用程序和移動應用程序。在這種情況下，您可以為每個應用程序創建單獨的后端服務，每個服務針對特定平臺進行優化。

Web應用程序后端可以處理大量數據以實現更快的加載，而移動應用程序后端可以針對較低的延遲和網絡使用優化。

這種模式使團隊能夠通過為每個界面使用單獨的后端服務來優化用戶體驗。它還允許避免一個需要為多個不同需求的界面提供服務的單個后端服務，這可能變得越來越復雜和難以維護。

總結

本文雖然篇幅較長，但我們學習了一些關鍵的微服務設計模式。現在用一句話來總結每個模式，以便讀者能輕松記住并在適當的時候使用它們：

一句話總結流行的微服務設計模式：

• 服務注冊模式（Service Registry）：為服務提供中心位置，使其能夠注冊自身。
• 斷路器模式（Circuit Breaker）：允許服務快速失敗并防止級聯故障，該模式用于隔離出現故障的服務。
• API網關模式（API Gateway）：為系統中的所有請求和響應提供統一的入口點。因此，客戶端只需記住一個主機/端口地址，而不是每個微服務的多個IP地址。
• Saga 模式：用于管理跨多個服務的長事務的模式。
• 事件溯源模式（Event Sourcing Pattern）：是一種將應用程序狀態的變化表示為事件序列的設計模式。
• 命令查詢責任分離模式（Command Query Responsibility Segregation，CQRS）：將應用程序的讀取和寫入請求分離開來，以實現更好的擴展性和性能。
• 隔離模式（Bulkhead Pattern）：在微服務內部隔離故障，以防止單個故障導致整個系統崩潰。
• 面向前端的后端模式（Backends for Frontends，BFF）：為每個客戶端提供一個特定的后端。它允許前端團隊快速開發功能并添加特定于客戶端的功能。