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