微服務架構最重要的設計模式有哪些

這篇文章主要介紹“微服務架構最重要的設計模式有哪些”，在日常操作中，相信很多人在微服務架構最重要的設計模式有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”微服務架構最重要的設計模式有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

微服務架構

在之前的博客文章中，我已經詳細介紹了微服務體系結構：微服務體系結構：簡要概述以及為什么要在下一個項目中使用它以及模塊化單片軟件體系結構真的死了嗎?如果您有興趣，可以閱讀它們以更深入地了解它們。

什么是微服務架構。微服務架構有很多定義。這是我的定義：

微服務架構旨在將大型，復雜的系統垂直(按功能或業務要求)劃分為較小的子系統，這些子系統屬于流程(因此可獨立部署)，并且這些子系統之間通過與語言無關的輕量級網絡通信相互通信(例如REST，gRPC)或異步(通過消息傳遞)方式。

這是具有微服務架構的業務Web應用程序的組件視圖：

> Microservice Architecture by Md Kamaruzzaman

微服務架構的重要特征：

• 整個應用程序分為多個單獨的進程，每個進程可以包含多個內部模塊。

• 與模塊化Monoliths或SOA相反，微服務應用程序是垂直拆分的(根據業務能力或領域)

• 微服務邊界是外部的。結果，微服務通過網絡調用(RPC或消息)相互通信。

• 由于微服務是獨立的流程，因此它們可以獨立部署。

• 他們以輕巧的方式交流，不需要任何智能交流渠道。

微服務架構的優勢：

• 更好的開發規模。

• 更高的發展速度。

• 支持迭代或增量現代化。

• 充分利用現代軟件開發生態系統(云，容器，DevOps，無服務器)的優勢。

• 支持水平縮放和粒度縮放。

• 由于尺寸較小，它降低了開發人員的認知復雜度。

微服務架構的缺點：

• 大量的活動部件(服務，數據庫，流程，容器，框架)。

• 復雜性從代碼轉移到基礎架構。

• RPC調用和網絡流量的激增。

• 管理整個系統的安全性具有挑戰性。

• 設計整個系統比較困難。

• 介紹分布式系統的復雜性。

何時使用微服務架構：

• Web規模應用程序開發。

• 當多個團隊處理應用程序時，進行企業應用程序開發。

• 長期收益優先于短期收益。

• 該團隊擁有能夠設計微服務架構的軟件架構師或高級工程師。

微服務架構的設計模式

每個微服務獨占數據庫

一旦公司用許多較小的微服務替換了大型的單片系統，它面臨的最重要的決定就是關于數據庫。在整體架構中，使用大型中央數據庫。許多架構師都喜歡保留數據庫原樣，即使他們轉向微服務架構也是如此。盡管它提供了一些短期好處，但它是一種反模式，尤其是在大規模系統中，因為微服務將緊密耦合在數據庫層中。轉向微服務的整個目標將失敗(例如，團隊授權，獨立開發)。

更好的方法是為每個微服務都提供自己的數據存儲，以使數據庫層中的服務之間不存在強耦合。在這里，我使用數據庫一詞來表示數據的邏輯分離，即微服務可以共享同一物理數據庫，但是它們應該使用單獨的架構/集合/表。它還將確保根據域驅動設計正確隔離微服務。

> Database per Microservice by Md Kamaruzzaman

優點：

• 數據對服務的完全所有權。

• 開發服務的團隊之間的松耦合。

缺點：

• 在服務之間共享數據變得充滿挑戰。

• 提供應用程序范圍的ACID事務保證變得更加困難。

• 將Monolith數據庫分解為較小的零件需要仔細設計，這是一項艱巨的任務。

每個微服務何時使用數據庫：

• 在大型企業中的應用。

• 當團隊需要其微服務的完全所有權以進行開發擴展和提高開發速度時。

什么時候不使用每個微服務的數據庫：

• 在小型應用中。

• 如果一個團隊開發所有微服務。

啟用技術示例：

• 所有SQL和NoSQL數據庫都提供邏輯上的數據分離(例如，分離的表，集合，模式，數據庫)。

事件源 Event Sourcing

