Есть ли какой-то конкретный способ миграции Axon с версии 2.4.3 на 3.1.1?

Question

Я новичок в Axon и выполняю миграцию с Axon 2.4.3 на 3.1.1, но я не могу найти руководство по миграции, доступное для другой версии? Можете ли вы поделиться своим опытом о том, как сделать то же самое. Я сталкиваюсь с большой проблемой, некоторые классы были удалены, некоторые пакеты были изменены. Для некоторых классов я даже не могу найти замен, поэтому, пожалуйста, помогите мне с некоторыми предложениями. Если есть руководство для того же, пожалуйста, дайте мне ссылку на это.

Заранее спасибо

На самом деле я не могу найти замену этим, которые были там в аксоне 2.4.3 ClusteringEventBus- DefaultClusterSelector- EventBusTerminal- SimpleCluster- SpringAMQPTerminal- SpringAMQPConsumerConfiguration- ListenerContainerLifecycleManager-

Answer 1

В настоящее время не существует официального руководства по переходу с Axon 2.x на 3.x, хотя оно находится в очереди. Однако я могу дать вам несколько советов, которые вы должны искать во время миграции:

1. AbstractAnnotatedAggregateRoot больше не требуется вашим агрегатам, поэтому удалите его.
2. Публикация событий в ваших агрегатах теперь выполняется со статической AggregateLifecycle.apply() функция, поэтому импортируйте ее.
3. AbstractAnnotatedSaga больше не нужен для ваших саг, поэтому удалите его.
4. Если в приложении Spring предлагается использовать @Aggregate аннотации к вашим агрегатам, чтобы уведомить Spring о создании всех необходимых компонентов (репозиторий, фабрика,,,) для агрегата.
5. Если в приложении Spring предлагается использовать @Saga аннотации на ваши саги, чтобы уведомить Spring о создании всех необходимых bean-компонентов (репозиторий, менеджер,,,) для Saga.
6. domain_event_entry к таблице добавлено globalIndex столбец, который, если у вас уже есть достаточно событий, нуждается в корректной миграции. Этот пост дает некоторое представление о том, как пользователь Axon Framework решает эту проблему.
7. В Axon 2.x у вас было понятие Clusters, где вы могли бы сгруппировать компоненты обработки событий. Это было заменено группами обработки событий, где у вас есть возможность выбирать между SubscribingEventProcessor (отправка событий в компоненты обработки событий) и TrackingEventProcessor (извлеките сохраненные события и обработайте их в ваших компонентах обработки событий).
8. В смеси Spring / Axon 2.x вы, возможно, использовали конфигурацию через Spring XML. В 3.x вы можете использовать (1) Configurer API, (2) использовать @EnableAxon аннотации для класса Spring Configuration или (3 - рекомендуется) использовать axon-spring-boot-starter зависимость, чтобы автоматически получить все ваши бобы аксона.

Это то, о чем я могу думать, но я, наверное, забыл некоторые указатели. Вы также можете найти некоторую информацию о миграции в этом сообщении группы пользователей Axon, или, в более общем случае, в группе пользователей Axon могут быть некоторые вещи, которые вы ищете.

Кстати, не стесняйтесь обновлять свой вопрос, тогда я могу обновить свой ответ, чтобы заполнить пробелы, которые вам все еще не хватает!

Обновить

Этот бит относится к конкретным классам, которые вы пропускаете при обновлении с 2.4.3 до 3.1.1:

Как я уже говорил в своем предыдущем ответе, точнее, пункт 7, полный кластерный подход в Axon 2.x был заменен подходом обработчика событий в Axon 3.x. Концептуально здесь мало что изменилось, однако внутренне оно ведет себя по-другому и намеренно более кратко. Итак, краткий ответ: все эти классы были заменены обработчиком событий, для которого документация здесь.

Поскольку это не очень полезно, я дам вам конкретный ответ на классы, которые вам не хватает, чтобы помочь вам. Это довольно долго, так что будьте готовы:

• ClusteringEventBus: Это было сделано для публикации событий в кластере компонентов обработки событий. В Axon 3.x это теперь группа обработки, которая обрабатывается реализацией подписки или отслеживания. Следовательно, не ищите ClusteringEventBus публиковать события в группы. Все 3.х EventBus реализации будут знать, как публиковать события в SubscribingEventProcessorв то время как TrackingEventProcessor будет извлекать события из самого магазина (так что автобус не задействован).
• DefaultClusterSelector: Селектор кластера отвечал за группирование компонентов обработки событий / прослушивателей событий в кластер. Что касается общего доступа, мы больше не рассматриваем набор прослушивателей событий как кластер, а как группу обработки. Поведение в 3.x таково, что имя пакета вашей реализации прослушивателей событий является именем используемой группы обработки. Вы можете переписать это, но добавив @ProcessingGroup({processing-group-name}) как аннотация на уровне класса для вашей реализации Event Listener. Конфигурация 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 не создал ListenerContainers как это происходит в точке введения Axon 3.x. Поэтому было принято решение не сохранять нашу собственную конфигурацию для этих потребителей и передать ее в компетентные руки Spring. Следовательно, вы не найдете SpringAMQPConsumerConfiguration и должен искать, как Spring создает потребителей для AMQP.
• ListenerContainerLifecycleManagerЭтот класс был реализацией для правильного получения всех событий, поступающих из очередей, и отправки их всем слушателям событий. Этот класс был заменен SpringAMQPMessageSource,

Надеюсь, что это даст вам ответы, которые вы ищете @AS!