如何在事件溯源和 CQRS 中使用发布/订阅模式答案

【问题标题】：How to use pub/sub pattern in Event Sourcing & CQRS如何在事件溯源和 CQRS 中使用发布/订阅模式
【发布时间】：2017-11-19 04:15:47
【问题描述】：

我正在开发微服务，我正在使用带有 CQRS 模式的事件溯源，在我的情况下，如果用户从一项服务中删除/更新，我希望它发布事件和其他服务来订阅它并删除条目也从其数据库中关于该用户。

我想问一下如何在 Event Sourcing 中使用 pub/sub 模式，可以使用哪个事件存储，因为目前我看到一些人使用 Azure Tables，但是如何将它用作 pub/sub？

【问题讨论】：

如果您的事件在 Azure 表存储中，您如何将事件投影到您的读取模型？
目前，我没有使用任何 Event Store。我也在寻找这样的解决方案，我可以将我的事件投影到读取模型，这无法通过 Azure 表存储来完成。这就是为什么我要求一个可以自动执行此操作的事件存储
如答案中所述，EventStore (geteventstore.com) 支持订阅，此功能是构建读取模型的最佳方式。虽然预测不是 pub-sub。后者是消息传递模式。

【解决方案1】：

可以使用哪个事件存储...？

如果您有幸选择要使用的技术，那么我建议您先查看 Greg Young 的 Event Store

是的，就是这个人将 CQRS 介绍给了世界。

（您可能还想查看他在 polyglot data 上的演讲，其中包括基于拉取与推送的模型的讨论）。

【讨论】：

【解决方案2】：

如何在事件溯源中使用发布/订阅模式

这个用例自然是基于事件溯源，如果能准确地实现它，那么关于通知的问题就会自行消失。最好是通过公共总线来实现交互。实现聚合或预测的每个微服务都连接在统一的逻辑总线上，并对所有事件进行签名，也可以在那里发送任何事件。

当然，当系统负载较重时，需要做一些优化，例如，为事件输入名称空间，以及向总线的代理指定什么事件以及它给什么微服务有必要交付。另外，如果某些信息对于微服务来说是私有的，那么在总线中建立私有通道是有意义的，但是它不是由事件源理论提供的，与聚合之间的验证完全相同。

另外，由于公共总线的概念，您还可以收到系统客户端（例如浏览器）的“礼物”响应性。但是，您不能订阅聚合的预测或状态，只能订阅事件。如果服务器事件不等于客户端，您可以在他们的广播中输入中间实体，但它不再负责事件的存储。

【讨论】：