Архитектура на основе событий
Архитектура на основе событий или Событийно-ориентированная архитектура (EDA - Event-Driven Architecture) - это популярный паттерн распределенной асинхронной архитектуры, используемый для создания высокомасштабируемых приложений. Он также обладает высокой адаптивностью и может использоваться как для небольших приложений, так и для больших и сложных. Событийно-ориентированная архитектура состоит из высокоразвязанных одноцелевых компонентов обработки событий, которые асинхронно получают и обрабатывают события.
Архитектурный паттерн событийной архитектуры включает в себя две основные топологии - медиатор и брокер. Топология медиатора обычно используется в тех случаях, когда необходимо организовать несколько шагов в рамках события через центрального посредника, а топология брокера - когда необходимо связать события в цепочку без использования центрального посредника. Поскольку характеристики архитектуры и стратегии реализации этих двух топологий различаются, важно понимать каждую из них, чтобы знать, какая из них лучше подходит для конкретной ситуации.
Топология посредника (медиатор)
Топология медиатора полезна для событий, состоящих из нескольких этапов и требующих определенного уровня оркестровки для обработки события. Например, одно событие по размещению сделки с акциями может потребовать сначала подтвердить сделку, затем проверить соответствие этой сделки различным правилам, назначить сделку брокеру, рассчитать комиссию и, наконец, разместить сделку у брокера. Все эти этапы требуют определенного уровня оркестровки для определения порядка их выполнения и того, какие из них могут выполняться последовательно и параллельно.
В топологии медиатора можно выделить четыре основных типа архитектурных компонентов: очереди событий, медиатор событий, каналы событий и процессоры событий. Поток событий начинается с того, что клиент посылает событие в очередь событий, которая используется для передачи события медиатору событий. Посредник событий получает исходное событие и оркеструет его, посылая дополнительные асинхронные события в каналы событий для выполнения каждого этапа процесса. Процессоры событий, которые прослушивают каналы событий, получают событие от медиатора событий и выполняют определенную бизнес-логику для обработки события. На рис. 2-1 показана общая топология медиатора в паттерне архитектуры, ориентированной на события.
В архитектуре, управляемой событиями, обычно имеется от нескольких десятков до нескольких сотен очередей событий. В паттерне не указывается реализация компонента очереди событий; это может быть очередь сообщений, конечная точка веб-сервиса или любая их комбинация.
В рамках данного паттерна существует два типа событий: начальное событие и событие обработки. Начальное событие - это исходное событие, полученное медиатором, а события обработки - это события, которые генерируются медиатором и принимаются компонентами, обрабатывающими события.
Компонент event-mediator отвечает за организацию шагов, содержащихся в исходном событии. Для каждого шага исходного события медиатор событий посылает в канал событий определенное событие обработки, которое затем принимается и обрабатывается процессором событий. Важно отметить, что посредник событий не выполняет бизнес-логику, необходимую для обработки начального события, а лишь знает о шагах, необходимых для обработки начального события.
Каналы событий используются медиатором событий для асинхронной передачи процессорам событий определенных событий обработки, связанных с каждым шагом исходного события. Каналы событий могут быть как очередями сообщений, так и темами сообщений, хотя темы сообщений наиболее широко используются в топологии медиатора, чтобы события обработки могли обрабатываться несколькими процессорами событий (каждый из которых выполняет свою задачу в зависимости от полученного события обработки).
Компоненты процессора событий содержат бизнес-логику приложения, необходимую для обработки события обработки. Процессоры событий - это автономные, независимые, с высокой степенью развязки компоненты архитектуры, которые выполняют определенную задачу в приложении или системе. Хотя детализация компонентов процессора событий может варьироваться от мелкой (например, расчет налога с продаж по заказу) до крупной (например, обработка страхового случая), важно помнить, что в общем случае каждый компонент процессора событий должен выполнять единственную бизнес-задачу и не полагаться на другие процессоры событий для выполнения своей конкретной задачи.
Посредник событий может быть реализован различными способами. Как архитектор, вы должны понимать каждый из этих вариантов реализации, чтобы убедиться, что выбранное вами решение для медиатора событий соответствует вашим потребностям и требованиям.
Наиболее простой и распространенной реализацией медиатора событий является использование интеграционных узлов с открытым исходным кодом, таких как Spring Integration, Apache Camel или Mule ESB. Потоки событий в этих интеграционных узлах с открытым исходным кодом обычно реализуются с помощью Java-кода или DSL (языка, специфичного для конкретной области). Для более сложного посредничества и оркестровки можно использовать BPEL (язык исполнения бизнес-процессов) в сочетании с BPEL-движком, например, с открытым исходным кодом Apache ODE. BPEL - это стандартный XML-подобный язык, описывающий данные и шаги, необходимые для обработки исходного события. Для очень больших приложений, требующих гораздо более сложной оркестровки (включая шаги, предполагающие взаимодействие с людьми), можно реализовать посредника событий с помощью менеджера бизнес-процессов (BPM), например jBPM.
Понимание своих потребностей и их соответствие правильной реализации медиатора событий является критически важным для успеха любой событийно-управляемой архитектуры, использующей данную топологию. Использование интеграционного узла с открытым исходным кодом для выполнения очень сложной оркестровки управления бизнес-процессами - это залог неудачи, так же как и применение BPM-решения для выполнения простой логики маршрутизации.
Чтобы проиллюстрировать работу топологии посредника, предположим, что вы застрахованы в страховой компании и решили переехать. В этом случае исходное событие может называться как событие переезда. Шаги, связанные с обработкой события переезда, содержатся в медиаторе событий, как показано на рис. 2-2. Для каждого шага исходного события медиатор событий создает событие обработки (например, смена адреса, пересчет котировок и т.д.), отправляет это событие обработки в канал событий и ожидает, пока оно будет обработано соответствующим процессором событий (например, процессом клиента, процессом котировки и т.д.). Этот процесс продолжается до тех пор, пока не будут обработаны все шаги исходного события. Одиночная полоса над шагами пересчета котировок и обновления требований в медиаторе событий указывает на то, что эти шаги могут выполняться одновременно.