CQRS和事件来源指南

Question

我想创建一个 CQRS和事件源架构，该架构非常便宜，非常灵活并且非常简单。

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

现在，我想到了几个选择：

天蓝色

天蓝色，我似乎不知道该用什么。

1. 天蓝色服务巴士
2. 天蓝色函数
3. Azure Webjob（我想可以用Azure函数代替）
4. ?? （我忘了或不知道的东西？）

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

自定义

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

---

总而言之，我想要：

1. 能够在失败的情况下重播消息/事件。
2. 轻松添加订户的能力。
3. 能够选择在其上重播消息的订户。
4. 事件存储应该能够存储非常大的事件消息（或者其他如何将图像或文件排队？）。
5. 事件存储区绝不能cho塞或入睡。
6. 实现/原型制作的速度将会增加 优势。

---

您的经验表明什么？

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

Answer 1

为什么不运行事件存储？由格雷格·杨本人创建。在您需要的地方托管。

Answer 2

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

Answer 3

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

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