@EventHandler 重试逻辑和 DistributedCommandBus 设置

Question

第一个问题：所以我正在使用 Spring Eureka 和 DistributedCommandBus 通过以下设置：

  public CommandRouter springCloudCommandRouter(DiscoveryClient discoveryClient, Registration localServiceInstance) { ... }
  public CommandBusConnector springHttpCommandBusConnector(@Qualifier("localSegment") CommandBus localSegment, RestOperations restOperations, Serializer serializer) { .. }
  public DistributedCommandBus springCloudDistributedCommandBus(CommandRouter commandRouter, CommandBusConnector commandBusConnector) { ... }

我对这部分的问题是如何证明它有效？我有两个 K8 pods 运行上面的代码并且看到了一个运行 @CommandHandler 和另一个运行 @EventSourcingEvent 但没有查看日志中的任何内容以表明它正在使用总线。

只是想证明它是 "working"，因为我被要求这样做。

Eureka 部分正在运行，我看到了来自所述仪表板的所有信息。

编辑 - 删除了在另一个线程中提出的第二个问题

Answer 1

为了让我的回答更加集中，我只会为您的第一个问题提供一个建议，总结为：

How can I point out my DistributedCommandBus set up with Eureka is actually routing the commands to different instances?

我建议围绕此设置一些日志记录。这样，您可以记录消息何时从节点 1 分派以及何时由节点 2 处理。理想的做法是将 LoggingInterceptor 注册为 MessageHandlerInterceptor 和 MessageDispatchInterceptor.

为此，您必须在 DistributedCommandBus 和 "local segment" CommandBus 上进行注册。 DistributedCommandBus 将负责调度它，因此在调度时调用 LoggingInterceptor。本地段/CommandBus 负责向正确的 JVM 中的命令处理程序提供命令，因此将在处理时调用 LoggingInterceptor。

唯一的缺点是 LoggingInterceptor 在 Axon Framework 版本 4.2 之后将成为处理程序和调度拦截器。因此，就目前而言，您只需将其作为处理程序拦截器即可。

但是，这也足够了，因为 LoggingInterceptor 只会在处理命令时登录。这只会发生在实际处理命令的节点上。

希望对您有所帮助！

@EventHandler 重试逻辑和 DistributedCommandBus 设置

@EventHandler retry logic and DistributedCommandBus setup

spring-boot

axon