Определение ориентированной на события архитектуры и ее значение

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

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

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

Что такое событие?

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

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

• Платеж не выполнен или выполнен успешно
• Пользователь входит в систему или выходит из нее
• Запас опускается ниже порогового значения
• Отправка отправляется со склада или прибывает в место назначения
• Нарушение безопасности инициирует предупреждение
• Программа лояльности обновляет баланс баллов
• Группа поддержки создает сервисный запрос
• Клиент обновляет свой адрес доставки
• Новый пользователь создает учетную запись
• Покупатель отправляет отзыв на продукт
• Подписчик обновляет или отменяет подписку

Основные компоненты управляемой событиями архитектуры

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

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

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

В очень простой архитектуре с одним производителем и одним потребителем в прямой коммуникации друг с другом, брокеры событий могут быть необязательными. Однако на большинстве предприятий несколько источников рассылают события нескольким потребителям, поэтому необходим брокер или даже сеть брокеров, также известная как «сетка событий». При использовании Event Broker или Event Mesh создается "свободная связь" приложений.

Синхронная и асинхронная коммуникация

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

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

Модели на основе запросов и событий в управляемой событиями архитектуре

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

В управляемой событиями модели взаимодействие начинается с события – изменения состояния или действия, инициирующего обработку, – и компоненты автоматически реагируют при возникновении событий, например, публикация/подписка. Эта модель имеет характерную функцию push-передачи, то есть система автоматически отправляет ("передает") события или обновления потребителям сразу после их возникновения, не дожидаясь, когда потребитель запросит их. Модели на основе событий являются асинхронными, разъединенными и идеально подходят для реагирования в реальном времени.

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

Общие модели управляемой событиями архитектуры

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

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

• Публикация/подписка (т. е. «pub/sub»): потребители событий подписываются на сообщения и каналы, опубликованные производителями событий. При публикации события оно отправляется напрямую всем подписчикам с помощью брокера событий. Во избежание дублирования нельзя воспроизвести события или получить к ним доступ после потребления, так как их удаляет брокер.
• Потоковая передача событий: с помощью потоковой передачи событий производители публикуют целые потоки событий для брокера. Потребители подписываются на поток и могут считывать его из любой его части, потребляя только релевантные для него события. При потоковой передаче событий события сохраняются брокером даже после их потребления.
• Сегрегация ответственности за запросы команд (CQRS): с шаблоном CQRS уровень дизайна и архитектуры приложения разделяет операции чтения и записи по разным моделям. Команды обновляют состояние при чтении запросов. В управляемой событиями архитектуре шаблон CQRS часто работает с событиями для асинхронного распространения изменений, что повышает масштабируемость и производительность сложных систем.
• Выбор источника поставки для события: при выборе источника поставки система записывает каждое изменение состояния как событие в журнал только с приложением, а не сохраняет только текущее состояние сущности. Текущее состояние можно перестроить, воспроизведя эти события. Это обеспечивает полный контрольный журнал и поддерживает сценарии командировок и восстановления во времени.

Стили обработки событий

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

1. Простая обработка событий: потребители обрабатывают каждое событие по мере его получения. Примеры:

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

2. Обработка сложных событий. Потребители обрабатывают ряд событий для выявления закономерностей и выполнения действий на основе результата. Примеры:

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

3. Обработка потока событий: потребители обрабатывают и действуют в постоянном потоке данных (данные в движении) в реальном времени с помощью платформы потоковой передачи данных. Примеры:

• Колебания цены акций стимулируют мгновенную торговлю на основе предварительно определенных правил.
• Всплывающие социальные сети упоминают обновления информационных панелей настроений «на лету».
• Телеметрия с подключенных транспортных средств динамически корректирует сигналы трафика.
• Данные потока кликов с сайта электронной коммерции дают рекомендации по продуктам в реальном времени.

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

Как работает управляемая событиями архитектура

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

Ниже пошагово показано, как работает управляемая событиями архитектура:

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

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

Сценарии использования и реальные примеры

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

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

Ресторанная промышленность

1. Студент колледжа размещает заказ на пиццу с помощью приложения для доставки еды. Приложение собирает его основную информацию — имя, адрес, платежную информацию и заказ — и публикует событие «Заказ пиццы».
2. Ресторан пиццы подписывается на мероприятие, выполняет заказ и публикует собственное мероприятие «заказ готов» обратно в службу доставки еды.
3. Затем сервис присваивает водителя поставки, планирует предполагаемое время прибытия и предупреждает клиента о том, что его круговая диаграмма в пути.

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

1. Онлайн-покупатель вводит данные своей кредитной карты на сайте электронной коммерции, который публикует событие «оплата отправлена».
2. Платежная система подписывается на событие, обрабатывает платеж и выдает собственное событие "Платеж обработан", указывающее на успех или сбой, и направляет его обратно в пользовательский интерфейс веб-сайта.
3. В пользовательском интерфейсе отображается статус платежа для клиента и запрашиваются следующие шаги.

Некоторые другие примеры управляемой событиями архитектуры:

телеметрия IoT

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

Аналитика и анализ событий

• Розничный торговец анализирует данные потока перемещения по сайту в реальном времени для персонализации рекомендаций по продуктам.
• Банк отслеживает модели транзакций для выявления мошенничества до того, как это произойдет.
• Логистическая компания использует потоковые данные для прогнозирования задержек поставок и перенаправления отгрузок.

