Axon或Kafka支持CQRS / ES

如何解决Axon或Kafka支持CQRS / ES

考虑一个简单的用例，我要将产品评级作为事件存储在事件存储中。

我可以使用两种不同的方法：

1. 使用 Axon ：一个Rating聚合负责处理CreateRatingCommand并发送RatingCreatedEvent。发送事件将使评级存储在事件存储中。连接到Axon服务器实例并对等级进行任何需要的操作时，其他事件处理程序也可以重播事件流。在这种情况下，事件处理程序将用作流处理器。
2. 使用 Kafka ：KafkaProducer将用于在Kafka主题中存储Rating POJO（在适当的序列化之后）。将主题的保留时间设置为无限期将不会导致事件丢失。在这种情况下，将使用Kafka Streams进行实际的评分处理逻辑。

两种方法在我看来都存在一些架构问题：

使用轴突时：

1. 如果汇总中没有要维护或更改的真实状态，使用Axon（或类似解决方案）是否有任何附加值？聚合仅充当数据的“哑”占位符，但不提供任何状态更改逻辑。
2. Axon如何处理相同事件类型的多个事件处理程序？他们会全部并行处理同一事件（相同的聚合ID），还是同一事件仅由其中一个处理程序处理一次？
3. Axon事件存储区中存储的事件是否一直保留到时间结束？

使用 Kafka 时：

1. Kafka将具有相同密钥的事件/消息存储在同一分区中。在用户产品评级的用例中，如何选择键的最佳值？ UserId，ProductId或两者的单独主题，并在两个主题中发布每个事件。
2. 为每个用户和每个产品使用单独的主题会导致集群中出现大量主题，这是否明智？ （大约

我不知道SO是否是此类问题的首选论坛...我只是想知道您（会）建议在此特定用例中作为最佳实践。期待您的反馈，并随时指出我在之前的问题中错过的其他观点。

EDIT @ 12/11/2020 ：我刚刚发现一个related discussion，其中包含与我的问题有关的有用信息。

解决方法

正如扬·加林斯基（Jan Galinski）所说的那样，这确实没有一个万无一失的答案。值得对例如AxonIQ's Discuss forum进行更广泛的讨论。无论如何，这里肯定有一些问题可以解答，所以让我们开始吧：

1. Axon问题1 -您已经注意到Axon Framework在以DDD为中心的应用程序中使用了很多。但是，没有什么可以迫使您完全基于该概念。您可以从“事件源”特定内容中剥离框架，也可以完全或完全对特定模型进行建模，以实现不同命令，事件和查询的消息传递思想。实际发布版本4（当前）时，将Axon Framework版本3分为这些子部分是一个明智的决定。紧接着，我认为不仅仅基于事件消息具有很大的价值。使用不同的命令和查询只会进一步使您的组件分离，从而使应用程序格局更加丰富和轻松。
2. 轴突问题2 -这取决于实际使用@EventHandler注释的方法在位置。如果它们在同一个类中，则只会调用一个。如果将它们放置在不同的类中，则两者将接收相同的事件。此外，如果将它们分隔在不同的类之间，则必须注意Axon使用事件处理器作为调用事件处理程序的技术解决方案。如果将不同的类分组在同一事件处理器下，则可以强加一定的顺序，首先调用该处理程序。接下来，如果事件处理应该并行发生，那么您将必须配置一个所谓的TrackingEventProcessor（Axon Framework中的默认设置），因为它允许配置多个线程来同时处理事件。好了，总结本节，您在第二个问题中要问的所有问题都是一个选择，都不是必须的。真的只是配置问题。可能值得在Axon Framework的this文档页面上进行检查。
3. Axon问题3 -由于Axon Server用于事件存储，因此根本没有保留期。所以是的，它们默认情况下会保留到时间结束。但是，如果您觉得存储事件没有任何价值，例如将所有模型都作为基础（就像使用事件源时那样），那么没有任何事情可以阻止您放弃事件。

这是我个人不太熟悉的Kafka问题（我猜是作为Axon Framework贡献者的数字）。我也可以在这件事上给你我的两分钱，尽管我会在这里建议第二种意见：

1. Kafka问题1 -从我个人对此类应用程序的要求出发，我认为您希望能够尽可能高效地检索给定产品的所有数据。我敢打赌，所有事件都在同一个分区中非常重要，这样才能使此过程尽可能高效，因为此后不需要任何合并。考虑到这一点，我认为使用ProductId最有意义。
2. Kafka问题2 -如果您仅预期5_000个产品和10_000个用户，那么我想为这些主题设置单独的主题应该是可行的。 意见征询-尽管我个人认为Kafka的意图是向您提供直接的力量，以便您决定何时使用主题而不是实际要实现的功能，业务功能。从应用程序开发的角度来看，提供隔离流的能力更像是事后的思考。我认为，一旦您需要企业级/高效的消息总线，那该选项就会真正发挥作用，然后您就可以进行批量优化了。

希望所有这些都可以帮助您进一步@KDW！