在微服務架構中，尤其是在每個微服務使用數據庫的情況下，微服務需要交換數據。對于有彈性，高度可擴展和容錯的系統，它們應通過交換事件進行異步通信。在這種情況下，您可能需要進行原子操作，例如，更新數據庫并發送消息。如果您有SQL數據庫，并且希望為大量數據分配分布式事務，則不能使用兩階段鎖定(2PL)，因為它無法擴展。如果您使用NoSQL數據庫并希望具有分布式事務，則不能使用2PL，因為許多NoSQL數據庫不支持兩階段鎖定。

在這種情況下，請結合使用基于事件的體系結構和事件源。在傳統數據庫中，具有當前"狀態"的業務實體被直接存儲。在事件源中，將存儲任何狀態更改事件或其他重要事件，而不是實體。這意味著業務實體的修改將保存為一系列不可變的事件。通過在給定時間重新處理該業務實體的所有事件，可以扣除該業務實體的狀態。因為數據存儲為一系列事件，而不是通過直接更新數據存儲來存儲，所以各種服務可以從事件存儲中重播事件以計算其各自數據存儲的適當狀態。

> Event Sourcing by Md Kamaruzzaman

優點：

• 為高度可擴展的系統提供原子性。

• 實體的自動歷史記錄，包括時間旅行功能。

• 松散耦合和事件驅動的微服務。

缺點：

• 從事件存儲中讀取實體變得具有挑戰性，通常需要額外的數據存儲(CQRS模式)

• 系統的整體復雜性增加，通常需要域驅動設計。

• 系統需要處理重復事件(冪等)或丟失事件。

• 遷移事件模式變得具有挑戰性。

何時使用事件來源：

• 具有SQL數據庫的高度可擴展的事務系統。

• 帶有NoSQL數據庫的事務系統。

• 高度可擴展且具有彈性的微服務架構。

• 典型的消息驅動或事件驅動系統(電子商務，預訂和預訂系統)。

何時不使用事件來源：

• 具有SQL數據庫的低伸縮性事務系統。

• 在簡單的微服務架構中，微服務可以同步交換數據(例如，通過API)。

啟用技術示例：

• 事件存儲：EventStoreDB，Apache Kafka，Confluent Cloud，AWS  Kinesis，Azure事件中心，GCP發布/訂閱，Azure Cosmos DB，MongoDB，Cassandra。Amazon  DynamoDB，

• 框架：Lagom，Akka，Spring，akkatecture，Axon，Eventuate

命令查詢職責隔離(CQRS)

如果我們使用事件源，那么從事件存儲中讀取數據將變得充滿挑戰。要從數據存儲中獲取實體，我們需要處理所有實體事件。另外，有時我們對讀寫操作有不同的一致性和吞吐量要求。

在這種用例中，我們可以使用CQRS模式。在CQRS模式中，系統的數據修改部分(命令)與數據讀取(查詢)部分分開。CQRS模式有兩種形式：簡單和高級，這導致軟件工程師之間產生一些混淆。

以簡單的形式，不同的實體或ORM模型用于讀取和寫入，如下所示：

> CQRS (simple) by Md Kamaruzzaman

它有助于實施"單一責任原則"和"關注點分離"，從而使設計更簡潔。

在其高級形式中，不同的數據存儲區用于讀取和寫入操作。高級CQRS與事件來源一起使用。根據使用情況，使用不同類型的寫入數據存儲和讀取數據存儲。寫入數據存儲區是"記錄系統"，即整個系統的黃金來源。

> CQRS (advanced) by Md Kamaruzzaman

對于重讀應用程序或微服務體系結構，將OLTP數據庫(任何提供ACID事務保證的SQL或NoSQL數據庫)或分布式消息平臺用作寫存儲。對于繁重的寫程序(高寫可伸縮性和吞吐量)，使用了水平可寫伸縮的數據庫(公共云全局數據庫)。規范化的數據保存在寫入數據存儲中。

為搜索(例如Apache  Solr，Elasticsearch)或讀取(鍵值數據存儲，文檔數據存儲)而優化的NoSQL數據庫用作讀取存儲。在許多情況下，在需要SQL查詢的地方使用可伸縮的SQL數據庫。歸一化和優化的數據將保存在讀取存儲中。

數據從寫入存儲異步復制到讀取存儲。結果，讀存儲區滯后于寫存儲區，并且最終保持一致。

優點：

• 在事件驅動的微服務中更快地讀取數據。

• 數據的高可用性。

• 讀寫系統可以獨立擴展。

缺點：

• 讀取數據存儲弱一致性(最終一致性)

• 系統的整體復雜性增加。貨運培訓CQRS可能會嚴重危害整個項目。

