模式語言提供了讨論問題的交流術語，它明确了特定場景、特定問題的解決方案和延伸性思考。模式語言主要目的是幫助開發者解決在設計和編程中遇到的共同的問題，即清晰的問題陳述、體現問題的解決方案以及推動解決方案的力量（Force）的清晰表述。

微服務架構作為一個現在流行的服務架構，也有一套屬于自己的模式。這篇文章是微服務架構相關模式語言的一個提綱。Chris Richardson 從不同的角度，對相關的模式進行了分類。可以點擊鍊接查看每個模式的詳細描述。下圖通過虛線框細分了不同的微服務模式。

微服務模式

核心模式（Application architecture patterns）

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

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

服務拆分（Decomposition）

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

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

部署模式（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） - 使用提供服務抽象能力的高度自動化部署平台部署服務實例

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

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

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

通信模式（Communication patterns）

風格

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

• 遠程過程調用（Remote Procedure Invocation）- 使用基于 RPI 協議的服務間通訊方式
• 消息（Messaging）- 使用異步消息進行服務間通訊
• 領域獨用協議（Domain-specific protocol） - 使用特定領域的通訊協議（如 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）

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

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

安全（Security）

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

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

測試（Testing）

如何更便捷的測試？

• 服務組件測試（Service Component Test） - 一個測試套件，它使用它調用的任何服務的測試替身來單獨測試服務
• 服務集成協議測試（Service Integration Contract Test - 由使用它的另一個服務的開發人員編寫的服務的測試套件

可觀測性（Observability）

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

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

UI 模式（UI patterns）

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

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

關注我

本站所有文章和資源僅為個人工作和學習中的記錄，部分觀點有一定主觀性，若有不妥，歡迎斧正。

歡迎指出網站中有問題的地方，我會盡快修正，謝謝！歡迎轉載謝謝！

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部