與面向?qū)ο笤O(shè)計模式一樣，微服務(wù)模式也是一種經(jīng)過驗證的解決方案，用于解決開發(fā)、部署和擴展微服務(wù)時遇到的常見問題。

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

本文介紹一些常見的微服務(wù)設(shè)計模式，每個從事微服務(wù)開發(fā)或?qū)误w應(yīng)用程序拆分為微服務(wù)以分離代碼、數(shù)據(jù)和接口的開發(fā)人員都應(yīng)該了解和學(xué)習(xí)。

1 服務(wù)注冊模式

服務(wù)注冊模式提供了一個中央存儲庫，用于按名稱發(fā)現(xiàn)微服務(wù)。它是一種微服務(wù)架構(gòu)模式，使服務(wù)能夠發(fā)現(xiàn)其他微服務(wù)并相互通信。

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

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

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

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

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

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

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

圖片

2 斷路器模式

顧名思義，斷路器模式通過斷開電路來防止級聯(lián)故障，并使應(yīng)用程序在一個或多個服務(wù)失敗時繼續(xù)運行。用于處理微服務(wù)架構(gòu)中可能發(fā)生的故障。

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

舉個例子，假設(shè)一個微服務(wù)應(yīng)用程序正在使用一個不可靠的外部服務(wù)，而且即使外部服務(wù)失敗，應(yīng)用程序也需要繼續(xù)運行。

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

圖片

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

3 API網(wǎng)關(guān)模式

API網(wǎng)關(guān)模式是微服務(wù)架構(gòu)中常用的設(shè)計模式之一，涉及到一個API網(wǎng)關(guān)，它充當所有傳入API請求的入口點。它為所有微服務(wù)提供了一個統(tǒng)一的入口點，并充當客戶端和微服務(wù)之間的代理，將請求路由到適當?shù)姆?wù)。

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

它還提供了額外的安全性和治理層，允許組織控制和管理對其服務(wù)的訪問，監(jiān)控系統(tǒng)的性能，并在所有服務(wù)中強制執(zhí)行策略。

以下是一個簡單電子商務(wù)系統(tǒng)中API網(wǎng)關(guān)模式的工作示例：

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

這就是API網(wǎng)關(guān)發(fā)揮作用的地方。API網(wǎng)關(guān)充當反向代理，接收來自客戶端的所有傳入請求。然后，它根據(jù)請求的終點將每個請求路由到適當?shù)奈⒎?wù)。

例如，API網(wǎng)關(guān)可能會將請求路由到/orders終點的訂單管理微服務(wù)，將請求路由到/products終點的產(chǎn)品目錄微服務(wù)。

圖片

API網(wǎng)關(guān)還可以執(zhí)行其他功能，如請求和響應(yīng)轉(zhuǎn)換、速率限制、身份驗證和授權(quán)以及緩存。

它還可以提供統(tǒng)一的API，隱藏微服務(wù)的內(nèi)部細節(jié)，并向客戶端呈現(xiàn)更簡單和一致的接口。

總的來說，API網(wǎng)關(guān)模式提供了一種在復(fù)雜系統(tǒng)中管理微服務(wù)的可擴展、靈活和安全的方式，使得開發(fā)、部署和維護基于微服務(wù)的應(yīng)用程序更加容易。

圖片

4 Saga模式

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

Saga模式由一系列本地事務(wù)組成，每個事務(wù)更新單個服務(wù)的狀態(tài)，以及一組相應(yīng)的補償事務(wù)，用于在發(fā)生故障時撤銷原始事務(wù)的影響。

以下是在基于微服務(wù)的電子商務(wù)應(yīng)用程序中使用Saga模式的示例：

假設(shè)您有兩個微服務(wù)，一個負責(zé)處理訂單，另一個負責(zé)發(fā)貨。

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

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

發(fā)貨服務(wù)將創(chuàng)建一個新的事務(wù)來打包和發(fā)貨訂單，如果事務(wù)成功，它將標記訂單為已發(fā)貨。

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

圖片

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

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

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

5 事件溯源模式

事件溯源是一種用于在應(yīng)用程序中持久化和查詢數(shù)據(jù)的微服務(wù)模式。它不存儲對象的當前狀態(tài)，而是持久化應(yīng)用程序中發(fā)生的所有事件，從而可以在任意時間點重構(gòu)對象的狀態(tài)。

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

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

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

事件溯源有幾個優(yōu)點：

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

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

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

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

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

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

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

使用CQRS，應(yīng)用程序?qū)⒕哂幸粋€專門用于寫入產(chǎn)品信息的命令模型，以及一個專門用于讀取產(chǎn)品信息的查詢模型。命令模型針對快速寫入進行優(yōu)化，而查詢模型針對快速讀取進行優(yōu)化。

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

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

7 隔離模式

隔離設(shè)計模式是一種將系統(tǒng)的不同部分隔離開來的方式，以防止一個部分的故障影響到系統(tǒng)的其他部分。在微服務(wù)架構(gòu)中，隔離模式可以用于隔離不同的微服務(wù)，以防止一個微服務(wù)的故障導(dǎo)致整個系統(tǒng)崩潰。

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

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

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

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

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

Web應(yīng)用程序后端可以處理大量數(shù)據(jù)以實現(xiàn)更快的加載，而移動應(yīng)用程序后端可以針對較低的延遲和網(wǎng)絡(luò)使用優(yōu)化。

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

總結(jié)

本文雖然篇幅較長，但我們學(xué)習(xí)了一些關(guān)鍵的微服務(wù)設(shè)計模式?，F(xiàn)在用一句話來總結(jié)每個模式，以便讀者能輕松記住并在適當?shù)臅r候使用它們：

一句話總結(jié)流行的微服務(wù)設(shè)計模式：

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