何時使用CQRS：

• 在使用事件源的高度可擴展的微服務體系結構中。

• 在讀取數據需要查詢到多個數據存儲區的復雜域模型中。

• 在讀寫操作具有不同負載的系統中。

何時不使用CQRS：

• 在微事件數量微不足道的微服務體系結構中，使用事件存儲快照來計算實體狀態是更好的選擇。

• 在讀寫操作具有相似負載的系統中。

啟用技術示例：

• 寫存儲：EventStoreDB，Apache Kafka，Confluent Cloud，AWS Kinesis，Azure Event  Hub，GCP發布/訂閱，Azure Cosmos DB，MongoDB，Cassandra。亞馬遜DynamoDB

• 閱讀商店：Elastic Search，Solr，Cloud Spanner，Amazon Aurora，Azure Cosmos  DB，Neo4j

• 框架：Lagom，Akka，Spring，akkatecture，Axon，Eventuate

SAGA

如果您將微服務體系結構與每個微服務的數據庫一起使用，那么通過分布式事務管理一致性就具有挑戰性。您不能使用傳統的兩階段提交協議，因為它無法擴展(SQL數據庫)或不被支持(許多NoSQL數據庫)。

您可以將Saga模式用于Microservice  Architecture中的分布式事務。Saga是一種舊模式，于1987年開發，作為SQL數據庫中長期運行的數據庫事務的概念替代方案。但是，這種模式的現代變體對于分布式事務也非常有效。Saga模式是一個本地事務序列，其中每個事務在單個微服務中更新數據存儲中的數據并發布事件或消息。傳奇中的第一個事務由外部請求(事件或操作)啟動。一旦本地事務完成(數據存儲在數據存儲中，并且發布消息或事件)，發布的消息/事件將觸發Saga中的下一個本地事務。

> Saga by Md Kamaruzzaman

如果本地事務失敗，則Saga執行一系列補償事務，以撤消先前本地事務的更改。

Saga交易協調主要有兩種變體：

• 分散的協調，每個微服務生成并收聽其他微服務的事件/消息，并決定是否應該采取措施。

• 統籌協調，協調器告訴協調的微服務哪些本地事務需要執行。

優點：

• 通過高度可擴展的或松散耦合的，事件驅動的微服務架構中的事務來提供一致性。

• 通過使用沒有2PC支持的NoSQL數據庫的微服務體系結構中的事務來提供一致性。

缺點：

• 需要處理短暫故障，并應提供冪等性。

• 難以調試，并且隨著微服務數量的增加，復雜性也隨之增加。

何時使用佐賀：

• 在使用事件源的高度可擴展的，松散耦合的微服務架構中。

• 在使用分布式NoSQL數據庫的系統中。

什么時候不使用佐賀：

• 具有SQL數據庫的低伸縮性事務系統。

• 在服務之間存在循環依賴性的系統中。

啟用技術示例：

• Axon，Eventuate，Narayana

前端的后端(BFF)

在現代業務應用程序開發中，尤其是在微服務體系結構中，前端和后端應用程序是分離的和獨立的服務。它們通過API或GraphQL連接。如果應用程序還具有Mobile  App客戶端，則對Web和Mobile客戶端使用相同的后端微服務將成為問題。移動客戶端的API要求通常與Web客戶端不同，因為它們具有不同的屏幕大小，顯示，性能，能源和網絡帶寬。

后端的后端模式可用于每個UI都有為特定UI定制的單獨后端的場景。它還提供了其他優勢，例如充當下游微服務的外觀，從而減少了UI與下游微服務之間的閑聊通信。同樣，在高度安全的情況下，下游微服務部署在DMZ網絡中，BFF用于提供更高的安全性。

> Backends for Frontends by Md Kamaruzzaman

優點：

• BFF之間的關注點分離。我們可以針對特定的UI優化它們。

• 提供更高的安全性。

• 減少UI與下游微服務之間的交流。

缺點：

• BFF之間的代碼重復。

• 如果使用其他許多UI(例如，智能電視，Web，移動設備，臺式機)，BFF的數量也會激增。

• BFF不應包含任何業務邏輯，而應僅包含特定于客戶的邏輯和行為，因此需要仔細設計和實施。

何時將后端用于前端：

• 如果應用程序具有多個具有不同API要求的UI。

• 如果出于安全原因在UI和下游微服務之間需要額外的一層。

