Игра Яндекс Практикума
Игра Яндекс Практикума
Игра Яндекс Практикума

Event-Driven архитектура: принципы и примеры использования

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

382 открытий2К показов
Event-Driven архитектура: принципы и примеры использования

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

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

Узнаем, каковы принципы и основы событийной архитектуры ПО, каковы преимущества и недостатки такой структуры, как работает EDA на конкретных примерах.

Принципы событийной архитектуры и ее компоненты

Event-Driven Architecture — это распространенный асинхронный шаблон, в котором основной для системных действий становится реакция на какое-либо событие. Здесь событием называют сообщение в разных точках исполняемого кода, возникающее при выполнении ряда условий. Паттерн EDA используется при разработке приложений с высокой масштабируемостью, а также при создании более простых программных продуктов.

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

Как работает EDA

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

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

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

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

В EDA производители и потребители сообщений не связаны напрямую. То есть продюсеры не знают, какие получатели принимают события, и наоборот — пользователям неизвестно, кто генерирует сообщения. Благодаря разделению можно автономно обновлять, масштабировать и всячески развивать проект.

Путь сообщений от точки приема до получателей бывает довольно извилистым — возможно, событию потребуется взаимодействовать с компонентами, написанными на другом языке, использующими другие интерфейсы и протоколы передачи. Используется два распространенных способа доставки данных — pub/sub и стандартная потоковая передача. В первом случае инфраструктура такова, что сообщения получает каждый подписчик, во втором события заносятся в лог, после чего потребители могут воспринимать их из любого участка потока.

Для современного ПО со сложными и разветвленными рабочими процессами принцип Event-Driven обеспечивает необходимую масштабируемость и гибкость. Полноценная обработка здесь и сейчас — это быстродействие и надежность, то есть основные требования, которые предъявляют пользователи к современному ПО.

Преимущества

Шаблон EDA имеет большой список плюсов:

  • Высокая масштабируемость. Отсутствие связанности компонентов обеспечивает масштабируемость системы при необходимости. Например, если в онлайн-магазине значительно повышается спрос на товары, архитектура легко справится с обработкой, не задействуя другие службы. 
  • Асинхронная связь. Архитектура работает по принципу асинхронной связи компонентов — то есть части системы включаются, не дожидаясь взаимных ответов. Параллельная обработка существенно повышает эффективность программных продуктов.  
  • Надежность (отказоустойчивость). В EDA системах минимум зависимостей между элементами, что повышает отказоустойчивость. Если с одним из элементов случится сбой, система продолжит работать с минимальными нарушениями. Брокеры позаботятся о том, чтобы события не были потеряны в процессе сбоя. Событийно-ориентированная коммутация позволяет хранить сообщения в специальном хранилище, где ошибки будут обработаны. 
  • Быстродействие приложений. Поскольку события обрабатываются асинхронно и в режиме онлайн, это обеспечивает высокую скорость реагирования на сообщения. В EDA-структурах компоненты отвечают на изменение статуса кода сразу, что максимально сокращает время между действиями и их обработкой. По этой причине событийная архитектура — идеальный вариант для ПО, где мгновенная обработка данных и оперативное реагирование критично важны, например, на финансовых платформах.
  • Бесшовная интеграция. Программы с архитектурой EDA легко интегрируются с другими приложениями для обмена сведениями и прочих взаимодействий. События потребляются и создаются независимо от задействованных языков программирования и технологических решений. 
  • Гибкость. Event-Driven предполагает модульный подход к разработке системы. Это значит, что изменение отдельных компонентов практически не влияет на статус всей системы. Повышается скорость реагирования на новые задачи и потребности, улучшается адаптивность, что сокращает период разработки и программные ресурсы. 

Таким образом, продукты с EDA высокопроизводительны и способны параллельно выполнять операции с минимальными затратами.

Примеры использования Event-Driven архитектуры

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

Электронная коммерция

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

Интернет вещей

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

Регистрация и верификация пользователей

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

Системы оповещения

В таких программных продуктах запуск событий происходит при конкретных условиях — рассылка сообщений, назначение задач в рабочих пространствах, почтовые и push уведомления.

Аналитика

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

Управление рабочими процессами

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

Микросервисы

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

Реальные примеры

Многие компании с международным статусом внедрили в свои ресурсы системы архитектуры EDA, чтобы обеспечить масштабируемость и гибкость программных продуктов.

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

Еще один пример EDA — платформа для заказа автомобильных поездок Uber. События в этой системе представлены изменениями геолокации, что позволяет операторам отслеживать местоположение тысяч водителей одновременно.

Технологии для реализации EDA

Для реализации EDA применяется несколько технологий. Обозначим наиболее значимые из них.

Event Sourcing

В переводе с английского — «поиск событий». Этот шаблон документирует все изменения статуса системы в виде набора упорядоченных событий. Взамен обновления статуса данных система фиксирует изменения как определенные события.

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

CQRS

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

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

Message Broker

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

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

Вызовы и недостатки EDA

Поскольку в ИТ-сфере (как и в других отраслях) нет ничего совершенного, у EDA есть свои недостатки и подводные камни. Рассмотрим их подробно.

Сложная структура

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

Согласованность событий

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

Порядок событий

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

Управление и мониторинг

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

Итоги

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

Сталкивались с EDA? 
Да, использую в проекте
Нет, никогда

И обязательно рассказывайте в комментариях, где применяете event-driven архитектуру.

Следите за новыми постами
Следите за новыми постами по любимым темам
382 открытий2К показов