Стиль архитектуры на основе событий

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

Architecture

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

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

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

• Публикация-подписка: Инфраструктура обмена сообщениями публикации отслеживает подписки. При публикации события оно отправляет событие каждому подписчику. После доставки события его нельзя воспроизвести, а новые подписчики не видят события. Мы рекомендуем использовать Службу "Сетка событий Azure " для сценариев публикации и подписки.

• Потоковая передача событий: События записываются в журнал. События строго упорядочены внутри секции и являются устойчивыми. Клиенты не подписываются на поток. Вместо этого клиент может читать из любой части потока. Клиент отвечает за продвижение своей позиции в потоке, что означает, что клиент может присоединяться в любое время и может воспроизводить события. Центры событий Azure предназначены для потоковой передачи событий высокой пропускной способности.

На стороне потребителя существуют некоторые распространенные варианты:

• Простая обработка событий: Событие немедленно активирует действие в потребителе. Например, функции Azure можно использовать с триггером сетки событий или триггером служебной шины Azure , чтобы код выполнялось при публикации сообщения.

• Базовая корреляция событий: Потребитель обрабатывает несколько дискретных бизнес-событий, сопоставляет их идентификатором и сохраняет информацию из предыдущих событий для использования при обработке последующих событий. Библиотеки, такие как NServiceBus и MassTransit , поддерживают этот шаблон.

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

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

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

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

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

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

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

Существует две основные топологии во многих архитектурах на основе событий:

• Топология брокера: Компоненты транслируют события всей системы. Другие компоненты либо действуют над событием, либо игнорируют событие. Эта топология полезна, если поток обработки событий относительно прост. Нет централизованной координации или оркестрации, поэтому эта топология может быть динамической.

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

• Топология посредника: Эта топология устраняет некоторые недостатки топологии брокера. Существует посредник событий, который управляет и управляет потоком событий. Посредник событий поддерживает состояние и управляет возможностями обработки ошибок и перезапуска. В отличие от топологии брокера, компоненты в топологии посредника широковещательные вхождения в виде команд и только для назначенных каналов. Эти каналы часто являются очередями сообщений. Ожидается, что потребители обработают эти команды.

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

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

Эту архитектуру следует использовать при выполнении следующих условий:

• Несколько подсистем должны обрабатывать одни и те же события.

• Требуется обработка в режиме реального времени с минимальным временем задержки.

• Требуется сложная обработка событий, например сопоставление шаблонов или агрегирование с течением времени.

• Требуется высокий объем и высокая скорость данных, например с Помощью Интернета вещей.

• Необходимо отделить производителей и потребителей для независимых целей масштабируемости и надежности.

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

Эта архитектура обеспечивает следующие преимущества:

• Производители и потребители отделены.
• Нет точек интеграции. Легко добавить новых потребителей в систему.
• Потребители могут немедленно реагировать на события по мере их возникновения.
• Это высокомасштабируемая, эластичная и распределенная.
• Подсистемы имеют независимые представления потока событий.

Сложности

• Гарантированная доставка

  В некоторых системах, особенно в сценариях Интернета вещей, важно гарантировать доставку событий.

• Обработка событий в порядке или только один раз

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

• Координация сообщений между службами

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

• Обработка ошибок

  Архитектура на основе событий в основном зависит от асинхронного взаимодействия. Распространенная проблема, которая представляет асинхронное взаимодействие, — обработка ошибок. Одним из способов решения этой проблемы является использование выделенного обработчика ошибок.

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

• Потеря данных

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

• Реализация традиционного шаблона ответа на запрос

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

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

• Обслуживание соответствующего количества событий

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

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

Другие вопросы

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

• Запрос отображается только компоненту обработки запросов. Но события часто видны нескольким компонентам рабочей нагрузки, даже если эти компоненты не используют их или не предназначены для их использования. Чтобы работать с "предполагать нарушение" мышления, помните о том, какие сведения вы включаете в события, чтобы предотвратить непреднамеренное воздействие информации.

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

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

Следующий шаг

• Видео обсуждения сообщества