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

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

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

Продюсер событий (генератор)

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

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

Канал событий

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

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

Механизм обработки событий

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

Нисходящая активность, управляемая событиями

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

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

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

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

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

Обработка потока событий

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

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

Комплексная обработка событий

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

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

Обрабатывая большое количество простых событий из разных источников, CEP может обнаруживать закономерности и делать выводы о сложных событиях. Затем система анализирует эти события, чтобы определить наилучшие ответные действия. Например, платежная платформа может использовать CEP для выявления мошеннических действий среди сотен и тысяч платежных событий, получаемых каждый час.

Разница между КЭП и ЭСП

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

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

Веб-сокет

Веб-сокеты — это двунаправленный протокол, используемый для установления связи между сервером и веб-браузером. Он обеспечивает полнодуплексную связь по одному протоколу управления передачей (TCP) и поддерживается современными веб-браузерами.

Событие, отправленное сервером (SSE)

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

Вебхук

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

Рекомендации

⁃ Архитектура, управляемая событиями — Wikipedia— (https://en.wikipedia.org/wiki/Event-driven_architecture)

⁃ Общие термины и полезные инструменты в архитектуре, управляемой событиями — 25 мая 2022 г. — Аллан Денис — (https://www.gravitee.io/blog/common- термины-инструменты-эда)

⁃ Архитектура, управляемая событиями — 15 февраля 2022 г. — Стивен Роддевиг — (https://blog.hubspot.com/website/event-driven-architecture)

⁃ Понимание архитектуры, управляемой событиями — 3 сентября 2019 г. — Лахвиндер Кумар — (https://softobiz.com/understanding-the-event-driven-architecture/ #:~:text=Event%20Flow%20Layers, произведено%20%20продюсером%20event%20.)

⁃ Подходы к обработке событий в архитектуре, управляемой событиями — 20 сентября 2021 г. — 3Pillar Global — (https://www.3pillarglobal.com/insights/event-processing- подходы к архитектуре, управляемой событиями/