В отличие от локального событийного цикла внутри одного приложения, EDA описывает взаимодействие распределённых компонентов и асинхронную обработку.
С 8 октября 2026 года сервис Serverless Integrations будет закрыт.
Функциональность Workflows доступна в конструкторе платформы Yandex AI Studio, а в качестве альтернативы EventRouter используйте триггеры в Cloud Functions, Serverless Containers и API Gateway.
Событийно-ориентированная архитектура, или Event-Driven Architecture (EDA), — это подход, при котором компоненты системы обмениваются не прямыми синхронными вызовами, а событиями — сигналами об изменении состояния.
В основе EDA простая модель: один сервис публикует событие, другие его получают и выполняют нужные действия. Источник события не обязан знать, кто именно будет его обрабатывать, поэтому компоненты можно развивать и масштабировать независимо.
В прикладном контексте формулировки «событийно‑ориентированная архитектура», «событийная архитектура», Event‑Driven Architecture и EDA обозначают одну и ту же модель. Событийно‑ориентированное программирование — более широкое понятие: его могут применять внутри одного приложения наряду с другими парадигмами, например с объектно‑ориентированным программированием (ООП).
У Event-Driven-архитектуры есть несколько базовых компонентов.
При проектировании важно, какие данные несёт событие: полный набор атрибутов или только идентификатор. В первом случае уменьшается число дополнительных запросов, но контракт становится тяжелее; во втором событие легче, но потребитель сильнее зависит от внешнего источника данных.
На практике обычно используют две модели:
Монолитная архитектура строится как единое приложение с общей кодовой базой, общей серверной частью и, как правило, общей базой данных. Основные модули приложения собраны вместе, а любое изменение в одном из них затрагивает всю систему.
Главное отличие EDA от монолита — в способе связи между компонентами. В монолите модули обычно взаимодействуют напрямую и синхронно, а в событийной архитектуре компонент публикует событие и не ждёт немедленного ответа. За счёт этого систему проще расширять: можно подключать новых потребителей, не меняя источник событий.
Монолит обычно проще отлаживать на старте: весь путь запроса виден внутри одного приложения. В EDA, особенно если система построена на микросервисах, этот путь распределён между очередями, поэтому здесь особенно важны трассировка, метрики и централизованная работа с ошибками.
Рассмотрим базовый сценарий:
OrderCreated.Каждый потребитель выполняет только свою часть работы.
В статье на Хабре мы рассматривали автоматизацию ухода сотрудника в отпуск как последовательность событий и действий: нужно создать заявление, проверить доступные дни, согласовать отпуск, передать данные в бухгалтерию и перестроить связанные процессы. На этом примере мы сравнивали два паттерна EDA — хореографию, где сервисы сами обмениваются событиями, и оркестрацию, где их взаимодействием управляет центральный компонент. Это показывает, что событийно-ориентированная архитектура допускает разные способы организации одного и того же процесса.
Свойство операции, при котором повторное выполнение даёт тот же результат, что и первое.
Дальше включается операционная логика: события могут буферизоваться в очереди, маршрутизироваться по правилам, повторно обрабатываться при сбоях и отправляться в отдельные каналы ошибок. Microsoft относит к типовым вызовам такой архитектуры гарантированную доставку и согласованность в конечном счёте, а RabbitMQ™ документирует механизм обменника недоставленных сообщений (dead letter exchange) для повторной маршрутизации проблемных сообщений.
Из этого следует важный вывод: event-driven-подход не сводится к установке брокера. Это архитектурный выбор, который требует дисциплины в обработке ошибок, идемпотентности и наблюдаемости.
Ключевые преимущества EDA связаны с гибкостью, масштабируемостью и скоростью реакции системы на события:
Для бизнес-процессов это означает более быстрые реакции: уведомления, аналитика, обработка заказов, антифрод и автоматизация рабочих процессов — всё это событийная технология запускает сразу после события.
Но у EDA есть и недостатки, в первую очередь связанные со сложностью реализации и особенностями работы распределённых систем:
Для отладки EDA одних логов обычно недостаточно: в распределённой системе важно видеть полный путь события через разные компоненты. Поэтому на практике используют метрики, централизованные логи и инструменты трассировки.
Для работы с метриками часто применяют Prometheus® и совместимые с ним решения. Prometheus — система мониторинга с открытым исходным кодом и база данных временных рядов, которая позволяет собирать, хранить и запрашивать метрики, а также настраивать оповещения. В Yandex Cloud для таких задач доступен Yandex Managed Service for Prometheus®.
Для логов важна централизованная агрегация и быстрый поиск по сообщениям из разных сервисов. Эту задачу решает Yandex Monium Logs — распределённая и высокодоступная система для хранения, поиска, визуализации и анализа логов пользовательских приложений и ресурсов Yandex Cloud.
Для трассировки ключевой принцип один: у события, сообщения или операции должен быть контекст, который можно передать через producer, broker и consumer. Иначе отладка превращается в разбор разрозненных записей без общей картины. В событийной архитектуре это уже не дополнительное удобство, а важная часть эксплуатации. Для этого существует Yandex Monium Traces, который позволяет собирать, хранить и визуализировать трейсы, чтобы видеть путь запроса через распределённую систему.
Один из распространённых сценариев для событийно‑ориентированной архитектуры — процессы в электронной коммерции. При оформлении заказа событие о его создании запускает несколько независимых обработчиков: они подтверждают оплату, обновляют остатки, отправляют уведомления и передают данные в аналитику. Так сервисы распределяют ответственность без жёстких синхронных вызовов.
Ещё один сценарий — обработка данных в реальном времени: поток событий от приложений, устройств или систем анализируется сразу после поступления. Это критично там, где нужна быстрая реакция, — например, при обработке телеметрии или сигналов о состоянии инфраструктуры.
Третий сценарий — мониторинг и оповещения. Система реагирует на изменения метрик, задержек или статусов через события, а не за счёт постоянного опроса ресурсов. В Yandex Monium можно настраивать алерты и отправку уведомлений, а для логов использовать уже упомянутый Yandex Monium Logs. Это делает событийную модель удобной как для бизнес‑процессов, так и для эксплуатации приложений и облачной инфраструктуры.
Для реализации EDA нужен целый набор технологий: средства приёма событий, транспорт для асинхронной доставки сообщений, компоненты обработки, а также инструменты оркестрации и маршрутизации. Выбор зависит от сценария: требуется ли обмен между двумя компонентами, модель публикации и подписки с одним источником и несколькими получателями, потоковая обработка, хранение состояния или координация бизнес‑процессов.
Обычно событийная архитектура строится из нескольких слоёв. На входе — приём внешних событий через API‑шлюзы. В Yandex Cloud эту задачу решает Yandex API Gateway: он публикует единый API для фронтенда и внешних систем и передаёт запросы во внутренние бессерверные компоненты.
Для асинхронной доставки сообщений между сервисами применяют очереди. Сервис Yandex Message Queue помогает развязать источник события и получателя, убрать жёсткую синхронную зависимость и организовать фоновую обработку. Реакцию на события и выполнение бизнес‑логики обеспечивают Yandex Cloud Functions и Yandex Serverless Containers. Первый сервис подходит для небольших обработчиков и микросервисов, второй — для случаев, когда приложению нужно гибкое окружение с зависимостями.
Чтобы автоматизировать запуск обработчиков, используют триггеры. Они переводят модель с опросом (pull) в модель доставки (push): получают сообщение из очереди, расписания или хранилища и сразу запускают нужную функцию. Это уменьшает объём служебного кода и упрощает типовые сценарии обработки.
Если событие должно доставляться сразу нескольким получателям, задействуют шины событий. В Yandex Cloud для этого подходит Yandex Data Streams — сервис для работы с потоками данных в реальном времени, включая поток событий (event streaming) и пакетную обработку (batch processing).
Важный элемент EDA — хранение состояния. Для сохранения актуальных данных, результатов обработки и информации для других сервисов можно использовать YDB в бессерверном режиме. Это особенно важно для сложных паттернов, например при фиксировании изменений состояния как последовательности событий (event sourcing) и разделении операций записи и чтения (CQRS). Механизм отслеживания изменений в данных (Change Data Capture) дополняет решение: он автоматически превращает изменения в базе в поток событий, сокращая объём интеграционного кода.
Когда архитектура выходит за рамки простой доставки сообщений, нужны инструменты более высокого уровня. Для управления последовательностью шагов (например, проверка заказа, запуск оплаты и обработка результата) применяют оркестрацию — в Yandex Cloud с этим справляется Yandex Workflows — компонент сервиса Yandex Serverless Integrations. Если же система строится без единого управляющего центра и несколько сервисов должны независимо реагировать на события друг друга, важнее хореография. Здесь помогает компонент EventRouter: он маршрутизирует сообщения подписчикам по заданным правилам, позволяя одному событию запускать реакции сразу в нескольких подсистемах.
На практике инструменты EDA редко используют по отдельности — их объединяют в единую цепочку обработки событий. Чем сложнее бизнес‑сценарий, тем важнее, чтобы компоненты работали как целостная платформа, а не как набор разрозненных интеграций.
В этой статье: