在微服務架構中實現查詢

在微服務架構中實現查詢操作有兩種不同的模式：
1：API組合模式

	這是最簡單的方法，應儘可能使用。它的工作原理是通過定義一個API組合器（API Composer）實現查詢，該API組合器會調用擁有數據的服務，並組合服務返回的查詢結果

什麼是API組合模式：

• API組合器

  它通過查詢數據提供方的服務來實現查詢操作

• 數據提供方服務

  擁有查詢返回的部分數據的服務

• 模式：API組合
  通過查詢每個服務的API並組合結果，實現從多個服務檢索數據的查詢。
  是否可以使用此模式實現特定查詢操作取決幾個因素，包括數據的分區方式、擁有數據的服務公開的API功能，以及服務使用數據庫的功能，等等。

• API組合模式的設計缺陷：
  使用此模式時，必須解決兩個設計問題：

  1. 確定架構中的哪個組件是查詢操作的API組合器
     由誰來擔任API組合器角色
     這是必須做出的一個決定，選擇由誰來扮演查詢操作的API組合器角色。有以下三種方式：
     1：由客戶端擔任API組合器
     2：由實現應用程序外部的API的API Gateway來扮演API組合器的角色，用來完成查詢操作和查詢結果的組合。
     3：將API組合器實現爲獨立的服務
  2. 如何編寫有效的聚合邏輯
     API組合模式的弊端：
     1. 增加了額外的開銷
        明顯的缺點就是涉及多個請求和多個數據庫連接
     2. 帶來可用性降低的風險
        操作的可用性隨着所涉及的服務數量而下降
     3. 缺乏事務數據一致性

• 命令查詢職責隔離(CQRS)模式
  它比API組合模式更強大，但也更復雜。它維護一個或多個視圖數據庫(可以是NoSql也可以是關係型數據庫)，其唯一目的是支持查詢。
  爲什麼要使用CQRS
  API組合模式是實現需要從多個服務檢索數據查詢的好辦法。但是，它只是解決微服務架構中查詢問題的不完整解決方案。因爲針對一些涉及多個服務的查詢，API組合無法有效地實現。
  更重要的是，實現一些特定的服務查詢很有挑戰性。也許服務的數據庫不能有效地支持查詢。或者，有時必須實現檢索不同服務所擁有的數據的查詢。例如，Mysql對搜索支持的很差，性能低。
  在微服務架構中使用API組合模式經常會遇到三個問題：

1. 檢索分散在多個服務中的數據會導致昂貴、低效的內存中連接
2. 擁有數據的服務將數據存儲在不能有效支持所需查詢的數據庫中
3. 隔離問題意味着，擁有數據的服務不一定會實現查詢操作的服務

什麼是CQRS

• CQRS是命令查詢職責隔離的簡稱，它涉及隔離或問題的隔離，它將持久化數據模型和使用數據的模塊分爲兩部分：命令端和查詢端。命令端模塊和數據模型實現了創建、更新和刪除操作。查詢端模塊和數據模型實現查詢。查詢端通過訂閱命令端發佈的事件，使其數據模型與命令端數據模型保持同步。

• 獨立的查詢模型可以用來處理複雜的查詢場景。查詢端的代碼往往比命令端簡單很多，因爲它不需要負責實現具體的業務邏輯。查詢端使用的數據庫種類也很靈活，可以是NoSql，也可以是Mysql等數據庫。查詢端的事件處理程序會訂閱領域事件並更新數據庫。

• CQRS和查詢專用服務
  CQRS不僅可以在服務中應用，還可以使用此模式來定義查詢服務。查詢服務的API只包含查詢操作，並無命令操作。它通過訂閱由一個或多個其他服務發佈的事件來確保它的數據是不斷更新的，並由此實現查詢操作。
  在許多方面，CQRS也代表了當前流行的基於事件的數據庫應用場景，例如，它可以使用關係型數據庫作爲記錄系統，使用Elasticsearch來處理文本查詢。不同之處在於CQRS使用更廣泛的數據庫類型，而不僅僅是一種。此外，通過訂閱事件，近乎實時更新CQRS查詢端的數據庫。

• CQRS的好處：
  1：在微服務架構中高效地實現查詢

   CQRS模式的一個好處是它有效地實現了檢索多個服務所擁有的數據查詢
  

  2：高效地實現多種不同的查詢類型

   CQRS的另一個好處是它使應用程序或服務能夠高效地實現各種查詢。嘗試使用單個持久數據模型支持所有查詢通常具有挑戰性，並且在某些情況下是不可能
  

  3：在基於事件溯源技術的應用程序中實現查詢

   CQRS還剋制了事件溯源的主要限制。事件存儲庫僅支持基於主鍵的查詢。CQRS模式訂閱由基於事件溯源的聚合發佈的事件流，可以保持最新的聚合的一個或多個視圖，由此解決此限制
  

  4：更進一步地實現問題隔離

   CQRS的另一個好處是它會隔離問題。領域模型及其相應的持久化數據模型不必同時處理命令和查詢。CQRS爲服務的命令端和查詢端定義了單獨的代碼模塊和數據庫模式。
  

• CQRS的弊端
  1：更加複雜的架構

   CQRS的一個缺點是它使複雜性增加了。開發人員必須編寫更新和查詢視圖的查詢端服務。管理和運維額外的數據存儲庫提高了運維的複雜性。此外，應用程序可能使用不同類型的數據庫，這進一步增加了開發人員和運維人員面臨的複雜性
  

  2：處理數據複製導致的延遲

   CQRS的另一個缺點是處理命令端和查詢端視圖之間的“滯後”。
  

• 設計CQRS視圖
  CQRS視圖模塊包括由一個或多個查詢操作組成的API。它通過訂閱由一個或多個服務發佈的事件來更新它的數據庫視圖，從而實現這些查詢操作
  在開發視圖模塊時，必須做以下重要的設計決策：

  1. 必須選擇合適的數據庫，並設計數據庫結構
  2. 在設計數據訪問模塊時，必須解決各種問題，包括確保更新是冪等的，並且能夠處理併發更新
  3. 在現有應用程序中實現新視圖或更改現有應用程序的模式時，必須實現一種機制，以便有效地構建或重建視圖
  4. 必須決定如何設計視圖的客戶端，以應對前面描述的複製延遲