微服務的模式語言

轉自：A pattern language for microservices

[譯註]：模式語言提供了討論問題的交流術語，它明確了特定場景、特定問題的解決方案和延伸性思考。模式語言主要目的是幫助開發者解決在設計和編程中遇到的共同的問題，即清晰的問題陳述、體現問題的解決方案以及推動解決方案的力量（Force）的清晰表述。微服務架構作為一個現在流行的服務架構，也有一套屬於自己的模式。這篇文章是微服務架構相關模式語言的一個提綱。Chris Richardson 從不同的角度，對相關的模式進行了分類。可以點擊鏈接查看每個模式的詳細描述。下圖通過虛線框細分了不同的微服務模式。

核心模式（Core patterns）

您為應用程序選擇哪一種架構？

• 單體架構（Monolithic architecture） - 採用單一部署單元的方式架構應用
• 微服務架構（Microservices architecture） - 採用一組松耦合服務的方式架構應用

服務拆分（Decomposition）

如何把應用拆分為若干個服務？

• 根據業務能力拆分（Decompose by business capability）new - 根據業務能力界定服務的範圍
• 根據領域的子域拆分（Decompose by subdomain）new - 根據領域驅動設計中子域的概念界定服務的範圍

部署模式（Deployment patterns）

如何部署應用程序的服務？

• 單主機上部署服務的多個實例（Multiple service instances per host） - 把服務的多個實例部署在一台主機上
• 單主機上部署服務的單個實例（Single service instance per host） - 把服務的單一實例部署在它獨享的主機上
• 服務實例與虛擬機一一對應（Service instance per VM） - 把服務的單一實例部署在它獨享的虛擬機上
• 服務實例與容器一一對應（Service instance per Container） - 把服務的單一實例部署在它獨享的容器上
• 無伺服器部署（Serverless deployment） - 使用無伺服器部署平台部署服務實例
• 服務部署平台（Service deployment platform）new - 使用提供服務抽象能力的高度自動化部署平台部署服務實例

需要關注的邊界問題（Cross cutting concerns）

如何處理服務實例與外界交互的問題？

• 微服務的基底（Microservice chassis） - 一個用於服務實例與外界交互和簡化服務開發的框架
• 配置信息外部化（Externalized configuration）new - 把類似資料庫連接、訪問密鑰等配置信息外部化

通訊模式（Communication patterns）

風格

應該選擇怎樣的通信機制來進行服務間通訊和外部客戶端通訊？

• 遠程過程調用（Remote Procedure Invocation） - 使用基於 RPI 協議的服務間通訊方式
• 消息（Messaging） - 使用非同步消息進行服務間通訊
• 領域獨用協議（Domain-specific protocol）new - 使用特定領域的通訊協議（如 SIP，等）

外部 API

如何處理外部客戶端與服務之間的通訊？

• API 網關（API gateway） - 為每一類客戶端提供一個訪問服務的獨特介面
• 服務前端的後端（Backend for front-end） - 為每一類客戶端都提供一個獨立的 API 網關

服務發現

一個基於 RPI 的客戶端如何在網路上發現服務實例的位置？

• 客戶端服務發現（Client-side discovery） - 客戶端通過直接查詢服務註冊表獲取服務實例的位置
• 伺服器端服務發現（Server-side discovery） - 路由模塊通過查詢服務註冊表獲取服務實例的位置
• 服務註冊表（Service registry） - 一個記錄了服務實例位置的數據
• 自註冊（Self registration） - 服務實例自己完成向服務註冊表的註冊
• 第三方註冊（3rd party registration） - 通過第三方模塊來進行服務實例信息到服務註冊表的註冊過程

可靠性

如何避免由於服務故障或網路中斷所引起的故障蔓延到其他服務？

• 斷路器（Circuit Breaker） - 當遠端服務返回的故障率超過一定的閥值時，客戶端代理（比如 API 網關）對遠程服務的調用將立刻返回失敗的信息

數據管理（Data management）

如何實現數據一致性和查詢？

• 每服務資料庫（Database per Service） - 每個服務都擁有它私有的資料庫
• 共享資料庫（Shared database） - 服務之間共享同一個資料庫
• 事件驅動架構（Event-driven architecture） - 使用事件來維護服務間的數據一致性
• 事件溯源（Event sourcing） - 以一連串事件的方式來持久化聚合
• 事務日誌跟蹤（Transaction log tailing） - 跟蹤資料庫的日誌變更並由此對外發布消息
• 資料庫觸發器（Database triggers） - 使用觸發器來捕獲對數據的修改
• 應用程序事件（Application events） - 應用程序從消息隊列獲取事件並插入資料庫中
• 命令查詢職責分離（CQRS） - 維護一個或者多個重要的數據視圖以供高效率的查詢

安全（Security）

如何向服務實例傳遞訪問客戶端的身份信息？

• 訪問令牌（Access Token）new - 服務實例通過訪問令牌來安全地傳遞客戶端的身份信息

測試（Testing）

如何更便捷的測試？

• 服務組件測試（Service Component Test）new - a test suite that tests a service in isolation using test doubles for any services that it invokes
• 服務集成協議測試（Service Integration Contract Test）new - a test suite for a service that is written by the developers of another service that consumes it

可觀測性（Observability）

如何掌握一個運行中微服務應用的行為並進行有效的故障排錯？

• 應用日誌（Log aggregation）new - 聚合應用程序產生的日誌文件
• 應用指標（Application metrics）new - 在代碼中實現收集應用運營過程中各類指標的功能
• 審計日誌（Audit logging）new - 把用戶行為記錄在資料庫中供日後核查
• 分散式追蹤（Distributed tracing）new - 在服務代碼中針對每一個外部訪問，都分配一個唯一的標識符，並在跨服務訪問時傳遞這個標識符以供追蹤分散式引發的問題。例如，當通過一個集中式服務處理外部請求時，記錄請求本身的信息以及請求的開始和結束時間。
• 異常追蹤（Exception tracking）new - 把所有服務程序代碼觸發的異常信息都匯聚到集中的異常追蹤服務，並根據一定的邏輯對開發者或運維人員發出通知。
• 健康檢查 API（Health check API）new - 一個監控服務可調用的 API，通常返回服務健康度信息，或對 ping 等心跳檢查請求做出響應。

UI 模式（UI patterns）

如何將源自多個服務的信息組織在一起生成 UI 界面或 Web 頁面？

• 伺服器端頁面碎片化元素構建（Server-side page fragment composition）new - 在伺服器端通過編排由多個業務或領域相關後端服務生成的 HTML 片段來構建前端輸出的頁面內容
• 客戶端 UI 構建（Client-side UI composition）new - 在客戶端通過編排由多個業務或領域相關 UI 組件生成的 HTML 片段來構建前端輸出的頁面內容

推薦閱讀：