• 如果在UI開發中使用微前端。

何時不使用后端作為前端：

• 如果應用程序具有多個UI，但是它們使用相同的API。

• 如果未在DMZ中部署核心微服務。

啟用技術示例：

• 任何后端框架(Node.js，Spring，Django，Laravel，Flask，Play等)都支持它。

API網關

在微服務架構中，UI通常與多個微服務連接。如果微服務是細粒度的(FaaS)，則客戶端可能需要連接許多微服務，這變得很繁瑣且具有挑戰性。而且，服務(包括其API)可以發展。大型企業還希望擁有其他跨領域的問題(SSL終止，身份驗證，授權，限制，日志記錄等)。

解決這些問題的一種可能方法是使用API網關。API網關位于客戶端APP和后端微服務之間，并充當外觀。它可以用作反向代理，將客戶端請求路由到適當的后端微服務。它還可以支持將客戶端請求的扇出擴展到多個微服務，然后將匯總的響應返回給客戶端。它還支持基本的跨領域關注。

> API Gateway by Md Kamaruzzaman

優點：

• 提供前端和后端微服務之間的松散耦合。

• 減少客戶端和微服務之間的往返呼叫次數。

• 通過SSL終止，身份驗證和授權實現高安全性。

• 集中管理的跨領域問題，例如日志記錄和監視，節流，負載平衡。

缺點：

• 可能導致微服務架構中的單點故障。

• 由于額外的網絡呼叫，延遲增加了。

• 如果不進行擴展，它們很容易成為整個企業的瓶頸。

• 額外的維護和開發成本。

何時使用API網關：

• 在復雜的微服務架構中，這幾乎是強制性的。

• 在大型公司中，必須使用API網關來集中安全性和跨領域問題。

何時不使用API網關：

• 在安全性和中央管理不是最高優先級的私人項目或小型公司中。

• 如果微服務的數量很小。

啟用技術示例：

• Amazon API Gateway，Azure API管理，Apigee，Kong，WSO2 API管理器

扼殺者

如果要在棕地項目中使用微服務架構，則需要將舊版或現有的Monolithic應用程序遷移到微服務。將現有的大型生產單片式應用程序遷移到微服務中具有很大的挑戰性，因為這可能會破壞應用程序的可用性。

一種解決方案是使用Strangler模式。Strangler模式意味著通過逐步用新的微服務替換特定功能，將Monolithic應用程序逐步遷移到微服務架構。此外，新功能僅在微服務中添加，繞過了傳統的Monolithic應用程序。然后將Facade(API網關)配置為在舊版Monolith和微服務之間路由請求。一旦功能從Monolith遷移到微服務，Facade就會攔截客戶端請求并路由到新的微服務。一旦所有舊版Monolithic功能都已遷移，舊版Monolithic應用程序將被"勒死"，即退役。

> Strangler by Md Kamaruzzaman

優點：

• 將Monolithic應用程序安全遷移到微服務。

• 遷移和新功能開發可以并行進行。

• 遷移過程可以有自己的進度。

缺點：

• 在現有的Monolith和新的微服務之間共享數據存儲變得充滿挑戰。

• 添加外觀(API網關)將增加系統延遲。

• 端到端測試變得困難。

何時使用Strangler：

• 將大型后端單片應用程序增量遷移到微服務。

何時不使用Strangler：

• 如果后端整體組件較小，則批量替換是一個更好的選擇。

• 如果客戶端對舊版Monolithic應用程序的請求無法被攔截。

推動技術：

• 帶有API網關的后端應用程序框架。

斷路器

在微服務體系結構中，微服務進行同步通信，微服務通常調用其他服務來滿足業務需求。由于瞬態故障(網絡連接速度慢，超時或時間不可用)，對另一個服務的調用可能會失敗。在這種情況下，重試呼叫可以解決此問題。但是，如果存在嚴重問題(微服務完全失敗)，則微服務將長時間不可用。在這種情況下，重試是沒有意義的，并且浪費了寶貴的資源(線程被阻塞，浪費了CPU周期)。同樣，一項服務的故障可能會導致整個應用程序級聯故障。在這種情況下，立即失敗是一種更好的方法。

對于此類用例，可以使用斷路器模式。微服務應通過代理來請求另一個微服務，該代理的工作方式類似于斷路器。代理應該計算最近發生的故障數，并使用它來決定是允許操作繼續進行還是直接返回異常。

