CQRS 和事件溯源 - 阅读您自己的事件

Question

目前，我正在实现事件驱动架构，并有一个命令服务（写入部分）和另一个查询服务（读取部分）。

我现在在做什么。

1. 在 CommandService 上接受命令
2. 在事件总线上存储事件和发布事件
3. ReadService 监听这些事件并更新读取模型

如果您听自己的事件，这听起来不错。 假设我从 CommandService 监听外部事件

1. 收听活动
2. 为此事件处理命令
3. 将您的域生成的事件存储在您的事件存储中并将此事件发布到事件总线
4. ReadService 监听这些事件并更新读取模型

在这种方法中，我可以看到更新我的读取模型存在双倍延迟。 第一个延迟 -> CommandService 时间拉事件 第二个延迟 -> ReadService 时间来拉取从 CommandService 生成的事件。

我在想如果我更新我的 ReadService 以在不需要事件总线的情况下直接侦听 CommandService 事件存储，那么我可以减少其中一个延迟。

你怎么看？

Answer 1

我们前段时间做过类似的事情。基本上，我们已经

1. 实现流程管理器模式的服务，并使用 EventSourcing 和 Saga 在多个服务之间执行一些编排逻辑。存储在数据库中的每个事件都包含一个序列化为 Avro 格式的 EventPayload，其中包含事件发生时的进程状态。该有效负载包含所有状态，而不仅仅是差异，因此我们一直在处理期间更新该有效负载。
2. 我们使用 Kafka Connect JDBC 源连接器从 EventStore 中读取数据，基本上只要在 EventStore 中发布新事件，连接器就会读取该事件并将其发布到 Kafka（Kafka 被用作 EventBus）。
3. 通过 Kafka 更新放置在另一个服务中的读取模型（这里有两种方法：使用 Kafka Connect JDBC Sink Connector 或使用 Kafka Consumer 并从 Consumer 进行事务更新）。

希望对你有帮助！

Answer 2

我在想如果我更新我的 ReadService 来收听 CommandService eventstore 直接不需要事件总线，那么我可以减少 这种延迟之一。

是的，您会减少延迟，但您会在两个服务之间引入耦合，这不一定是坏事，但如果两个服务是解耦的（使用总线），您可以独立扩展每个服务。

此外，如果您使用了 RabbitMQ 等托管总线，您将受益于消息确认、多种类型的消息传递和队列等。