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. Выводы
- Событийная архитектура использует события для запуска и обмена данными между разделенными службами и является обычным явлением в современных приложениях, созданных с использованием микросервисов.
- Событийная архитектура имеет следующие ключевые компоненты: генераторы событий, каналы событий, начальные события и события обработки, маршрутизаторы событий и потребители событий.
- Событийная архитектура хорошо масштабируется, легко модифицируется и обладает высокой производительностью благодаря своей асинхронной природе, но шаблон имеет высокую сложность разработки и его непросто тестировать.
- Варианты использования событийной архитектуры включают репликацию данных между учетными записями и между регионами; разветвление и параллельная обработка; мониторинг состояния ресурсов и оповещение; интеграция разнородных систем.