Архитектура на основе событий: анализ паттерна
Архитектурный паттерн, управляемый событиями, является достаточно сложным для реализации, в первую очередь из-за его асинхронной распределенной природы. При реализации этого паттерна необходимо решать различные проблемы распределенной архитектуры, такие как доступность удаленных процессов, отсутствие реакции на запросы и логика переподключения брокера в случае отказа брокера или посредника.
Одним из соображений, которое необходимо учитывать при выборе данного архитектурного паттерна, является отсутствие атомарных транзакций для одного бизнес-процесса. Поскольку компоненты процессора событий сильно разобщены и распределены, очень сложно поддерживать транзакционную единицу работы между ними. Поэтому при проектировании приложения с использованием этого паттерна необходимо постоянно думать о том, какие события могут выполняться независимо, а какие нет, и в соответствии с этим планировать гранулярность процессоров событий. Если вы обнаружите, что вам необходимо разделить единую работу между процессорами событий, т.е. если вы используете отдельные процессоры для чего-то, что должно быть неразделенной транзакцией, то, вероятно, этот паттерн не подходит для вашего приложения.
Пожалуй, одним из наиболее сложных аспектов паттерна событийно-ориентированной архитектуры является создание, сопровождение и управление контрактами компонентов процессора событий. Каждое событие обычно связано с определенным контрактом (например, значения и формат данных, передаваемых процессору событий). При использовании этого паттерна крайне важно с самого начала остановиться на стандартном формате данных (например, XML, JSON, Java Object и т.д.) и установить политику версионирования контрактов.
Анализ паттерна
В следующей таблице приведен рейтинг и анализ общих характеристик архитектуры для паттерна событийно-управляемой архитектуры. Оценка каждой характеристики основывается на естественной тенденции развития данной характеристики как возможности на основе типичной реализации паттерна, а также на том, чем данный паттерн известен в целом.
Общая маневренность
Анализ: Общая гибкость - это способность быстро реагировать на постоянно изменяющуюся среду. Поскольку компоненты процессоров событий являются одноцелевыми и полностью отделены от других компонентов процессоров событий, изменения, как правило, касаются одного или нескольких процессоров событий и могут быть сделаны быстро, не затрагивая другие компоненты.
Простота развертывания
Анализ: В целом данный паттерн относительно прост в развертывании благодаря развязанности компонентов событийного процессора. Топологию брокера развернуть легче, чем топологию посредника, прежде всего потому, что компонент посредника событий несколько тесно связан с процессорами событий: изменение компонента процессора событий может потребовать изменения и в посреднике событий, что требует развертывания обоих компонентов для любого изменения.
Тестируемость
Анализ: Хотя индивидуальное модульное тестирование не представляет особых трудностей, для генерации событий требуется специализированный клиент тестирования или инструмент тестирования. Тестирование также осложняется асинхронным характером данного паттерна.
Производительность
Анализ: Хотя, конечно, можно реализовать архитектуру, управляемую событиями, которая будет работать не очень хорошо из-за всей инфраструктуры обмена сообщениями, в целом паттерн достигает высокой производительности за счет своих асинхронных возможностей; другими словами, возможность выполнения развязанных, параллельных асинхронных операций перевешивает затраты на постановку сообщений в очередь и снятие с нее.
Масштабируемость
Анализ: Масштабируемость в данном паттерне достигается за счет высокой степени независимости и развязанности процессоров событий. Каждый процессор событий может масштабироваться отдельно, что обеспечивает тонкую масштабируемость.
Простота разработки
Анализ: Разработка может быть несколько затруднена из-за асинхронного характера паттерна, а также создания контрактов и необходимости создания более сложных условий обработки ошибок в коде для не реагирующих на события процессоров и отказавших брокеров.