Архитектура, управляемая событиями – это подход к проектированию и архитектуре программного обеспечения, в котором особое внимание уделяется использованию событий для запуска и взаимодействия между различными компонентами системы.
В этой архитектуре компоненты в системе развязаны и взаимодействуют посредством асинхронных событий, а не синхронных вызовов методов. Когда происходит событие, оно публикуется в шине событий или брокере, который затем доставляет событие всем заинтересованным слушателям или подписчикам.
Основными компонентами событийно-управляемой архитектуры являются:
- Источник/издатель события: компонент, генерирующий событие.
- Событие: сообщение, представляющее событие.
- Шина событий/брокер: механизм, который получает события и доставляет их заинтересованным слушателям или подписчикам.
- Прослушиватель событий/подписчик: компонент, который получает и обрабатывает событие.
Основное преимущество архитектуры, управляемой событиями, заключается в том, что она позволяет компонентам быть слабо связанными, что означает, что их можно разрабатывать, развертывать и масштабировать независимо друг от друга. Кроме того, он обеспечивает более гибкую и отказоустойчивую систему, поскольку компоненты могут реагировать на изменения в среде, обрабатывая получаемые ими события.
Давайте разберемся с этим на примере:
Скажем, у нас есть система, в которой мы получаем данные из внешнего приложения, мы должны брать эти данные, анализировать их и сохранять в БД, а данные поступают постоянно. Это отличный случай, когда эта архитектура может быть очень полезной.
Здесь я буду использовать микронавт в java-фреймворке (очень похоже на весеннюю загрузку, чтобы показать код)
- Определение класса событий Первым шагом является определение класса событий, который будет содержать входящие данные. В этом случае вы можете определить простой класс событий с именем
DataReceivedEvent
:
public class DataReceivedEvent { private final String data; public DataReceivedEvent(String data) { this.data = data; } public String getData() { return data; } }
- Определение издателя событий Далее необходимо определить издателя событий, который будет отправлять
DataReceivedEvent
в шину событий. В этом случае вы можете создать новый класс с именемDataReceiver
, который будет считывать входящие данные в виде строки, создавать новыйDataReceivedEvent
с данными и публиковать их в шине событий:
import io.micronaut.context.event.ApplicationEventPublisher; import javax.inject.Inject; import javax.inject.Singleton; @Singleton public class DataReceiver { @Inject private ApplicationEventPublisher eventPublisher; public void receiveData(String data) { DataReceivedEvent event = new DataReceivedEvent(data); eventPublisher.publishEvent(event); } }
В приведенном выше примере мы внедряем ApplicationEventPublisher
и создаем новый DataReceivedEvent
с входящими данными. Затем мы используем метод publishEvent
для отправки события в шину событий.
- Определение прослушивателя событий Далее необходимо определить прослушиватель событий, который будет получать
DataReceivedEvent
и анализировать данные. Для этого создайте новый класс и используйте аннотацию@EventListener
:
import io.micronaut.context.event.ApplicationEventListener; import javax.inject.Singleton; @Singleton public class DataReceivedEventListener implements ApplicationEventListener<DataReceivedEvent> { @Override public void onApplicationEvent(DataReceivedEvent event) { // Parse the data and store it into the database String data = event.getData(); // Do your parsing and database storing logic here } }J
В приведенном выше примере мы реализуем интерфейс ApplicationEventListener
и указываем тип события как DataReceivedEvent
. Затем мы реализуем метод onApplicationEvent, анализируем входящие данные и сохраняем их в базе данных.
В заключение можно сказать, что управляемая событиями архитектура — это мощный подход к созданию масштабируемых, устойчивых и реактивных систем, которые могут обрабатывать данные в режиме реального времени и обеспечивать гибкость бизнеса и инновации. Разделяя производителей и потребителей событий через шину событий, приложения могут быть разработаны для обработки большого количества событий, сохраняя при этом слабую связь, асинхронную связь и отказоустойчивость. Архитектура, управляемая событиями, не является универсальным решением, но она может предложить значительные преимущества по сравнению с традиционными архитектурами типа «запрос-ответ», особенно в таких областях, как Интернет вещей, потоковая аналитика, электронная коммерция и финансовые услуги. По мере того, как событийно-ориентированная архитектура продолжает развиваться, появляются новые инструменты и платформы, упрощающие ее внедрение и управление, что делает ее более доступной для разработчиков и предприятий любого размера. Чтобы оставаться конкурентоспособными в сегодняшней быстро развивающейся цифровой экономике, важно рассматривать архитектуру, управляемую событиями, как основной принцип проектирования для вашего следующего проекта.