考虑一个简单的用例，在这个用例中，我希望将产品评级作为事件存储在事件存储中。
我可以使用两种不同的方法：
使用axon:rating聚合负责处理createratingcommand并发送ratingcreatedevent。发送事件会将要存储在事件存储区中的等级设置为case。其他事件处理程序在连接到axon服务器示例并对分级执行任何需要的操作时，都可以重放事件流。在这种情况下，事件处理程序将用作流处理器。
使用kafka：kafkaproducer将用于在kafka主题中存储分级pojo（在正确序列化之后）。将主题的保留时间设置为“不确定”不会导致任何事件在时间上丢失。在这种情况下，kafka流将用于执行实际的评级处理逻辑。
在我看来，这两种方法都存在一些架构问题：
使用轴突时：
如果在聚合中没有需要维护或改变的真实状态，那么使用axon（或类似的解决方案）是否有任何附加值？聚合只是充当数据的“哑”占位符，但不提供任何状态更改逻辑。
axon如何处理相同事件类型的多个事件处理程序？它们都将并行处理同一事件（相同的聚合id），还是同一事件仅由其中一个处理程序处理一次？
axon事件存储中存储的事件是否一直保存到时间结束？
使用Kafka时：
kafka将具有相同密钥的事件/消息存储在同一分区中。在用户产品评级的用例中，如何为键选择最佳值？userid、productid或单独的主题，并在两个主题中发布每个事件。
明智的做法是为每个用户和每个产品使用一个单独的主题，从而在集群上产生大量的主题吗(大约<5k个产品和>10k个用户）。
我不知道这类问题的首选论坛是不是。。。我只是想知道在这个特定的用例中，您会推荐什么作为最佳实践。期待您的反馈，并随时指出我在前面的问题中遗漏的其他观点。
edit@12/11/2020 ：我刚刚发现一个相关讨论，其中包含与我的问题相关的有用信息。
1条答案
按热度按时间vjrehmav1#
正如扬·加林斯基所说，这个问题还没有一个简单的答案。这值得更广泛的讨论，例如axoniq的讨论论坛。不管怎样，这里有一些问题我肯定能给出答案，所以让我们开始吧：
axon问题1-正如您所注意到的，axon框架在以ddd为中心的应用程序中使用了很多。然而，没有什么能强迫你把自己建立在这个观念上。您可以将框架从事件源细节中剥离出来，并完全和纯粹地按照不同命令、事件和查询的消息传递思想建模细节。当版本4（当前版本）实际发布时，有意识地决定将axon框架版本3分为这些子部分。除此之外，我认为不仅仅是基于事件信息，还有很大的价值。使用不同的命令和查询只会进一步分离组件，从而使应用程序环境更加丰富和易于扩展。
轴突问题2-这取决于
@EventHandler带注解的方法实际上位于。如果它们在同一个类中，则只调用一个。如果它们被定位到不同的类中，那么它们都将接收相同的事件。此外，如果它们被隔离在不同的类之间，那么需要注意的是axon使用事件处理器作为调用事件处理程序的技术解决方案。如果不同的类被分组在同一个事件处理器下，则可以对首先调用哪个处理程序施加某种顺序。接下来，如果事件处理应该并行进行，则必须配置一个所谓的TrackingEventProcessor（axon框架中的默认值），因为它允许多个线程的配置同时处理事件。好吧，在这一节结束时，你在第二个问题中提出的所有问题都是一种选择，而不是必要的。只是配置的问题。可能值得在axon框架的这个文档页面上查看一下。axon问题3-由于axon服务器用于事件存储，因此根本没有保留期。所以是的，它们被默认保存到时间结束。但是，如果您觉得将事件存储在所有模型的基础上（就像使用事件源时一样）没有任何价值，那么没有什么可以阻止您删除事件。
这是我个人不太熟悉的Kafka问题（我猜是作为轴突框架的贡献者的人物）。不过，我也可以在这件事上给你我的两分钱，不过我在这里建议你另一种意见：
Kafka的问题1-从我个人的感觉，这样的应用程序将需要什么，我想你会希望能够检索所有的数据为一个给定的产品尽可能有效。我敢打赌，所有事件都在同一个分区中，这一点很重要，以使这个过程尽可能高效，因为它不需要在之后进行任何合并。考虑到这一点，我认为使用
ProductId最有意义。Kafka问题2-如果你预期只有5000个产品和10000个用户，我猜应该可以为这些单独的主题。意见来袭-在这里，虽然我个人觉得Kafka的意图是提供给你直接的权力，决定什么时候使用的主题，而不是复杂的，从你实际试图实现的，哪些业务功能。从应用程序开发的Angular 来看，赋予分离流的能力更像是一种事后思考。一旦您需要一个企业级/高效的消息总线，我想这就是这个选项真正发挥作用的时候了，因为这样您就可以针对批量进行优化。
希望这一切能帮助你进一步@kdw！