> Circuit Breaker by Md Kamaruzzaman

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

• 已關閉：斷路器將請求發送到微服務，并計算給定時間段內的故障數。如果在一定時間內的故障數量超過閾值，則它將跳閘并進入"打開狀態"。

• 打開：來自微服務的請求立即失敗，并返回異常。超時后，斷路器進入半開狀態。

• 半開放式：僅允許來自微服務的有限數量的請求通過并調用該操作。如果這些請求成功，則斷路器將進入閉合狀態。如果任何請求失敗，則斷路器進入"打開"狀態。

優點：

• 提高微服務架構的容錯性和彈性。

• 停止將故障級聯到其他微服務。

缺點：

• 需要復雜的異常處理。

• 記錄和監視。

• 應該支持手動重置。

何時使用斷路器：

• 在緊密耦合的微服務體系結構中，微服務進行同步通信。

• 一個微服務是否依賴于多個其他微服務。

何時不使用斷路器：

• 松散耦合的，事件驅動的微服務架構。

• 微服務是否不依賴于其他微服務。

推動技術：

• API網關，服務網格，各種斷路器庫(Hystrix，Reselience4J，Polly。

外部化配置

每個業務應用程序都有許多用于各種基礎結構的配置參數(例如，數據庫，網絡，連接的服務地址，憑據，證書路徑)。同樣，在企業環境中，應用程序通常部署在各種運行時中(本地，開發，生產)。實現此目標的一種方法是通過內部配置，這是一種致命的不良做法。由于很容易破壞生產憑據，因此可能導致嚴重的安全風險。另外，配置參數的任何更改都需要重建應用程序。在微服務架構中，這一點尤為重要，因為我們可能擁有數百種服務。

更好的方法是外部化所有配置。結果，將構建過程與運行時環境分開。此外，由于生產配置文件僅在運行時或通過環境變量使用，因此將安全風險降到最低。

優點：

• 生產配置不是代碼庫的一部分，因此可以最大程度地減少安全漏洞。

• 無需重新構建即可更改配置參數。

缺點：

• 我們需要選擇一個支持外部化配置的框架。

何時使用外部化配置：

• 任何重要的生產應用程序都必須使用外部配置。

何時不使用外部化配置：

• 在概念發展的證明。

推動技術：幾乎所有企業級的現代框架都支持外部化配置。

消費者驅動的合同測試

在微服務架構中，通常由獨立的團隊開發許多微服務。這些微服務一起工作來滿足業務需求(例如，客戶請求)，并且彼此同步或異步地通信。消費者微服務的集成測試具有挑戰性。通常，在這種情況下使用TestDouble可以進行更快，更便宜的測試。但是TestDouble通常并不代表真正的提供程序微服務。另外，如果提供者微服務更改了其API或消息，則TestDouble無法確認這一點。另一個選擇是進行端到端測試。雖然在生產之前必須進行端到端測試，但它脆弱，緩慢，昂貴，并且不能替代集成測試(測試金字塔)。

消費者驅動的合同測試可以在這方面為我們提供幫助。此處，消費者微服務所有者團隊編寫了一個測試套件，其中包含針對特定提供者微服務的請求和預期響應(用于同步通信)或預期消息(用于異步通信)。這些測試套件稱為顯式合同。對于提供商微服務，其使用者的所有合同測試套件都添加到了自動測試中。在執行針對特定提供程序微服務的自動測試時，它將運行自己的測試，合同并驗證合同。通過這種方式，合同測試可以幫助以自動化的方式維護微服務通信的完整性。

優點：

• 如果提供者意外更改了API或消息，則會在很短的時間內自動找到它。

• 更少的驚喜和更高的健壯性，尤其是包含大量微服務的企業應用程序。

• 改善團隊自主權。

缺點：

• 由于合同測試可能使用完全不同的測試工具，因此需要進行額外的工作才能在合同商微服務中開發和集成合同測試。

• 如果合同測試與實際服務消耗不匹配，則可能導致生產失敗。

何時使用消費者驅動的合同測試：

• 在大型企業業務應用程序中，通常，不同的團隊開發不同的服務。

何時不使用消費者主導的合同測試：

• 一個團隊開發所有微服務的相對簡單，較小的應用程序。

• 提供者微服務是否相對穩定且未處于積極開發中。

推動技術：

• 契約，郵遞員，Spring Cloud合同

到此，關于“微服務架構最重要的設計模式有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！