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 Pod，其中一个运行@CommandHandler，另一个运行@EventSourcingEvent，但是在日志中没有看到任何迹象表明它正在使用总线。

只是想能够像我被要求那样显示它正在“工作”。

Eureka部件正在工作，我从所说的仪表板中看到了所有信息。

第二个问题：@EventHandler内置了哪种重试逻辑？

我更改了方法以专门引发异常，它只是记录了该异常并继续。我希望稍后可以重试，或者在哪里发布有关失败原因的研究信息。

第三个问题：使用AggregateTestFixture<?>时，有没有一种方法可以模拟递增的SequenceNumber？

SampleCreateCommand sampleCreateCommand = SampleCreateCommand.builder().id("test-00001").dataVersion(0L).build()
SampleUpdateCommand SampleUpdateCommand = SampleUpdateCommand.builder().id("test-00001").dataVersion(0L).build() // setting this to 1L gives the 2nd error below
ResultValidator resultValidator = fixtureConfiguration
                    .givenCommands(sampleCreateCommand) // setup initial 0L
                    .when(sampleUpdateCommand) // update to 1L??

resultValidator.expectEvents(SampleUpdateEvent.builder().id("test-00001").dataVersion(1L).build())

给出错误：

|In a message of type [SampleUpdateEvent], the property [dataVersion] was not as expected.
|Expected <1> but got <0>
-
ConflictingAggregateVersionException: The version of aggregate [test-00001] was not as expected. Expected [1], but repository found [0]

Answer 1

为了使我的答案更加集中，我仅对您的第一个问题提供建议，总结为：

如何指出我在Eureka上进行的DistributedCommandBus设置实际上是将命令路由到其他实例？

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

为此，您将必须在DistributedCommandBus上进行注册，也必须在“本地网段” CommandBus上进行注册。 DistributedCommandBus将负责分发它，并因此在分发时调用LoggingInterceptor。本地网段/ CommandBus负责向正确的JVM中的命令处理程序提供命令，因此将在处理后调用LoggingInterceptor。

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

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

希望这会有所帮助！

@EventHandler重试逻辑和DistributedCommandBus设置

1 个答案: