Архитектура, управляемая событиями – это подход к проектированию и архитектуре программного обеспечения, в котором особое внимание уделяется использованию событий для запуска и взаимодействия между различными компонентами системы.

В этой архитектуре компоненты в системе развязаны и взаимодействуют посредством асинхронных событий, а не синхронных вызовов методов. Когда происходит событие, оно публикуется в шине событий или брокере, который затем доставляет событие всем заинтересованным слушателям или подписчикам.

Основными компонентами событийно-управляемой архитектуры являются:

  1. Источник/издатель события: компонент, генерирующий событие.
  2. Событие: сообщение, представляющее событие.
  3. Шина событий/брокер: механизм, который получает события и доставляет их заинтересованным слушателям или подписчикам.
  4. Прослушиватель событий/подписчик: компонент, который получает и обрабатывает событие.

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

Давайте разберемся с этим на примере:

Скажем, у нас есть система, в которой мы получаем данные из внешнего приложения, мы должны брать эти данные, анализировать их и сохранять в БД, а данные поступают постоянно. Это отличный случай, когда эта архитектура может быть очень полезной.

Здесь я буду использовать микронавт в java-фреймворке (очень похоже на весеннюю загрузку, чтобы показать код)

  1. Определение класса событий Первым шагом является определение класса событий, который будет содержать входящие данные. В этом случае вы можете определить простой класс событий с именем DataReceivedEvent:
public class DataReceivedEvent {
    private final String data;
    public DataReceivedEvent(String data) {
        this.data = data;
    }
    public String getData() {
        return data;
    }
}
  1. Определение издателя событий Далее необходимо определить издателя событий, который будет отправлять 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 для отправки события в шину событий.

  1. Определение прослушивателя событий Далее необходимо определить прослушиватель событий, который будет получать 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, анализируем входящие данные и сохраняем их в базе данных.

В заключение можно сказать, что управляемая событиями архитектура — это мощный подход к созданию масштабируемых, устойчивых и реактивных систем, которые могут обрабатывать данные в режиме реального времени и обеспечивать гибкость бизнеса и инновации. Разделяя производителей и потребителей событий через шину событий, приложения могут быть разработаны для обработки большого количества событий, сохраняя при этом слабую связь, асинхронную связь и отказоустойчивость. Архитектура, управляемая событиями, не является универсальным решением, но она может предложить значительные преимущества по сравнению с традиционными архитектурами типа «запрос-ответ», особенно в таких областях, как Интернет вещей, потоковая аналитика, электронная коммерция и финансовые услуги. По мере того, как событийно-ориентированная архитектура продолжает развиваться, появляются новые инструменты и платформы, упрощающие ее внедрение и управление, что делает ее более доступной для разработчиков и предприятий любого размера. Чтобы оставаться конкурентоспособными в сегодняшней быстро развивающейся цифровой экономике, важно рассматривать архитектуру, управляемую событиями, как основной принцип проектирования для вашего следующего проекта.