高可用性、可擴展性、故障恢復能力和性能是微服務的特徵。您可以使用微服務架構模式來構建微服務應用程序，從而降低微服務失敗的風險。

模式分爲三層：

應用模式

應用程序模式解決了開發人員面臨的問題，例如數據分解、數據維護、測試、用戶界面和一些可觀察性模式。

讓我們回顧一下這些應用程序模式的基礎知識。

分解模式

選擇如何將單體系統分解爲服務

• 按業務能力分解——服務是圍繞業務能力組織的。

• 按子域分解——服務是圍繞域驅動設計的子域組織的。

數據模式

• 數據一致性——每個服務使用一個單獨的數據庫以確保鬆散耦合。爲了跨服務的數據一致性，必須使用 Saga 模式。

• 查詢——每個服務使用數據庫的另一個問題是某些查詢需要連接來自多個服務的數據。不可能對服務的數據庫執行分佈式查詢，因爲它的數據只能通過其 API 訪問。必須使用其中一種查詢模式來檢索分散在多個服務中的數據。

• API 組合——對一項或多項服務進行 API 調用並彙總結果。

• 命令查詢職責分離 (CQRS) — 數據保存在一個或多個可以輕鬆查詢的副本中。

測試模式

單個微服務更容易測試，因爲它們比單體應用程序小得多。在測試不同服務是否協同工作時，重要的是要避免使用同時檢查多個服務的複雜、緩慢和不穩定的端到端測試。

• 消費者驅動的合同測試——確保服務滿足客戶的期望。

• 消費者端合約測試——確保服務的客戶端可以與之通信。

• 服務組件測試——隔離服務並對其進行測試。

用戶界面模式

顯示與不同服務相對應的數據及其顯示方式是不同團隊的責任。

• 服務器端頁面片段組合——每個團隊開發一個 Web 應用程序，爲他們的服務實現的頁面區域生成 HTML 片段。UI 團隊通過在服務器端聚合特定於服務的 HTML 片段來開發頁面模板。

• 客戶端 UI 組合——每個團隊創建一個客戶端 UI 組件，爲他們的服務實現屏幕區域，例如 AngularJS 指令。通過組合多個特定於服務的 UI 組件，UI 團隊實現頁面骨架來構建屏幕。

可觀察性模式

爲了有效地運行應用程序，瞭解其運行時行爲並解決請求失敗等問題非常重要。

• 審計日誌——審計日誌記錄每個用戶的操作。審計活動日誌通常用於協助客戶支持、確保合規性和檢測可疑活動。

• 應用程序指標——監控和警報是生產環境的關鍵組成部分。有一系列指標，例如 CPU、內存和磁盤的利用率，到服務請求的延遲和執行的請求數。指標由提供警報和可視化的指標服務收集。

應用基礎架構模式

它們適用於也會影響開發的基礎設施問題，例如通信、可觀察性、可靠性和安全模式。

橫切關注點模式

我們必須先了解關注點，才能理解橫切關注點。關注點是基於其功能的系統的一部分。有兩種擔憂：

• 核心關注點——它代表主要需求的單一和特定功能，例如業務邏輯。

• 橫切關注點——與次要需求相關的關注點。橫切關注點是適用於整個應用程序的關注點，例如安全性和日誌記錄。

• 外部化配置——在運行時，它向服務提供配置屬性值，例如數據庫憑據和網絡位置。

• 微服務底盤——微服務底盤是處理一系列問題的一個或一組框架，例如外部化配置、健康檢查、應用程序指標、服務發現、斷路器和分佈式跟蹤。您可以使用微服務機箱更有效地開發服務的業務邏輯。

• 服務模板——開發人員可以通過複製源代碼模板快速開始開發新服務。顧名思義，模板是一個簡單的可運行服務，它實現了構建邏輯和橫切關注點以及示例應用程序邏輯。

通訊模式

