我們真的需要微服務中的事件采購和CQRS嗎？

Question

根據我的理解，當數據庫事務跨越微服務時，我們可以通過發布事件使用message-broker（kafka，RabbitMQ等）來解決這個問題，以便Subscriber Microservices可以通過監聽這些事件來更新他們的數據庫。

如果發生異常，我們可以發送失敗事件，以便訂閱服務可以更新其狀態。

這還不夠嗎？ 這種方法有什么問題？

為什么以及何時需要采購活動？

我們需要真正的事件采購嗎？

Answer 1

一點也不。 您可以擁有一個非常明確的微服務式架構，而無需CQRS和事件源。 CQRS和Event Sourcing是微服務內設計的解決方案。 您可以選擇使用CQRS和事件采購來實施全部或部分微服務。

讓我們看看Event Sourcing如何幫助您。 Event Sourcing是使用事件而不是像Entity Framework或Hibernate和SQL數據庫這樣的ORM來恢復實體當前狀態的替代方法。 假設您有一個微服務來存儲有關Books的數據。 如果使用SQL，則可以使用控制器和端點來創建，更新和刪除書籍，並將這些書籍存儲在SQL表中。 如果要更新該書，那么為了獲得當前狀態，您將返回到SQL表並查詢該書（通過其id），然后您的ORM將該表表示轉換為書籍對象（對象關系）阻抗不匹配問題）然后您將應用更改並將更改的書對象保存回SQL表。 作為替代方案，您可以將書籍對象的事件存儲在NoSQL數據庫（如MongoDB）或事件存儲庫中。 現在，為了更新本書，首先您需要恢復當前狀態，並且可以通過返回與本書相關的所有事件並重播這些事件來恢復當前狀態來實現。 您的事件成為事實的來源，您完全避免了ORM映射和SQL連接的瓶頸。 事件存儲為JSON文檔，通常超快。

現在，來到CQRS - CQRS純粹是一種分離關注點的模式。 您可以使用CQRS從寫入端分叉您的讀取端。 與寫入端相關的端點（如創建，更新和刪除）存在於一個服務中，端點用於讀取端存在於另一個服務中。 您在這里獲得的優勢是獨立擴展，部署，維護等等。 如果您的應用程序是讀取密集型的，則會為讀取端服務部署多個實例。

如果您想了解更多信息，請隨時與我聯系。 祝好運！

Answer 2

我認為你對微服務的東西感到困惑:)它們是設計可擴展應用程序的解決方案，與數據庫事務無關。 更重要的是，db事務（理想情況下）不應跨越進程，從不關注微服務。

pub-sub方法是不同的微服務（也適用於過程模型）進行通信的方式。 與db事務無關。 事件采購就是將域狀態視為相關變更的集合。 與微服務相比，目標非常不同。

我們正在使用ES，因為我們喜歡將域事件存儲為“單一事實來源”，微服務與否。 這都是關於域模型設計的。

了解有關ES，DDD，CQRS的更多信息，並為將來留下微服務。 它們現在太過流行，很少有應用程序需要它們，很少有開發人員能夠正確地使用它們。

Answer 3

您正在描述補償模式作為分布式事務的替代。 在面向微服務的體系結構中，這是一種通過利用最終一致性來關注可用性的好方法：每個服務不是在服務之間進行集中協調的分布式事務，而是在沒有事務上下文的情況下執行其子任務。 如果出現問題，將向每個服務通知失敗並對先前的操作執行某種（語義）補償。 因此，交易操作最終被撤消。

正如您已經說過的，可以通過消息總線系統進行通信，並且不需要事件源或CQRS，補償模式不依賴於這些原則。