Axon从2.4.3版本迁移到3.1.1有什么具体方法 [英] Is there any specific way for Axon migration from 2.4.3 version to 3.1.1

问题描述

我是axon的新手，正在进行从Axon 2.4.3到3.1.1的迁移，但是我找不到任何其他版本的迁移指南？
请您分享您的经验。
我面临很多问题，某些类已被删除，某些软件包已被更改。
对于某些课程，我什至找不到替代品，因此请向我提出一些建议。
如果有相同的指南，请提供它的链接。

I am new to axon and doing migration from Axon 2.4.3 to 3.1.1 but I am not able to find any migration guide which is available for other version? Can you please share your experience on how to do the same. I am facing a lot problem, some classes have been removed, some packages have been changed. For some classes I am even not able to find replacements, so please help me with some suggestion. If there is a guide for same please provide me with link of that.

在此先感谢

实际上，我无法找到轴突2.4.3中的替换项
ClusteringEventBus-
DefaultClusterSelector-
EventBusTerminal-
SimpleCluster-
SpringAMQPTerminal-
SpringAMQPConsumerConfiguration-
ListenerContainerLifecycleManager-

Acctually I am not able to find replacement for these which were there in axon 2.4.3 ClusteringEventBus- DefaultClusterSelector- EventBusTerminal- SimpleCluster- SpringAMQPTerminal- SpringAMQPConsumerConfiguration- ListenerContainerLifecycleManager-

推荐答案

目前尚无官方的Axon 2.x至3。 x迁移指南，尽管它在待办事项列表中有介绍。
但是，我可以给您一些迁移时应该寻找的指示：

There currently is not an official Axon 2.x to 3.x migration guide, although it is on the backlog to be introduced. I can, however, give you a couple of pointers you should look for whilst migrating:

1. 对于您的聚合，不再需要AbstractAnnotatedAggregateRoot ，因此将其删除。


2. 现在，使用静态 AggregateLifecycle完成在聚合中的发布事件。 apply（）函数，因此将其导入。


3. AbstractAnnotatedSaga 对于您的Sagas不再需要，因此


4. 如果在Spring应用程序中，建议在聚合上使用 @Aggregate 批注以通知Spring创建


5. 如果在Spring应用程序中，建议使用 @Saga 在您的Sagas上使用c $ c>批注，以通知Spring为Saga创建所有必需的bean（存储库，管理器，...）。


6. domain_event_entry 表中添加了 globalIndex 列，如果您准备好有一些事件需要正确迁移。 这篇文章提供了一些见解，说明Axon Framework用户如何解决此问题。


7. 在Axon 2.x中，您有群集的概念，您可以将事件处理组件归为一组。这已经被事件处理组所取代，在那里您可以在 SubscribingEventProcessor （将事件推送到事件处理组件）和 TrackingEventProcessor （存储并处理它们的事件）之间进行选择在事件处理组件中）。


8. 在Spring / Axon 2.x混合中，您可能已经通过Spring XML使用了配置。在3.x中，您可以使用（1） Configurer API，（2）使用 @EnableAxon 批注Spring Configuration类或（推荐3）使用 axon-spring-boot-starter 依赖性自动获取所有Axon Bean。

1. AbstractAnnotatedAggregateRoot is no longer necessary for your Aggregates, so remove it.
2. Publishing events in your aggregates is now done with the static AggregateLifecycle.apply() function, so import it.
3. AbstractAnnotatedSaga is no longer necessary for your Sagas, so remove it.
4. If in an Spring application, it is suggested to use the @Aggregate annotation on your aggregates to notify Spring to create all the required beans (repository, factory,,,) for an Aggregate.
5. If in an Spring application, it is suggested to use the @Saga annotation on your sagas to notify Spring to create all the required beans (repository, manager,,,) for a Saga.
6. The domain_event_entry table has an added globalIndex column, which if you already have quite some events needs correct migration. This post gives some insights how an Axon Framework user is solving this.
7. In Axon 2.x you had the notion of Clusters, were you could group your Event Handling Components in. This has been replacing by Event Processing Groups, where you've got the possibility to choose between a SubscribingEventProcessor (push events to the Event Handling Components) and a TrackingEventProcessor (pull events being stored and handle them in your Event Handling Components).
8. In a Spring / Axon 2.x mix, you've possibly used configuration through Spring XML. In 3.x you can use (1) the Configurer API, (2) use the @EnableAxon annotation on a Spring Configuration class or (3 - recommended) use the axon-spring-boot-starter dependency to automatically get all your Axon beans.

