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 требует больше производительности вычислительных ресурсов, нужно больше хранилищ данных, растут расходы на поддержку и управление инфраструктурой.
⭐️ Подборка материалов доступна в базе знаний по системному анализу
#архитектура #проектирование
Event-Driven Architecture (EDA) — архитектурный подход, при котором система строится вокруг событий.
В таком подходе сервисы взаимодействуют друг с другом через генерацию событий, вместо того, чтобы вызывать друг друга напрямую через HTTP-запросы. Сервис, который породил событие, ничего не знает о сервисах, которые будут это событие обрабатывать (обратное тоже верно). Подход EDA широко применяется в архитектуре микросервисов.
Компоненты EDA
Одни и те же сервисы могут выполнять как роль производителя, так и роль обработчика событий.
Модели доставки событий в EDA
1. Производители генерируют события и отправляют брокеру.
2. Брокер направляет события потребителям, которые на них подписались.
3. После отправки события удаляются.
Пример – RabbitMQ.
1. Производители генерируют события и отправляют брокеру.
2. Брокер сохраняет события у себя в журнале.
3. Потребители считывают события из любой части журнала в любой момент времени. События не удаляются брокером.
Пример – Kafka.
Преимущества событийно-ориентированной архитектуры вытекают из реализации принципа слабой связности. В событийно-ориентированной архитектуре сервисы взаимодействуют исключительно через события. При этом производитель события не знает, какие обработчики принимают события, а обработчики не знают, какие производители их генерируют.
✅ Преимущества EDA
⛔️ Недостатки EDA
⭐️ Подборка материалов доступна в базе знаний по системному анализу
#архитектура #проектирование