Автоматизация

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

Финансовые операции

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

Цепочка поставок

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

Модернизация ИТ и разъединение старых систем

• Компания выгружает работу из своего мэйнфрейма, публикуя бизнес-события в современных облачных сервисах для ключевых функций.
• Организация предоставляет интерфейс реального времени для событий, связанных со старой системой ERP, чтобы новые приложения могли мгновенно реагировать, не затрагивая бэкэнд.
• Бизнес-события из старой системы CRM отражаются на современной платформе SaaS, обеспечивая синхронизацию обеих систем во время постепенной миграции.

Уведомления

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

Общие сценарии использования управляемой событиями архитектуры:

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

Преимущества управляемой событиями архитектуры

Организации могут применять преимущества управляемой событиями архитектуры к своим современным системам. Основные преимущества управляемой событиями архитектуры:

1. Скорость реагирования в реальном времени и интеллектуальные потоки операций. Управляемая событиями архитектура позволяет системам мгновенно реагировать на события по мере их возникновения, инициируя автоматизированные потоки операций и решения в реальном времени. Это особенно важно в периоды пиковой нагрузки, например, во время крупных мероприятий по продажам или праздничных дней. Организации могут применять эту скорость реагирования к повседневным операциям, улучшая все процессы — от автоматизации цепочки поставок и выявления мошенничества до персонализированного взаимодействия с клиентами.
2. Скорость и эффективность с помощью асинхронной коммуникации: Приложения в управляемой событиями архитектуре взаимодействуют асинхронно, то есть производители публикуют сообщения о событиях, не дожидаясь их получения потребителями. Такой подход без блокировки повышает производительность, сокращает задержки и позволяет системам обрабатывать огромные объемы событий без узких мест.
3. Гибкость и масштабируемость благодаря разъединению и свободному соединению: компоненты в управляемой событиями архитектуре разъединены или слабо связаны, поэтому они работают независимо, не полагаясь на доступность друг друга или внутреннюю логику. Это упрощает обновление, тестирование и развертывание сервисов без прерывания работы всей системы. Разъединение также упрощает добавление дополнительных производителей и потребителей по мере необходимости, обеспечивая беспрепятственное масштабирование по мере роста бизнес-потребностей.
4. Устойчивость и изоляция отказов: при разъединении сервисов сбои в одном компоненте не каскадируются по всей системе. Каждая услуга может завершиться неудачей независимо, что делает архитектуру более прочной и отказоустойчивой, чем традиционные тесно связанные модели.
5. Готовая к будущему интеграция: слабая связь и асинхронный дизайн делают управляемую событиями архитектуру идеальной для модернизации ИТ, разъединения устаревших систем и мультиоблачных операций. Организации получают гибкость для интеграции новых технологий, таких как автоматизация на основе ИИ и аналитика событий, не переписывая основные системы.

Проблемы, ограничения и передовые практики

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

Проблемы

• Сложность распределенных систем: управление сеткой брокеров событий в различных средах создает архитектурную сложность. Проектирование потоков событий, обеспечение непротиворечивости схем и обработка асинхронной коммуникации требуют расширенного планирования и опыта. Без надлежащего контроля над дизайном организации могут столкнуться с хаосом событий по мере роста объемов событий, производителей и потребителей.
• Управление и соблюдение нормативных требований. События, происходящие в гибридных и мультиоблачных средах, усложняют соблюдение политик управления, таких как конфиденциальность данных, безопасность и соблюдение нормативных требований. Организациям необходимы надежные структуры управления для предотвращения утечек данных и несанкционированного доступа, а также контроля над быстро расширяющимися ландшафтами событий.
• Отладка и наблюдательность: Устранение неполадок в асинхронной, слабо связанной системе сложнее, чем в традиционных архитектурах. Для выявления основных причин отказов или задержек требуются расширенные возможности мониторинга, трассировки и воспроизведения событий. Это особенно актуально, когда группы устраняют проблемы, возникающие в сложных цепочках событий, или устраняют симптомы хаоса событий.

Как сетка событий вписывается в

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

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

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

Ограничения управляемой событиями архитектуры

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

Лучшие практики в области архитектуры, ориентированной на события

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

Характеристики управляемой событиями архитектуры

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

• Асинхронная коммуникация: основополагающая характеристика событийной архитектуры. Вместо того, чтобы ждать прямого ответа, как в традиционных моделях на основе запросов, приложения публикуют события и продолжают работать без задержек. Этот неблокирующий стиль обеспечивает взаимодействие в реальном времени в распределенных системах и повышает скорость реагирования даже при большой нагрузке.
• Слабая связь. Приложениям не нужно знать доступность друг друга, структуру API или внутреннюю логику; они просто взаимодействуют через события, маршрутизируемые брокером событий или сеткой событий. Обеспечивая независимое функционирование производителей и потребителей событий, команды могут добавлять, обновлять или заменять услуги, не нарушая более широкую систему, повышая гибкость и отказоустойчивость.
• Независимое масштабирование: поскольку компоненты разъединены, отдельные сервисы могут масштабироваться в зависимости от потребности, не требуя изменений в предшествующих или последующих приложениях. SAP выделяет это как основное преимущество интеграции на основе событий, особенно в гибридных и мультиоблачных средах, где необходимо эффективно управлять пиковой нагрузкой и распределенной рабочей нагрузкой.

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

Часто задаваемые вопросы