微服務架構設計模式概述
作者：Grey
原文地址: 微服務架構設計模式概述
說明
本文內容是《微服務架構設計模式》這本書的學習筆記
單體應用轉換成微服務可以考慮的幾個維度
SOA和微服務的區別
| SOA | 微服務 | |
|---|---|---|
| 協議 | 重量級（SOAP,WS*) | REST或者RPC |
| 數據管理 | 共享數據庫 | 每個服務都有自己的數據模型和數據庫 |
| 典型服務規模 | 較大的單體 | 較小的服務 |
模式之間的基本關係和符號表示
前導(Predecessor)
前導模式是催生這個模式的需求的模式，例如，微服務架構模式是除單體架構模式以外整個模式語言中所有模式的前導模式。
後續（Successor)
後續模式是指用來解決當前模式引人的新問題的模式，例如，如果你採納了微服務架構模式，你需要一系列的後續模式來解決諸如服務發現、斷路器等微服務帶來的新問題。
替代(Alternative)
當前模式的替代模式，提供了另外的解決方案，例如，單體架構和微服務架構就是互為替代的模式，它們都是應用的架構風格。你可以選擇其一
泛化（Generalization)
針對一個問題的一般性解決方案。例如: 「每主機單個服務」這個模式存在多種不同的技術實現。
特化（Specialization）
針對特定模式的具體解決方案。例如: 將服務部署為容器模式是針對「每主機單個服務」的具體解決方案。
符號說明：
基於上述符號，我們可以用圖例來表示微服務架構中各個環節的相關模式
服務拆分的相關模式
-
按功能組織服務
-
根據子域分解服務（DDD）
示例圖
服務通信模式
通信風格
使用哪一類進程間通訊機制
服務發現
客戶端如何獲得服務具體實例（如HTTP請求）的IP地址
可靠性通信
在服務不可用的情況下，如何確保服務之間的可靠通訊
事務性消息
如何將消息發送，事件發佈這樣的動作與更新業務數據庫的數據庫事務集成
外部API
應用程序的客戶端如何與服務進行通信
實現事務管理的數據一致性相關模式
為了保證松耦合，每個服務必須擁有自己的數據庫，因此，需要使用Saga模式來確保數據一致性
在微服務架構中查詢數據的相關模式
有兩種：
-
API組合
微服務部署的相關模式
可觀測的相關模式
健康檢查API
可以返回服務健康狀態的APIO
日誌聚合
把服務產生的日誌寫人一個集中式的日誌服務器，這個服務器可以提供日誌搜索，也可以根據日誌情況觸發報警。
分佈式追蹤
為每一個外部請求分配一個唯一的ID，用於在各個服務之間追蹤外部請求。
異常跟蹤
把程序異常發送到異常跟蹤服務，這個服務會排除重複異常，給開發者發送告警並且跟蹤每一個異常的解決。
應用指標
供維護使用的指標，例如計數器等，導出到指標服務器。
審計日誌
記錄用戶的行為。
實現服務自動化測試的相關模式
消費端驅動的契約測試
驗證服務滿足客戶端所期望的功能
消費端契約測試
驗證服務的客戶端可以正常與服務通信
服務組件測試
在隔離的環境中測試服務。
解決基礎設施和邊界問題的相關模式
該模式在運行時向服務提供數據庫憑據等配置參數。在開發新服務時，從頭開始重新實現這些功能是在太費時間了。
安全相關的模式
在微服務架構中，用戶身份驗證的工作通常由API Gateway完成。然後，它必須將有關用戶的信息（例如身份和角色）傳遞給它調用的服務。常見的解決方案是應用訪問令牌模式。API Gateway將訪問令牌（例如JWT，即JSON web令牌）傳遞給服務，這些服務可以驗證令牌並獲取有關用戶的信息。
