Event-Driven Architecture (EDA) — архитектурный подход, где основное внимание в работе ИТ-систем уделяется обработке событий. В чем он заключается, как работает и что дает, читателям RSpectr рассказывает руководитель разработки информационных систем и приложений компании Axenix Дмитрий Кузнецов.

ПРЕДМЕТ РАЗГОВОРА

EDA предполагает реагирование ИТ-системы и ее компонентов на различные события или изменения состояний связанных с ней объектов, расположенных как во внешней среде, так и в самой системе.

Подход помогает в создании асинхронных и реактивных ИТ-решений, идеально подходящих для сценариев, требующих определенной реакции на изменения в реальном времени. Например, для обработки финансовых транзакций, систем обработки клиентских заказов или координации деятельности множества объектов управления в онлайн-режиме.

Событийно-ориентированная архитектура является решением, сконструированным из множества децентрализованных сервисов, которые занимаются публикацией, обработкой или маршрутизацией событий. В системах, построенных по такой архитектуре, отсутствуют какие-либо управляющие компоненты, – они работают по принципу эстафеты, где управление участком процесса передается тому компоненту/участнику, который за него должен отвечать.

СОБЫТИЕМ В EDA-ТЕРМИНОЛОГИИ СЧИТАЕТСЯ ЛЮБОЕ ИЗМЕНЕНИЕ ИЛИ ОБНОВЛЕНИЕ СОСТОЯНИЯ ОБЪЕКТА ИТ-СИСТЕМЫ

К примеру, это может быть добавление продукта в корзину, окончание генерации файла-отчета или поступление заказа в службу доставки после оплаты клиентом. События необратимы, они сообщают о том, что произошли изменения и их необходимо обработать всеми «заинтересованными» компонентами.

В теле события могут фиксироваться как состояние и детализация самих изменений (наименование, цена товара, количество в заказе), так и указатели на объект (например, «отправка заказа № 567») для последующего поиска нужных данных на этапе обработки.

В отличие от более привычных всем «командно-ориентированных подходов» EDA способствует более слабой связности взаимодействующих друг с другом компонентов, так как они не обязаны предоставлять друг другу явную реакцию на полученные изменения. Это значительно упрощает процесс масштабирования, обновления и развертывания отдельных элементов системы вне зависимости друг от друга.

А КАК ЖЕ КЛАССИКА?

Старая добрая монолитная архитектура подразумевает разработку единого, централизованного приложения, что обеспечивает относительную простоту в тестировании и развертывании всех компонентов, находящихся в одном месте.

Этот вариант подходит для небольших ИТ-решений, где декомпозиция на компоненты и высокая масштабируемость не являются первоочередными требованиями. Например, решение разрабатывается одной командой и не видно перспектив его усложнения или увеличения численности команд в будущем.

Микросервисная архитектура, в противовес монолиту, предполагает декомпозицию на множество более мелких решений, разделенных по определенному принципу (бизнес-специфика, организация команд и продуктов) и взаимодействующих друг с другом.

ЕЕ СИЛЬНЫЕ СТОРОНЫ ВКЛЮЧАЮТ ВОЗМОЖНОСТЬ ПОВТОРНОГО ИСПОЛЬЗОВАНИЯ ЛОГИКИ И ГИБКОСТЬ ПОСТРОЕНИЯ СЛОЖНЫХ РЕШЕНИЙ

Многоуровневая (N-уровневая) архитектура призвана обеспечивать организованную и четко структурированную систему, разделяя ее на различные уровни, каждый из которых специализируется на выполнении своих уникальных ролей и задач.

EDA, со своей стороны, не противоречит выбранному разбиванию и декомпозиции ответственности, а лишь способствует созданию систем с низкой степенью взаимосвязи компонентов, обеспечивая тем самым большую адаптивность. Это позволяет компонентам решения масштабироваться автономно, допускает локальные отказы без нарушения работы остальных элементов и упрощает взаимодействие.

ЯВНЫЕ ПРЕИМУЩЕСТВА

Событийно-ориентированные архитектуры особенно уместны для ситуаций с непостоянным и сложно контролируемым потоком событий внешней и внутренней среды – события в EDA порождаются, анонсируются, и для каждого предусмотрен свой обработчик, который отреагирует должным образом, не исключая вероятность генерации еще одного (уже другого) события.

Все это происходит в реальном времени, задержки могут случаться в результате ошибок в ходе обработки событий, что само по себе (ошибка) тоже является событием и может (и должно) быть обработано соответствующим компонентом решения.

В EDA производители событий (источники) не взаимодействуют напрямую с потребителями своих событий, не заботятся о последствиях и не зависят от действий потребителей. События лишь фиксируют изменения в состоянии.

Потребители (например, микросервисы внутри системы или приложения) подписываются на те события, которые находятся в зоне их ответственности, – по заданным параметрам и критериям. Добавляя новых подписчиков на такого рода событийные рассылки, можно легко добавлять новых потребителей для реализации дополнительных функций ИТ-системы без какого-либо влияния на ранее налаженные процессы. Более того, это дает большие возможности для тестирования в продуктивной среде и проверки гипотез без негативного влияния на качество.

