Управляемая событиями архитектура включает поставщики событий, которые создают потоки событий, и потребители событий, которые прослушивают эти события.
События доставляются практически мгновенно, что позволяет потребителям немедленно реагировать на происходящие события. Производители отделены от потребителей - производитель не знает, какие потребители слушают. Потребители также не зависят друг от друга, и каждый из них получает все события. Это важное отличие от шаблона конкурирующих клиентов, в котором пользователи извлекают сообщения из очереди, и каждое сообщение обрабатывается только один раз (если не возникает ошибок). В некоторых системах, таких как Интернет вещей, события обрабатываются в огромных объемах.
Архитектура на основе событий может использовать модель публикации и подписки (также называемая pub/sub) или моделью потока событий.
Публикация и подписка. Инфраструктура обмена сообщениями поддерживает список подписок. Каждое публикуемое событие отправляется каждому подписчику. После получения события его нельзя воспроизвести, а новые подписчики не видят события.
Потоковая передача событий. Все события записываются в журнал. События в пределах каждой секции строго упорядочены и сохраняются в течение долгого времени. Клиенты не подписываются на поток, а просто считывают события из любой его части. Каждый клиент самостоятельно управляет своим положением в потоке. Это означает, что клиент может подключиться в любое время и (или) прослушать события повторно.
На стороне получателя есть несколько распространенных вариантов реализации.
Обработка простых событий. Каждое событие немедленно запускает действие в объекте-получателе. Например, в Функциях Azure можно создать триггер служебной шины, который будет выполнять некоторую функцию при каждой публикации сообщения в определенном разделе служебной шины.
Базовая корреляция событий. Потребитель должен обрабатывать небольшое количество дискретных бизнес-событий, обычно сопоставленных с некоторым идентификатором, сохраняя некоторые сведения из предыдущих событий для использования при обработке последующих событий. Этот шаблон поддерживается библиотеками, такими как NServiceBus и MassTransit.
Обработка сложных событий. Потребитель обрабатывает ряд событий, ищет шаблоны в данных о событиях, используя технологию, например Azure Stream Analytics. Например, можно выполнять статистическую обработку показаний встроенного устройства за некоторый период времени, чтобы создавать уведомления, когда скользящее среднее значение выходит за определенные пороговые значения.
Обработка потока событий. Платформу потоковой передачи данных, например Центр Интернета вещей Azure или Apache Kafka, можно использовать как конвейер для приема событий и передачи их в обработчики потоков. Обработчики потоков определенным образом реагируют на эти процессы или преобразовывают поток. Может существовать несколько обработчиков потока для разных подсистем приложения. Такой подход хорошо подходит для рабочих нагрузок Интернета вещей.
Источник событий может находиться за пределами системы, например это могут быть физические устройства в решении Интернета вещей. В такой ситуации система должна поддерживать прием данных в таких объемах и на такой скорости, которые соответствуют характеристикам источника данных.
На представленной выше логической схеме каждый тип потребителя обозначен отдельным блоком. На практике обычно используется несколько экземпляров каждого поставщика, чтобы они не становились единой точкой отказа. Наличие нескольких экземпляров также может требоваться для обработки событий в нужных объемах и (или) с нужной скоростью. Кроме того, каждый объект-получатель может обрабатывать события в нескольких потоках. Это может создать проблемы, если события должны обрабатываться в порядке или требовать точно один раз семантики. См. руководство по минимизации координации.
Когда следует использовать эту архитектуру
- Для обработки одних и тех же событий несколькими подсистемами.
- Для обработки в режиме реального времени, с минимальными задержками.
- Для обработки сложных событий, например сопоставления шаблонов или статистической обработки за некоторый период.
- При больших объемах и скоростях поступления данных, например в Интернете вещей.
Льготы
- Отправители и получатели независимы друг от друга.
- Нет точек интеграции. Очень легко добавлять в систему новые объекты-получатели.
- Объекты-получатели могут реагировать на события сразу при их поступлении.
- Высокая масштабируемость и распределение.
- Подсистемы получают независимые представления потока событий.
Сложности
- Гарантированная доставка. В некоторых системах, особенно в среде Интернета вещей, важно гарантировать доставку событий.
- Обработка событий в строгом порядке и (или) строго один раз. Каждый тип потребителя обычно выполняется на нескольких экземплярах, чтобы обеспечить надежность и масштабируемость. Это может создать проблему, если события должны обрабатываться в порядке (в типе потребителя) или не реализована логика обработки идемпотентных сообщений.
- Координация сообщений между службами. Бизнес-процессы часто включают в себя публикацию и подписку на сообщения нескольких служб для достижения согласованного результата для всей рабочей нагрузки. Такие шаблоны рабочих процессов, как шаблон хореографии и оркестрация Saga, можно использовать для надежного управления потоками сообщений между различными службами.
Дополнительные рекомендации
- Объем данных, включаемых в событие, может быть значительным фактором, который влияет как на производительность, так и на затраты. Размещение всех соответствующих сведений, необходимых для обработки в самом событии, может упростить код обработки и сохранить дополнительные подстановки. Размещение минимального объема информации в событии, как и всего несколько идентификаторов, уменьшит время транспорта и затраты, но требует, чтобы код обработки искал дополнительную информацию, необходимую ему. Дополнительные сведения об этом см. в этой записи блога.
- Хотя запрос виден только компоненту обработки запросов, события часто видны нескольким компонентам в рабочей нагрузке, даже если эти компоненты не предназначены для их использования. Работа с "предполагать нарушение" мышления, помните о том, какая информация, которую вы включаете в события, чтобы предотвратить непреднамеренное воздействие информации.
Связанные ресурсы
- Обсуждение сообщества видео о рекомендациях по выбору между хореографией и оркестрацией.