CQRS 和事件溯源指南答案

【问题标题】：CQRS and Event Sourcing GuideCQRS 和事件溯源指南
【发布时间】：2019-09-22 00:05:14
【问题描述】：

我想创建一个非常便宜、非常灵活且非常简单的 CQRS 和事件溯源架构。

我想确保事件永远不会失败，至少永远不会到达发布者/事件存储，因为那是业务所在。

现在，我有几个选择：

天蓝色

使用 azure，我似乎不知道该使用什么。

Azure 服务总线
Azure 函数
Azure webjob（我想这可以用 Azure 函数代替）
?? （还有什么我忘记或不知道的？）

这些天蓝色无服务器解决方案的可靠性如何？

自定义

为此，我正在考虑使用 RabbitMQ，问题是运行它的虚拟机成本。

总而言之，我想要：

能够在失败的情况下重播消息/事件。
能够轻松添加订阅者。
能够选择重播消息的订阅者。
事件存储应该能够存储非常大的事件消息（或者如何将图像或文件排队？？）。
事件存储永远不能被阻塞或休眠。
实施/原型设计的速度将增加优势。

您的经验有何启示？

其他选择呢？（例如：apache-kafka）？

【问题讨论】：

标签： azure apache-kafka rabbitmq cqrs event-sourcing

【解决方案1】：

为什么不运行 Event Store？由 Greg Young 本人创建。在您需要的地方托管。

【讨论】：

【解决方案2】：

我是一个 java 用户，我一直在使用 hornetq（也就是我不使用的 artemis）作为 rabbitmq 的替代品；唯一的问题是它不支持复制，但在事件采购方面可以完成工作。对于您的自定义场景，rabbitmq 是一个不错的选择，但请尝试在数字海洋实例上以低成本运行它。如果您正在寻找简单性和灵活性，那么您只有 2 个选择，构建您自己的或放弃简单性并选择 apache kafka 及其所有复杂性，但会给您带来灵活性。同样，您也可以使用 mongodb 构建事件存储。 https://www.mongodb.com/blog/post/event-sourcing-with-mongodb

【讨论】：

关于建立自己的活动商店：这是一个非常糟糕的建议。事件存储有足够复杂的要求，使构建自己的任务变得相当困难，而且很多人在第一次接触事件溯源时似乎并没有意识到这些，
另外（鉴于此 get 经常被建议），以防万一，不要使用 kafka 作为事件存储，因为它缺少写入时的并发检查，导致您可能最终得到错误的数据。跨度>
我听到了，但这确实取决于用例。您不需要为了进行次要事件溯源而选择整个框架。如果您正在大规模进行，我会真正理解朝这个方向发展的必要性，但对于次要事件溯源，请创建简单的事件溯源应用程序并在此期间使用它。
@SavvasKleanthous 还有一件事，看 Greg Youngs 的“8 行代码”和youtube.com/watch?v=9a1PqwFrMP0&ab_channel=NDCConferences。你总是可以建立自己的，没有标准的方法，只有一堆你需要理解的原则。
我非常了解 Greg 和 Mat 的谈话，我个人也认识他们两个。编写代码以从事件中恢复状态是与构建事件存储完全不同的问题类型。看看这里：github.com/ylorph/RandomThoughts/blob/master/…

【解决方案3】：

您的要求太模糊，无法做出最佳选择。您需要考虑很多事情，其中之一是，例如，每个聚合的事件数、聚合数（请注意，这必须是统计的）。这些很重要，主要是因为如果您为每个聚合允许数以万计的事件，那么您将需要进行快照，这会增加您可能不需要的复杂性。

但对于常规用例，您可以只使用 Postgres 之类的关系数据库作为（线性化）事件存储。它还具有侦听/通知功能，您实际上也不需要任何消息总线，并且您的应用程序可以以反应方式编写。

【讨论】：