EDA облегчает разбивку систем на компоненты – из-за слабой связанности компонентов, которую эта архитектура приносит, у разработчиков появляется возможность улучшить доступность решения.

Снижается когнитивная нагрузка, что позволяет быстрее ориентироваться в проекте.

ОРКЕСТРАЦИЯ ПРОТИВ ХОРЕОГРАФИИ

EDA, будучи примером реализации хореографического подхода, является прямой противоположностью оркестрируемых решений.

Оркестрируемые архитектуры предполагают «дирижирование» оркестром из элементов ИТ-системы, где кто-то один управляет всеми музыкантами, указывая, когда и как играть каждому из них. Аналогично в оркестрации ИТ-систем существует централизованный контроль, который диктует каждому компоненту системы, что и когда делать.

Это в какой-то мере облегчает внесение изменений, так как достаточно изменить только центральные директивы. Однако такая централизация несет в себе риск единой точки отказа: если центральный элемент управления выйдет из строя, вся система может остановиться.

В отличие от оркестрации, хореографический подход (EDA) больше похож на танцевальный ансамбль, где каждый танцор знает свои движения и взаимодействует с другими участниками без центрального руководства.

В ХОРЕОГРАФИИ ИТ-СИСТЕМ КАЖДЫЙ КОМПОНЕНТ ФУНКЦИОНИРУЕТ АВТОНОМНО И САМООРГАНИЗОВАННО, РЕАГИРУЯ НА СОБЫТИЯ ИЛИ ДЕЙСТВИЯ ДРУГИХ КОМПОНЕНТОВ

Это повышает устойчивость системы, так как нет единой точки отказа. Но такая самоорганизованность может усложнять управление системой, так как необходимо координировать множество независимых компонентов. Большинство отказов в следовании архитектуре EDA вызваны именно опасениями в сложности управления этим решением. Потребуются дополнительные усилия по классификации, ведению реестра событий, со спецификациями их форматов, генераторов и потребителей.

Резюмируя: в «оркестрах» все идет через команды, в «хореографии» – через события. Если в привычных большинству архитектурах управление выглядит как «сделай А, сделай В», то в EDA акцент делается на реакции на события: «произошло А, произошло В – вы сами знаете, что делать дальше».

В этом контексте система больше не нацелена на ожидание ответов от компонентов или внешнего окружения. Вместо этого она активно уведомляет другие части системы или окружение о произошедших изменениях или действиях.

При этом допускается комбинирование архитектур, где на верхнем уровне решения используется событийный подход, а на более низких участках обработки событий имеются решения для оркестрации.

НА ПРАКТИКЕ

Рассмотрим пример. Клиент отправляет форму через веб-интерфейс, система не ждет подтверждения или конечного ответа с результатом обработки этой формы. Вместо этого она уведомляет составляющие об этом событии, что может вызвать ряд последующих действий в других частях системы. Пользователь при этом уведомляется о том, что его обращение принято и обрабатывается.

Аналогично, когда статус какой-либо клиентской заявки меняется или поступает запрос на обслуживание, система уведомляет соответствующие компоненты или службы без ожидания их прямой ответной реакции.

Этот подход обеспечивает более быстрое и гибкое взаимодействие между элементами системы, упрощая процессы управления и реакции на изменения.

Для разных интернет-платформ критически важно поддерживать готовность к быстрому наращиванию ресурсов в случае роста активности пользователей. EDA за счет генерации цепочки событий активирует определенную последовательность независимо масштабируемых сервисов, каждый из которых выполняет отдельную функцию: от подтверждения заказа и приема оплаты до уведомления службы доставки.

Благодаря этому обеспечивается устойчивость к нагрузкам на разных участках бизнес-процессов, появляется возможности гибко настраивать производительность каждого участка.

Другой пример – при получении клиентом банковской услуги (например, кредит) банку необходимо выполнить определенные проверки, включая ряд подтверждений: личности, адреса, платежеспособности, кредитной истории. Все эти операции также могут быть организованы в виде цепочки разных событий, которые обрабатываются уполномоченными на то сервисами, при этом не будет централизованного органа управления процессом.

EDA И БУДУЩЕЕ

EDA популярна и привлекательна благодаря своей способности обеспечивать масштабируемость и гибкость ИТ-решений. Эти качества особенно ценятся в современной эпохе облачных вычислений и микросервисов, поскольку они позволяют приложениям адаптироваться к изменяющимся нагрузкам и требованиям бизнеса.

Благодаря своей реактивности и асинхронности EDA может стать неотъемлемой частью систем, требующих обработки событий в реальном времени, что находит применение в интернете вещей (IoT), финансовых технологиях и средствах обработки клиентских обращений.

Кроме того, устойчивость и отказоустойчивость становятся все более важными атрибутами современных ИТ-систем, а EDA снижает связанность между компонентами системы, что улучшает устойчивость к сбоям и обеспечивает лучшую надежность.

Источник: Rspectr.com