CQRS、事件溯源和扩展

Question

很明显，基于这些模式的系统很容易扩展。但我想请问一下，具体是怎样的呢？我对可扩展性有几个疑问:

1. 如何扩展聚合？如果我要创建聚合 A 的多个实例，如何同步它们？如果其中一个实例处理命令并创建一个事件，则该事件应该传播到该聚合的每个实例？
2. 不应该有一些业务逻辑来呈现要请求的聚合实例吗？因此，如果我发出适用于聚合 A(订单) 并适用于一个特定订单的多个命令，则将其传递到同一实例是有意义的。或者？

在本文中:https://initiate.andela.com/event-sourcing-and-cqrs-a-look-at-kafka-e0c1b90d17d8 ,他们使用带有分区的 Kafka。因此，用户管理服务 - 聚合已扩展，但仅订阅主题的特定分区，其中包含特定用户的所有事件。

谢谢!

Answer 1

How to scale aggregates?

• 仔细选择聚合，确保您的命令在许多聚合中合理分布。您不希望聚合可能从并发用户接收大量命令。

• 序列化发送到聚合实例的命令。这可以通过聚合存储库和命令总线/队列来完成。但对我来说，最简单的方法是使用聚合版本控制进行乐观锁定，如 this post by Michiel Rook 中所述。

which instance of the agregate to request?

在我们的reSolve framework中我们在每个命令上创建聚合实例，并且不在请求之间保留它。其工作速度惊人地快 - 获取 100 个事件并将其缩减为聚合状态比在集群中找到正确的聚合实例更快。

这种方法是可扩展的，让您可以实现无服务器 - 每个命令一次 lambda 调用，并且之间没有共享状态。聚合事件过多的罕见情况可以通过快照解决。