Архитектура, управляемая событиями
Это группа архитектурных стилей, исопльзуемых для создания распределённых асинхронных систем. Отличие архитектуры, основанной на событиях от традиционной архитектуры, онованной на запросах, в следующем:
- в архитектуре, основанной запросах, запросы выполняются оркестратором запросов (как правило, это приложение, предоставляющее пользовательский интерфейс - фронтенд) обработчикам запросов (бэкенд-сервисы). Обработчики запросов либо извлекают информацию из базы данных и возвращяют её на фронтенд, либо изменяют её в базе данных. Примером может быть запрос на предоставление списка пользователей системы;
- архитектура, основанная на событиях, реагирует на произошедшие в системе изменения. В качестве примера здесь можно привести событие "пользователь сделал ставку на аукционе". На это событие могут отреагировать несколько обработчиков событий, как согласованно, так и независимо друг от друга;
Есть две основных топологии архитектур, основанных на обработке событий:
- топология брокера - предоставоляет возможность динамически изменять реакцию на события;
- топология медиатора - предоставляет возможность контролировать процесс обработки событий обработчиками.
В топологии брокера событие обрабатывается одним или несколькими обработчиками, которые выполнив свою работу, сообщают об этом остальной системе путём размещения у брокера своего собственного события. Остальная система может либо каким-либо образом отреагировать на такое событие, либо проигнорировать его. Такой принцип размещения сообщений называется "выстрелил и забыл".
Такая архитектура позволяет динамически подключать и отключать обработчики событий без перезапуска всей ситемы. Все обработчики событий разделены и не зависят друг от друга.
Расплатой за такую гибкость является отсутствие контроля за бизнес-транзакциями и невозможность повторного запуска инициирующего события.
В топологии медиатора медиатор (приложение уровня Руководитель) выполняет работу по контролю бизнес-транзакций и соблюдению порядка обработки событий обработчиками.
Примеры существующих реализаций медиаторов:
- Apache Camel, Mule ESB или Spring Integration - для событий, не требующих сложной обработки ошибок и оркестровки;
- Apache ODE, Oracle BPEL Process Manager - если процесс обработки событий требует большого объема разветвленной обработки и нескольких динамических маршрутов со сложными директивами обработки ошибок;
- Business Process Management (jBPM, Camunda) - для процессов обработки событий, требующих длительных транзакций с участием человека.
Интересным отличием топологии брокера от топологии медиатора, помогающим понять разницу между ними, является то, как называются события обработки. Если для топологии брокера события будут называться как свершившиеся факты (order-created, payment-applied и email-sent), то в топологии медиатора это будут названия команд (place-order, send-
email и fulfill-order).
В топологии медиатора событие (команда) должно быть обязательно обработано. В топологии брокера событие может быть проигнорировано.
Продолжение следует.