微服務架構：必懂的 5 種設計模式

1. Database per Service (每個服務一個數據庫)

• 目標 / 目的

• 實現微服務之間的松耦合。

• 增強服務的獨立性、可伸縮性和數據封裝。

• 關鍵概念 / 工作方式

• 每個微服務管理自己的私有數據庫。

• 數據庫只能由擁有該服務的服務訪問。

• 強制執行清晰的邊界並促進單一職責原則。

• 數據隔離

  減少服務之間的依賴。

• 技術靈活性

  服務可以使用適合其特定需求的不同數據庫技術 (例如 MongoDB, DynamoDB, Azure Cosmos DB, Google Cloud Data Store)。

• 獨立伸縮

  數據庫可以根據每個服務的要求獨立伸縮。

• 簡化開發

  開發者可以專注於單個服務及其數據模型。

• 數據訪問僅通過服務的 API 進行，維護了強大的封裝性。

• 挑戰 / 常見錯誤

• 數據重複

  可能導致一致性問題。

• 複雜的跨服務查詢

  可能需要 API 組合等額外模式。

• 事務管理

  在沒有分佈式事務的情況下，跨服務確保數據一致性具有挑戰性。

• 操作複雜性增加

  管理多個數據庫比管理單個共享數據庫更具挑戰性。

• 過度使用

  不必要地應用於小型服務或緊密耦合的領域會增加複雜性。

• 忽略數據遷移

  在拆分單體數據庫時未能規劃數據遷移會產生問題。

• 忽略最終一致性

  未設計系統來處理服務之間的最終一致性。

• 應用示例

• 在將單體電子商務平臺 adapting 爲微服務架構後應用此模式。

• 每個服務擁有特定表，例如產品服務擁有產品和分類表，庫存服務擁有庫存和位置表等。

• 通過將數據庫模式拆分爲更小的、由每個服務獨立管理的專用數據庫來實現。

• 前提條件

• 對業務流程和數據有紮實的理解。

• 定義清晰的微服務邊界。

• 實施數據治理計劃。

2. API Gateway (API 網關)

• 目標 / 目的

• 作爲客戶端請求的單一入口點。

• 通過提供統一接口簡化客戶端代碼。

• 處理跨領域關注點，如認證、日誌記錄和速率限制。

• 聚合

  來自多個微服務的響應。

• 提供協議轉換和 API 版本控制。

• 關鍵概念 / 工作方式

• 充當反向代理，攔截所有來自客戶端的傳入 API 調用。

• 將請求路由到適當的微服務。

• 聚合響應

  並返回給客戶端。

• 可以執行額外功能，如認證和授權、請求和響應轉換、緩存、監控和分析、速率限制和節流。

• 挑戰 / 常見錯誤

• 性能瓶頸

  如果設計不當，可能成爲單點故障和性能瓶頸。

• 過度複雜

  添加過多業務邏輯會使其難以維護和伸縮。

• 缺乏版本控制

  未實現適當的 API 版本控制會導致客戶端出現破壞性變更。

• 監控不足

  未實現全面的監控和告警會使問題排查困難。

• 安全配置錯誤

  錯誤實現認證和授權會導致安全漏洞。

• 緊密耦合

  與底層微服務設計得過於緊密會降低靈活性。

• 應用示例

• 應用於電子商務解決方案。

• 攔截來自客戶端的傳入 API 調用，路由請求，並在聚合響應前處理認證、密鑰管理和 HTTP / 協議轉換。

• 實現選項

• AWS API Gateway。

• Azure API Management。

• Google Cloud Endpoints 和 Apigee Edge。

3. Event Driven Architecture (EDA - 事件驅動架構)

• 目標 / 目的

• 實現松耦合、可伸縮和響應迅速的系統，能夠實時響應變化。

• 通過允許組件異步通信改進系統靈活性、可伸縮性和容錯性。

• 關鍵概念 / 工作方式

• 基於產生、檢測、消費和響應事件的思想。

• 事件表示系統中的重要狀態變化或發生。

• 事件生產者

  在發生重要事件時生成事件。

• 事件通過事件通道或消息代理傳輸。

• 事件消費者

  訂閱相關事件並做出相應反應。

• 促進解耦系統，組件無需瞭解彼此的存在。

• 挑戰 / 常見錯誤

• 管理和版本化事件模式會變得複雜。

• 通常依賴最終一致性，這在需要即時一致性的用例中可能具有挑戰性。

• 確保事件的正確順序，尤其是在分佈式系統中。

• 過度使用事件

  : 並非所有交互都需要是事件驅動的，不必要地增加複雜性。

• 未建立標準事件格式，導致集成困難。

• 忽略持久化重要事件，可能導致關鍵數據丟失和系統不一致。

• 未實現適當的錯誤處理。

• 未考慮在分佈式系統中調試問題的能力。

