本篇主要總結第七章：在微服務架構中實現查詢

• 在微服務架構中查詢數據的挑戰
• 何時以及如何使用API組合模式實現查詢
• 何時以及如何使用CQRS模式實現查詢

微服務架構中，查詢通常需要檢索分散在多個服務所擁有的數據庫中的數據，跨服務數據查詢的兩種模式：

• API組合模式
  • 簡單，應盡可能使用
• CQRS：命令查詢職責隔離模式
  • 強大但復雜
  • 維護一個或多個視圖數據庫

API組合模式

API組合模式：由API組合器和兩個或多個服務提供方組成，API組合器通過查詢每個服務的API并組合結果，實現從多個服務檢索數據的查詢。

• API組合器：調用數據提供方API并組合查詢結果
• 數據提供方服務

API組合模式需要解決的兩個設計問題：

• 由誰來擔任API組合器的角色
  • 客戶端
  • API Gateway
  • API組合器獨立為服務
• 如何編寫有效的聚合邏輯
  • 盡可能并行查詢，使用響應式編程模型

API組合模式的好處和弊端

• 好處
  • 簡單
• 弊端
  • 增加了額外的開銷
    • 將一個查詢變成了N個查詢
  • 帶來可用性降低的風險
    • 依賴于每個服務提供方都可用，總體可用性是各服務提供方可用性的乘積。
    • 需要專門的策略來提高可用性
      • 緩存數據
      • 返回不完整數據
  • 缺乏事務數據一致性
    • 查詢操作可能返回不一致的數據

CQRS模式（命令查詢職責隔離）

CQRS模式：使用事件來維護從多個服務復制數據的只讀視圖，借此實現對來自多個服務的數據的查詢。它將持久化數據模型和使用數據的模塊分為命令端和查詢端，他們擁有各自的獨立數據庫。

• 命令端
  • 增、刪和改操作CUD
  • 不需要join，僅基于主鍵的查詢操作
  • 發布領域事件
• 查詢端
  • 查詢操作R
  • 數據庫視圖
  • 訂閱并處理領域事件并更新數據庫

CQRS模式的好處和弊端

• 好處
  • 在微服務架構中高效地實現查詢
  • 高效地實現多種不同的查詢類型
  • 在基于事件溯源技術的應用程序中實現查詢
  • 更進一步地實現問題隔離
• 弊端
  • 更加復雜的架構
  • 處理數據復制導致的延遲
    • 在命令端發布事件和在查詢端處理事件并更新視圖之間存在延遲。
      • 命令端和查詢端API提供數據的版本信息，使其能夠判斷查詢端是否過時，查詢API調用端可以輪詢查詢直到獲得最新版本的數據。

設計CQRS視圖

CQRS視圖模型包括視圖數據庫和三個子模塊：

• 查詢API
• 事件處理程序
• 數據訪問模塊
• 視圖數據庫

設計CQRS視圖需要考慮：

• 選擇視圖數據庫
• 設計數據庫訪問模塊
  • 并發處理：樂觀鎖
  • 冪等事件處理程序
• 添加和更新CQRS視圖
• 使用歸檔事件構建CQRS視圖
  • 增量式構建CQRS視圖
    • 快照+后續事件

學習總結

本章主要講跨服務查詢的問題。主要是兩個解決方案：

第一，使用一個API查詢組合器，分別調用各個服務提供的API查詢數據，再將結果組合起來。第二，使用CQRS，設計單獨的命令端和查詢端，命令端通過事件通知查詢端更新數據視圖，需要跨服查詢時直接查數據視圖。

在項目的初期或者在比較簡單查詢的情況下，可以多使用API查詢組合器。在項目后期或者對于一些較復雜的查詢，需要使用CQRS。

總結

以上是生活随笔為你收集整理的微服务的好处与弊端_《微服务架构设计模式》-学习总结07的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。