Event Driven Architecture: краткий обзор

Event-Driven Architecture (EDA) — архитектурный подход, при котором система строится вокруг событий.

В таком подходе сервисы взаимодействуют друг с другом через генерацию событий, вместо того, чтобы вызывать друг друга напрямую через HTTP-запросы. Сервис, который породил событие, ничего не знает о сервисах, которые будут это событие обрабатывать (обратное тоже верно). Подход EDA широко применяется в архитектуре микросервисов.


Компоненты EDA
💩 Событие – любое изменение состояния некой сущности или возникновение новой.
💩Производитель события – сервис, который создаёт событие.
💩Обработчик события – сервис, который получает событие и обрабатывает его, после чего порождается новое событие – результат обработки события.
💩Маршрутизатор события – промежуточный слой, который обеспечивает. доставку события от производителя до обработчика. Обычно это брокер сообщений.

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


Модели доставки событий в EDA

1⃣Pub/Sub
1. Производители генерируют события и отправляют брокеру.
2. Брокер направляет события потребителям, которые на них подписались.
3. После отправки события удаляются.
Пример – RabbitMQ.

2⃣Потоковая передача
1. Производители генерируют события и отправляют брокеру.
2. Брокер сохраняет события у себя в журнале.
3. Потребители считывают события из любой части журнала в любой момент времени. События не удаляются брокером.
Пример – Kafka.


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

✅ Преимущества EDA

➕Слабая связность и гибкость: можно масштабировать, обновлять и развертывать сервисы независимо друг от друга.

➕Скорость: в EDA каждое событие может быть обработано независимо, что позволяет системе использовать параллельную обработку. А ещё можно эффективнее распределять нагрузку между обработчиками событий с учётом текущей загруженности узлов.

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


⛔️ Недостатки EDA

💩Сложность разработки и тестирования вследствие распределённой архитектуры и асинхронного взаимодействия.

💩Отсутствие транзакционности. Поскольку компоненты обработчика событий сильно разобщены и распределены, очень трудно поддерживать транзакции между ними. Если нужно разделить один шаг процесса работы между обработчиками событий, то есть вы используете отдельные обработчики событий для чего-то, что должно быть неделимой транзакцией — вероятно, EDA тут не подходит.

💩Единая точка отказа – брокер сообщений, который является связующим звеном между всеми сервисами. Если он выйдет из строя, то вся система в целом перестанет работать.

💩Дополнительные затраты на инфраструктуру. Реализация EDA требует больше производительности вычислительных ресурсов, нужно больше хранилищ данных, растут расходы на поддержку и управление инфраструктурой.


⭐️ Подборка материалов доступна в базе знаний по системному анализу

#архитектура #проектирование