时间戳

首页 > 解决方案 > Axon 或 Kafka 支持 CQRS/ES

apache-kafka - 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. 为每个用户和每个产品使用单独的主题是否会导致集群上出现大量主题？（大约 <5k 产品和 >10k 用户）。

我不知道 SO 是否是此类问题的首选论坛......我只是想知道您（会）在这个特定用例中推荐什么作为最佳实践。期待您的反馈，并随时指出我在之前的问题中遗漏的其他想法。

EDIT@12/11/2020：我刚刚找到了一个相关讨论，其中包含与我的问题相关的有用信息。

标签： apache-kafkaarchitecturecqrsevent-sourcingaxon

解决方案

正如 Jan Galinski 已经说过的那样，这真的没有一个万无一失的答案。这值得在例如AxonIQ 的讨论论坛上进行更广泛的讨论。无论如何，这里有一些问题我绝对可以给出答案，所以让我们开始吧：

  1. Axon 问题 1 - Axon 框架正如您所注意到的，它在以 DDD 为中心的应用程序中使用了很多。然而，没有什么能强迫你把自己建立在这个概念上。您可以将框架从事件溯源细节以及建模细节中完全剥离出来，纯粹为了不同命令、事件和查询的消息传递理念。当版本 4（当前）实际发布时，将 Axon Framework 版本 3 分成这些子部分是一个有意识的决定。除此之外，我认为不仅仅基于事件消息是很有价值的。使用不同的命令和查询只会进一步解耦您的组件，从而形成更丰富、更容易扩展的应用程序环境。
  2. Axon Question 2 - 这取决于注释方法的实际位置。@EventHandler如果它们在同一个类中，则只会调用一个。如果它们被定位到不同的类中，那么两者都将收到相同的事件。此外，如果它们在不同的类之间隔离，请务必注意 Axon 使用事件处理器作为调用事件处理程序的技术解决方案。如果不同的类被分组在同一个事件处理器下，你可以强加一个特定的顺序，首先调用哪个处理程序。在此旁边，如果事件处理应该并行发生，您将必须配置一个所谓的TrackingEventProcessor（Axon Framework 中的默认设置），因为它允许配置多个线程来同时处理事件。好吧，总结本节，您在问题二中提出的所有问题都是一种选择，也不是必需品。真的只是配置问题。可能值得在Axon Framework 的此文档页面上查看有关此事的信息。
  3. Axon 问题 3 - 由于 Axon 服务器用于事件存储，因此根本没有保留期。所以是的，它们默认保存到时间结束。但是，如果您觉得存储事件没有任何价值，例如基于您的所有模型（就像您在使用事件源时所做的那样），那么没有什么可以阻止您删除事件。

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

  1. Kafka 问题 1 - 从我个人对此类应用程序需要的感觉来看，我假设您希望能够尽可能高效地检索给定产品的所有数据。我敢打赌，重要的是所有事件都在同一个分区中，以使这个过程尽可能高效，之后不需要任何合并。考虑到这一点，我认为使用ProductIdwill 最有意义。
  2. Kafka 问题 2 - 如果您预计只有 5_000 个产品和 10_000 个用户，我猜应该为这些设置单独的主题。意见传入- 虽然我个人认为 Kafka 的意图是让您直接决定何时使用主题，而不是您实际尝试实现的复杂功能，即业务功能。从应用程序开发的角度来看，赋予分离流的能力更像是事后的想法。一旦您需要企业级/高效的消息总线，我认为这就是这个选项真正闪耀的时候，然后您就可以针对批量进行优化。

希望所有这些能帮助您进一步@KDW！

推荐阅读