Что такое событийная (Event Driven) архитектура

1. Что такое событийная архитектура

Шаблон управляемой событиями архитектуры (событийная архитектура, event-driven architecture, EDA) — это популярный шаблон распределенной асинхронной архитектуры, используемый для создания масштабируемых приложений. EDA состоит из разделенных одноцелевых компонентов, которые асинхронно получают и обрабатывают события.

2. Пример

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

Пример событийной архитектуры для сайта электронной коммерции. (1) — Продюсеры событий; (2) — Начальные события; (3) — Маршрутизаторы событий; (4) — События обработки; (5) — Потребители событий.

3. Компоненты

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

3.1 Продюсеры мероприятий

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

3.2 События

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

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

Событие обычно состоит из двух частей: 1) заголовок события включает такую ​​информацию, как имя события, отметка времени и тип события; 2) тело события предоставляет подробную информацию об обнаруженном изменении состояния.

3.3 Каналы

И начальные, и события обработки доставляются по каналам событий.

Первоначальные каналы событий могут быть TCP/IP-соединением или файлом (XML, JSON, электронная почта и т.д). Одновременно можно открыть несколько исходных каналов событий. Они читаются асинхронно, что позволяет обрабатывать события почти в реальном времени. События хранятся в очереди, ожидая последующей обработки маршрутизатором событий.

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

3.4 Маршрутизатор событий

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

Маршрутизатор событий также может запускать ряд утверждений. Например, если событие, которое поступает в механизм обработки событий, является идентификатором продукта, запас которого на складе ограничен, это может вызвать такие реакции, как «Заказать продукт» и «Уведомить персонал».

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

3.5 Потребители событий

В этом примере потребители событий представлены управленческой базой данных, финансовой системой и отделом по работе с клиентами.

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

4. Анализ шаблона

4.1 Масштабируемость: высокая

Каждый потребитель событий может масштабироваться отдельно, что обеспечивает точную масштабируемость.

4.2 Сложность разработки: высокая

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

4.3 Производительность: высокая

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

4.4 Тестируемость: низкая

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

4.5 Модифицируемость: высокая

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

5. Событийная архитектура: примеры использования

5.1 Репликация данных между аккаунтами и регионами

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

5.2 Разветвление и параллельная обработка

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

5.3 Мониторинг состояния ресурсов и оповещение

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

5.4 Интеграция гетерогенных систем

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

6. Выводы

1. Событийная архитектура использует события для запуска и обмена данными между разделенными службами и является обычным явлением в современных приложениях, созданных с использованием микросервисов.
2. Событийная архитектура имеет следующие ключевые компоненты: генераторы событий, каналы событий, начальные события и события обработки, маршрутизаторы событий и потребители событий.
3. Событийная архитектура хорошо масштабируется, легко модифицируется и обладает высокой производительностью благодаря своей асинхронной природе, но шаблон имеет высокую сложность разработки и его непросто тестировать.
4. Варианты использования событийной архитектуры включают репликацию данных между учетными записями и между регионами; разветвление и параллельная обработка; мониторинг состояния ресурсов и оповещение; интеграция разнородных систем.

Что еще почитать

• Программные архитектуры
• Что такое Event-Driven Architecture?
• Event-driven architecture

Источник