Обзор управляемой событиями архитектуры (EDA)

Архитектура, управляемая событиями (EDA):
Архитектура, управляемая событиями, — это подход к разработке программного обеспечения, при котором службы (операции) программного обеспечения запускаются событиями. И именно поэтому этот подход известен как Архитектура, управляемая событиями.

Тогда что значит событие? Когда пользователь выполняет действие в приложении, построенном с использованием подхода EDA, происходит изменение состояния и генерируется реакция, называемая событием.

Вот несколько примеров,

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

Компоненты ЭДА:
EDA состоит из 4 компонентов, как показано ниже.

1. Мероприятие -
   Изменение состояния произошло в результате действия пользователя.
2. Обработчик службы/события –
   Сервисы обычно реагируют на события, и реакцией может быть процесс или генерация событий соответственно.
3. Цикл событий –
   Цикл событий обрабатывает и обеспечивает плавный поток взаимодействий между событиями и службами.
4. Слои потока событий –
   Уровни потока событий подразделяются на три. Они, производитель событий, потребитель событий. канал событий/маршрутизатор.

Как работает ЭДА?
Когда производитель событий обнаруживает изменение состояния, он генерирует событие и представляет его в виде сообщения. На этом этапе производитель не знает потребителя события. Он просто отправляет событие на маршрутизатор. Затем маршрутизатор обрабатывает событие и выполняет требуемый ответ на событие. После этого маршрутизатор информирует потребителя о событии и отправляет событие потребителю. Выход события является результатом потребления события.

Здесь слои слабо связаны. Таким образом, отправителю события не обязательно знать потребителя события. А также потребителю не обязательно знать производителя событий. Такое расположение приводит к интероперабельности.

Преимущества архитектуры, управляемой событиями:

1. Масштабируемость –
   Гибкость приложения, разработанного с использованием этого подхода, позволяет увеличивать и уменьшать масштаб в зависимости от потребностей. Он также может обрабатывать огромное количество данных, необходимых для аналитики.
2. Совместимость –
   Слабо связанные уровни/сервисы EDA обеспечивают мгновенный доступ к большим и разнообразным объемам данных. И когда производитель отправляет событие потребителю, даже если потребитель не работает, событие сохраняется на маршрутизаторе, и тогда потребитель может использовать событие. Это повышает гибкость и надежность приложения.
3. Сокращение эксплуатационных расходов –
   В событийно-управляемой архитектуре все происходит в ответ на событие. Таким образом, потребление пропускной способности сети, загрузка ЦП и шифрование сравнительно ниже, чем у традиционной архитектуры — модели, управляемой запросами.
4. Аудит стал проще –
   Канал событий или маршрутизатор является промежуточным звеном, которое проверяет приложение и определяет рекомендации. Эти рекомендации могут устанавливать контроль доступа к данным и шифровать события как на уровне производителя, так и на уровне потребителя.
5. Асинхронность –
   Архитектура, управляемая событиями, является асинхронной без блокировки. Это означает, что если событие запускает службу и начинает реагировать на событие, это не будет блокировать запуск или реакцию других служб. Этот аспект делает архитектуру, управляемую событиями, более гибкой и адаптируемой. Сервисы в этой архитектуре не связаны между собой и не зависят друг от друга. Так что это также имеет более высокую отказоустойчивость.

Когда мы перейдем к архитектуре, управляемой событиями:

1. Параллельная обработка -
   Когда необходимо, чтобы несколько систем работали в ответ на событие, в этом случае мы можем использовать архитектуру, управляемую событиями. Таким образом, соответствующий маршрутизатор будет отправлять события в системы, и каждая система может обрабатывать событие по-разному для разных целей.
2. Мониторинг состояния ресурсов –
   Архитектура, управляемая событиями, полезна, когда необходимо постоянно отслеживать и контролировать ресурсы, и в этом случае EDA может отслеживать и предупреждать о любых изменениях или обновлениях в ресурсах.
3. Гетерогенная система –
   Если система работает на нескольких стеках, в этом случае можно использовать архитектуру, управляемую событиями, для обмена информацией между ними. Маршрутизатор событий возьмет на себя ответственность за взаимодействие между системами.

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