• 應用示例

• 應用於電子商務解決方案，將服務與消息代理連接。

• 例如，用戶下單時，購物車服務發送通知給消息代理，產品服務訂閱此通知並響應，然後購物車服務確認數量並創建訂單。

• 實現選項

• AWS: Amazon EventBridge, Amazon Simple Notification Service (SNS), Simple Queue Service (SQS)。

• Google Cloud: Cloud Pub/Sub, Cloud Functions。

• Azure: Azure Event Grid, Azure Service Bus, Azure Functions。

4. Service Registry and Discovery (服務註冊與發現)

• 目標 / 目的

• 解決在分佈式系統中動態定位和通信服務的問題。

• 維護可用服務實例的最新目錄。

• 實現自動化服務註冊。

• 促進動態伸縮和負載均衡。

• 提高系統彈性和容錯性。

• 關鍵概念 / 工作方式

• 包含兩個主要組件:

• Service Registry (服務註冊中心)

  一個存儲可用服務實例信息 (包括網絡位置) 的數據庫。

• Service Discovery (服務發現)

  : 服務查找其他服務以進行交互的機制。

• 服務註冊

• 自注冊 (Self-registration)

  每個微服務在啓動時註冊自己，關閉時註銷。

• 第三方註冊 (Third-party)

  註冊器 (registar) 負責監控微服務的健康狀況，並根據其健康狀態註冊或註銷。

• 服務發現

• 客戶端發現 (Client-side Discovery)

  每個微服務查詢服務註冊中心以檢索其他服務所需的信息。

• 服務器端發現 (Server-side Discovery)

  依賴於代理來協助微服務之間的交互，代理負責路由請求。

• 挑戰 / 常見錯誤

• 確保註冊中心始終最新，限制臨時不一致，避免將流量導向不可用實例。

• 考慮可能的性能開銷: 頻繁查詢註冊中心可能影響性能，應實施緩存機制。

• 註冊中心本身可能成爲瓶頸和單點故障: 必須爲註冊中心實現高可用性和容錯性。

• 安全

  未能保護服務註冊中心會暴露關於基礎設施的敏感信息。

• 忽視健康檢查

  未在每個微服務中實現健壯的健康檢查會導致流量被路由到不健康實例。

• 未能實現適當的負載均衡策略，導致流量分佈不均。

• 應用示例

• 在電子商務解決方案中應用。

• API Gateway 知道如何發送登錄請求到 Identity and Access Management (IAM) 微服務，就是因爲它利用了服務註冊與發現。

• 使用第三方方法：微服務啓動時，註冊器檢測它們並更新註冊中心。

5. Circuit Breaker (熔斷器)

• 目標 / 目的

• 防止分佈式系統中的級聯故障。

• 提高系統彈性和容錯性。

• 減少服務故障對整個系統的影響。

• 實現快速故障檢測和恢復。

• 關鍵概念 / 工作方式

• 像電氣斷路器一樣工作，監控服務之間的請求流。

• 具有三種狀態:

• Closed (關閉)

  正常運行狀態，請求通過。

• Open (打開)

  檢測到故障時，請求立即被拒絕。

• Half Open (半打開)

  測試服務是否已從先前的故障中恢復。

• 當服務重複失敗時，熔斷器會跳閘到 Open 狀態，阻止進一步的請求。

• 經過定義的超時後，切換到 Half Open 狀態以測試服務是否已恢復。

• 如果測試成功，則切換回 Closed；如果失敗，則返回 Open 狀態。

• 挑戰 / 常見錯誤

• 設置故障閾值過低或過高，可能導致過早跳閘或延遲響應故障。

• 未能設置適當的超時。

• 缺乏監控

  未實現適當的監控和告警會使問題難以發現。

• 忽略部分故障

  只關注完全服務故障而忽略性能下降的情況。

• 過度依賴熔斷器

  不應將其作爲唯一的容錯解決方案，應是綜合彈性策略的一部分。

• 未能充分測試熔斷器行爲。

• 應用示例

• 應用於電子商務解決方案，特別是保護產品服務不被庫存服務調用失敗影響。

• 描述了庫存服務調用產品服務失敗，熔斷器跳閘，經過指數退避和抖動隨機化重試，最終產品服務恢復，熔斷器切換回 Closed 的場景。

• 實施時的關鍵問題

• 何時應該跳閘？

• 在一定時期內，需要考慮多少次失敗請求來做決定？

• 如何量化失敗？

• 在將請求視爲失敗之前，產品服務的預期響應時間或 SLA 是多少？

• 熔斷器何時可以再次關閉？

• 熔斷器跳閘後多久應該再次嘗試？

• 應該給產品服務多長時間恢復？

• 這個模式理念簡單，但需要仔細思考如何防止完全系統故障。

下面是 5 種模式結合後的示例圖 

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