Архитектура на основе событий. Топология брокера.
Топология брокера отличается от топологии посредника тем, что центральный посредник событий отсутствует, а поток сообщений распределяется между компонентами процессора событий по цепочке через легкий брокер сообщений (например, ActiveMQ, HornetQ и т.д.). Такая топология удобна, когда у вас относительно простой поток обработки событий и вам не нужна (или нужна) централизованная оркестровка событий.
В топологии брокера существует два основных типа архитектурных компонентов: компонент брокера и компонент обработчика событий. Компонент брокера может быть централизованным или федеративным и содержит все каналы событий, которые используются в потоке событий. Каналы событий, содержащиеся в компоненте брокера, могут быть очередями сообщений, темами сообщений или их комбинацией.
Эта топология показана на рис. 2-3. Как видно из схемы, центрального компонента-посредника, контролирующего и организующего исходное событие, нет; каждый компонент-процессор событий отвечает за обработку события и публикацию нового события, указывающего на выполненное им действие. Например, процессор событий, балансирующий портфель акций, может получить исходное событие под названием "дробление акций". На основе этого события процессор событий может произвести ребалансировку портфеля и опубликовать брокеру новое событие rebalance portfolio, которое затем будет перехвачено другим процессором событий. Обратите внимание, что возможны случаи, когда событие публикуется одним процессором событий, но не подхватывается другим. Это часто случается при развитии приложения или при обеспечении будущей функциональности и расширений.
Чтобы проиллюстрировать работу топологии брокера, воспользуемся тем же примером, что и в топологии медиатора (переезд застрахованного лица). Поскольку в топологии брокера нет центрального посредника для получения исходного события, компонент customer-process получает событие напрямую, изменяет адрес клиента и посылает событие об изменении адреса клиента (например, событие change address). В данном примере событие смены адреса интересует два процессора: процесс котировок и процесс претензий. Компонент обработки котировок пересчитывает новые тарифы автострахования на основе изменения адреса и публикует в остальной части системы событие, указывающее на это (например, событие recalc quote). Компонент обработки претензий, в свою очередь, получает то же событие смены адреса, но в этом случае он обновляет неоплаченный страховой случай и публикует событие в системе как событие обновления претензии. Затем эти новые события подхватываются другими компонентами обработки событий, и цепочка событий продолжается в системе до тех пор, пока не будет больше опубликовано ни одного события для данного конкретного инициирующего события.
Как видно из рис. 2-4, топология брокера представляет собой цепочку событий для выполнения бизнес-функции. Лучший способ понять топологию брокера - это представить ее в виде эстафеты. В эстафете бегуны, держа в руках эстафетную палочку, пробегают определенное расстояние, затем передают палочку следующему участнику и так далее по цепочке, пока последний участник не пересечет финишную черту. В эстафете, как только бегун передает эстафету, он завершает гонку. Это справедливо и для топологии брокера: как только процессор события передает эстафету, он больше не участвует в обработке этого конкретного события.
Перевод книги "Software Architecture Patterns".