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

• 在微服務架構中查詢資料的挑戰
• 何時以及如何使用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。