作者：Grey

原文地址: 微服務架構設計模式概述

說明

本文內容是《微服務架構設計模式》這本書的學習筆記

單體應用轉換成微服務可以考慮的幾個維度

SOA和微服務的區別

模式之間的基本關係和符號表示

前導(Predecessor)

前導模式是催生這個模式的需求的模式，例如，微服務架構模式是除單體架構模式以外整個模式語言中所有模式的前導模式。

後續（Successor)

後續模式是指用來解決當前模式引入的新問題的模式，例如，如果你採納了微服務架構模式，你需要一系列的後續模式來解決諸如服務發現、斷路器等微服務帶來的新問題。

替代(Alternative)

當前模式的替代模式，提供了另外的解決方案，例如，單體架構和微服務架構就是互為替代的模式，它們都是應用的架構風格。你可以選擇其一

泛化（Generalization)

針對一個問題的一般性解決方案。例如: “每主機單個服務”這個模式存在多種不同的技術實現。

特化（Specialization）

針對特定模式的具體解決方案。例如: 將服務部署為容器模式是針對“每主機單個服務”的具體解決方案。

符號說明：

基於上述符號，我們可以用圖例來表示微服務架構中各個環節的相關模式

服務拆分的相關模式

1. 按功能組織服務

2. 根據子域分解服務（DDD）

示例圖

服務通訊模式

通訊風格

使用哪一類程序間通訊機制

服務發現

客戶端如何獲得服務具體例項（如HTTP請求）的IP地址

可靠性通訊

在服務不可用的情況下，如何確保服務之間的可靠通訊

事務性訊息

如何將訊息傳送，事件釋出這樣的動作與更新業務資料庫的資料庫事務整合

外部API

應用程式的客戶端如何與服務進行通訊

實現事務管理的資料一致性相關模式

為了保證鬆耦合，每個服務必須擁有自己的資料庫，因此，需要使用Saga模式來確保資料一致性

在微服務架構中查詢資料的相關模式

有兩種：

1. API組合

2. CQRS(命令查詢職責隔離)

微服務部署的相關模式

可觀測的相關模式

健康檢查API

可以返回服務健康狀態的APIO

日誌聚合

把服務產生的日誌寫人一個集中式的日誌伺服器，這個伺服器可以提供日誌搜尋，也可以根據日誌情況觸發報警。

分散式追蹤

為每一個外部請求分配一個唯一的ID，用於在各個服務之間追蹤外部請求。

異常跟蹤

把程式異常傳送到異常跟蹤服務，這個服務會排除重複異常，給開發者傳送告警並且跟蹤每一個異常的解決。

應用指標

供維護使用的指標，例如計數器等，匯出到指標伺服器。

審計日誌

記錄使用者的行為。

實現服務自動化測試的相關模式

消費端驅動的契約測試

驗證服務滿足客戶端所期望的功能

消費端契約測試

驗證服務的客戶端可以正常與服務通訊

服務元件測試

在隔離的環境中測試服務。

解決基礎設施和邊界問題的相關模式

該模式在執行時向服務提供資料庫憑據等配置引數。在開發新服務時，從頭開始重新實現這些功能是在太費時間了。

安全相關的模式

在微服務架構中，使用者身份驗證的工作通常由API Gateway完成。然後，它必須將有關使用者的資訊（例如身份和角色）傳遞給它呼叫的服務。常見的解決方案是應用訪問令牌模式。API Gateway將訪問令牌（例如JWT，即JSON web令牌）傳遞給服務，這些服務可以驗證令牌並獲取有關使用者的資訊。