0

我正在開發微服務,我使用CQRS模式的事件採購,在我的情況下,如果用戶從一項服務中刪除/更新,我希望它發佈一個事件和其他服務來訂閱它,並從其db中刪除關於該用戶的條目。如何在事件採購和CQRS中使用發佈/訂閱模式

我想問如何在事件採購中使用pub/sub模式,可以使用哪個Event存儲區,因爲目前我已經看到一些人使用Azure Tables,但是如何將它用作pub/sub?

+0

如果您的事件位於Azure Table存儲中,如何將事件投影到您的已讀模型中? –

+0

目前,我沒有使用任何活動商店。我也在尋找這樣一個解決方案,我可以將我的事件投影到讀取模型,這無法通過Azure表存儲完成。這就是爲什麼我要求可以自​​動執行此操作的Event Store –

+0

正如答案中所述,EventStore(http://www.geteventstore.com)支持訂閱,此功能是構建讀取模型的最佳方式。雖然預測不是pub-sub。後者是消息傳遞模式。 –

回答

2

可以使用哪個事件存儲...?

如果你有選擇使用該技術的奢侈品,那麼我會建議你尋找到格雷格 - 年輕的Event Store

對,就是那個引入CQRS世界同一個人開始了。

(您可能還想回顧他在polyglot data上的演講,其中包括討論基於拉和推的模型)。

0

我如何使用發佈/訂閱模式在事件採購

該用例自然放下對eventsourcing,如果準確地意識到這一點,然後通知有關的問題將自動消失。 通過公共巴士實現交互是最好的。每個實現您的聚合或投影的微服務都連接在統一的邏輯總線中,並在所有事件上簽名,並且還可以在那裏發送任何事件。

當然,如果系統處於沉重負載下,則有必要進行一些優化,例如爲事件輸入名稱空間並向總線的中介者指定什麼事件以及什麼微服務有必要交付。此外,如果某些信息對於微服務是私有的,那麼在公共汽車上建立專用信道是有意義的,然而它不是由事件採購理論提供的,與集合體之間的驗證完全相同。

還要感謝公共巴士的概念,您還會收到系統客戶(例如瀏覽器)的「作爲禮物」反應。但是,您不得僅爲事件訂閱聚合的預測或狀態。如果服務器事件與客戶端不相同,則可以在其廣播中輸入中間實體,但它不再是存儲事件的責任。