基於微服務的應用程序是分佈式系統。微服務架構嚴重依賴進程間通信（IPC）。

• 遠程過程調用 (RPI) — 使用請求 / 回覆協議發出服務請求。

• 特定於域的協議 - 對於服務間通信，例如使用 SMTP/IMAP 的電子郵件，或使用 RTMP/HLS/HDS 的媒體流，請使用特定於域的協議。

• 消息傳遞——使用異步消息傳遞進行服務間通信，例如 AMQP

可觀察性模式

可觀察性模式提供了對應用程序行爲方式的洞察。診斷微服務架構的問題要困難得多。在最終將響應返回給客戶端之前，請求可以在多個服務之間反彈。

• 日誌聚合——將服務活動日誌寫入可以執行搜索和警報的集中式日誌服務器。

• 異常跟蹤——應將異常報告給異常跟蹤服務，該服務對異常進行重複數據刪除、警告開發人員並跟蹤其解決方案。

• 健康檢查 API — 提供一個返回服務健康狀況的端點。

• 分佈式跟蹤——爲每個外部請求提供一個 ID，並在請求在服務之間流動時對其進行跟蹤。

可靠性模式

當服務不可用時，如何保證它們之間的可靠通信？

• 斷路器——斷路器可用於保護跨服務調用。當一定數量的下游資源請求未能達到一定閾值時，斷路器會打開。如果斷路器打開，系統將很快出現故障。一段時間後，客戶端會發送一些請求來檢查下游服務是否已經恢復。如果有正常響應，將在健康恢復後再次發送請求。

安全模式

用戶通常由微服務架構中的 API 網關進行身份驗證。然後必須將用戶的身份和角色傳遞給它調用的服務。一個常見的解決方案是使用訪問令牌模式。API 網關將訪問令牌（例如 JWT（JSON Web 令牌））傳遞給服務，服務可以驗證令牌並獲取有關用戶的信息。

基礎架構模式

它們解決了與開發之外的基礎設施有關的問題，例如部署、發現和與外部 API 的通信模式。

部署模式

部署微服務有幾種模式。傳統上，服務以特定語言的方式打包。有兩種現代部署方法。

• 虛擬機或容器——虛擬機或容器可用於部署服務。

• 無服務器部署——無服務器平臺在您上傳服務代碼後執行它。自動化的自助服務平臺是部署和管理服務的最佳方式。

發現模式

通常，服務需要相互通信。單體應用程序使用語言級方法或過程調用來調用其服務。傳統上，分佈式系統在固定的、衆所周知的位置（主機和端口）運行，因此可以通過 HTTP/REST 或其他一些機制訪問服務。然而，大多數基於微服務的現代應用程序都在虛擬化或容器化環境中運行，其中服務實例的數量及其位置會動態變化。

• 自注冊——服務向服務註冊中心註冊自己

• 客戶端發現——服務客戶端從服務註冊表中檢索服務實例，然後在它們之間進行負載平衡。

• 3rd Party Registration — 第三方自動向服務註冊中心註冊服務實例。

• 服務器端發現——服務發現由路由器完成，路由器接收來自客戶端的請求。

外部 API 模式

微服務提供的 API 粒度通常與客戶端所需的不同。微服務提供的 API 通常是細粒度的，因此客戶端必須與多個服務交互。每個客戶端需要不同數量的數據，網絡性能對每個客戶端的影響也不同。

• API Gateway — API Gateway 實現了一項服務，該服務是從外部 API 客戶端進入基於微服務的應用程序的入口點。它執行請求路由、API 組合和其他功能，例如身份驗證、速率限制、緩存等。

• 前端的後端 (BFF)——爲每種類型的客戶端創建一個單獨的 API 網關。每個移動、瀏覽器和公共 API 團隊都將擁有自己的網關，而 API 網關團隊擁有公共層。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/erNCS6w3L5GMKh4Ari9AQg