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

Управляемая событиями архитектура включает поставщики событий, которые создают потоки событий, и потребители событий, которые прослушивают эти события.

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

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

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

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

На стороне получателя есть несколько распространенных вариантов реализации.

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

• Обработка сложных событий. Объект-получатель обрабатывает последовательность событий и отслеживает в них определенные закономерности с помощью некоторого технологического решения, например Azure Stream Analytics или Apache Storm. Например, можно выполнять статистическую обработку показаний встроенного устройства за некоторый период времени, чтобы создавать уведомления, когда скользящее среднее значение выходит за определенные пороговые значения.

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

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

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

Когда следует использовать эту архитектуру

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

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

• Отправители и получатели независимы друг от друга.
• Нет интеграции «точка — точка». Очень легко добавлять в систему новые объекты-получатели.
• Объекты-получатели могут реагировать на события сразу при их поступлении.
• Высокая масштабируемость и распределение.
• Подсистемы получают независимые представления потока событий.

Сложности

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