这是我能想到的，但是我可能忘记了一些建议。您还可以在此Axon用户组帖子中找到有关迁移的一些信息 ，或更常见的是 Axon用户组可能包含您正在寻找的某些内容

This is what I can think of on the top of my mind, but I'm probably forgetting some pointers. You can also find some info on migration in this Axon User Group post, or more generally the Axon User Group might have some things you're looking for.

顺便说一句，随时更新您的问题，然后我可以更新我的答案以填补您仍然缺少的空白！

By the way, feel free to update your question, then I can update my answer to fill in the blanks you're still missing!

更新

此位与从2.4.3更新时缺少的特定类有关到3.1.1：

This bit is regarding the specific classes you're missing when updating from 2.4.3 to 3.1.1:

就像我在较早的响应中所分享的那样，确切地说是第7点，Axon 2.x中的完整Cluster方法已被替换为Axon 3.x中的事件处理器方法。
从概念上讲，这里并没有太大变化，但是在内部，它的行为有所不同，并且意图更为简洁。因此，简短的答案是，所有这些类都已被事件处理器替换，其文档为此处。

Like I've shared in my earlier response, bullet point 7 to be exact, the complete Cluster approach in Axon 2.x has been replaced for the Event Processor approach in Axon 3.x. Conceptually not much has changed here, internally it however behaves differently and intendedly more concise. So the short answer is, all those classes have been replace by Event Processor, for which the documentation is here.

由于这根本不是很有帮助，我会为您提供针对您缺少的课程的具体答案，以帮助您。它很长，因此请做好准备：

As that's not very helpful at all, I'll give you a specific answer to the classes you're missing to help you out. It's quite long, so be prepared:

• ClusteringEventBus ：将事件发布到事件处理组件集群。在Axon 3.x中，处理组已经落后了，可以通过订阅或跟踪实现来处理。因此，请勿搜索 ClusteringEventBus 来将事件发布到组。所有3.x EventBus 实现都将知道如何将事件发布到 SubscribingEventProcessor ，而 TrackingEventProcessor 将从商店本身中提取事件（因此不涉及总线）。


• DefaultClusterSelector ：群集选择器负责将事件处理组件/事件侦听器分组到一个群集中。作为共享，我们不再将一组事件侦听器视为一个群集，而是一个处理组。 3.x中的行为使得事件侦听器实现的程序包名称就是所使用的处理组的名称。但是，您可以覆盖它，但是可以在事件监听器实现中添加 @ProcessingGroup（{processing-group-name}）作为类级别的注释。 Axon 3.x配置将在同一事件处理器下将具有相同处理组名称的事件侦听器自动分组（在2.4.x中将转换为同一群集）。默认情况下，使用的事件处理器实现将为订阅。可以在配置中将其调整为跟踪。


• SimpleCluster ：如前所述，不再有 SimpleCluster 。 EventProcessor 接口已取代该接口，该接口由订阅和跟踪事件处理器实现。


• EventBusTerminal ： EventBusTerminal 负责将事件发布到正确的群集，无论是本地的还是远程的。作为共享，我们不再拥有群集，而是拥有事件处理器组。事件如何到达事件处理器取决于所使用的实现。如果使用订阅（阅读：默认事件处理器），则 EventBus 负责将事件发布到它们。但是， TrackingEventProcessor 将异步启动其自己的线程以从 EventStore 中提取事件并就地发送这些事件传递给其事件监听器。因此，您不再需要搜索 EventBusTerminal ，因为它已经过时了。


