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