• SpringAMQPTerminal ：如我上面所分享的， EventBusTerminal 已被删除，以使用订阅或跟踪方法。从Axon 3.1.1开始，对于Spring AMQP，我们有一个订阅事件处理器实现以侦听事件并将其发布在一个队列中，该队列是 SpringAMQPPublisher 。


• SpringAMQPConsumerConfiguration ：该配置类已经到位，因为当 axon-amqp 被使用时引入后，Spring并未像在Axon 3.x引入时那样创建 ListenerContainers 。因此，决定不为该用户保留我们自己的配置，而是将其交给Spring的主管。因此，您将找不到 SpringAMQPConsumerConfiguration ，应搜索Spring如何为AMQP创建使用者。


• ListenerContainerLifecycleManager ：此类是用于正确接收从队列传入的所有事件并将其发送到所有事件侦听器的实现。该类已由 SpringAMQPMessageSource 代替。

• ClusteringEventBus: This was in place to publish events to a Cluster of Event Handling Components. In Axon 3.x, that's a now behind a Processing Group, handled by either a Subscribing or Tracking implementation. Hence, do not search for the ClusteringEventBus to publish events to groups. All the 3.x EventBus implementations will know how to publish events to a SubscribingEventProcessor, whilst the TrackingEventProcessor will pull the events from the store itself (so no bus involved).
• DefaultClusterSelector: The Cluster selector was in charge of grouping Event Handling Components / Event Listeners into a cluster. As shared, we no longer regard a set of Event Listeners as a cluster, but as a Processing Group. The behavior in 3.x is such that the package name of your Event Listeners implementation is the name of the Processing Group used. You can however overwrite this, but adding the @ProcessingGroup({processing-group-name}) as a class level annotation to your Event Listener implementation. The Axon 3.x configuration will automatically group the Event Listeners with the same Processing Group Name under the same Event Processor (which in 2.4.x would translate to the same Cluster). By default, the Event Processor implementation used will be Subscribing. This can be adjusted to Tracking in the configuration.
• SimpleCluster: As follows from my earlier explanation, there no longer is a SimpleCluster. This has been replaced by the EventProcessor interface, which is implemented by the Subscribing and Tracking Event Processors.
• EventBusTerminal: The EventBusTerminal was in charge of publishing the events to the right Clusters, albeit local or remote. As shared, we no longer have Cluster, but Event Processor groups. How events get to a Event Processor depends on the implementation used. If Subscribing (read: the default Event Processor) is used, the EventBus is in charge of publishing the events to them. The TrackingEventProcessor will however, asynchronously, start it's own thread(s) to pull events from the EventStore and in place send those events to its Event Listeners. Thus, you no longer have to search for the EventBusTerminal, as it's obsolete.
• SpringAMQPTerminal: As I've shared above, the EventBusTerminal has been removed in favor of the Subscribing or Tracking approach. As of Axon 3.1.1, for Spring AMQP we've got a Subscribing Event Processor implementation to listen to events and publish them on a Queue, which is the SpringAMQPPublisher.
• SpringAMQPConsumerConfiguration: This configuration class was in place, because when axon-amqp was introduced, Spring did not create the ListenerContainers as it does at introduction point of Axon 3.x. Hence there was decided against keeping our own configuration set up for this consumers and leave that to the competent hands of Spring. Hence you will not find SpringAMQPConsumerConfiguration and should search how Spring creates the consumers for AMQP.
• ListenerContainerLifecycleManager: This class was the implementation to correctly receive all event incoming from queues and send them over to all your Event Listeners. This class has been replaced by the SpringAMQPMessageSource.

希望这将为您提供您正在寻找@AS的答案！

Hope this gives you the answers you're looking for @AS!

这篇关于Axon从2.4.3版本迁移到3.1.1有什么具体方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！