Надежная обработка событий с помощью Функций Azure и Центров событий

2025-07-02

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

Проблемы потоков событий в распределенных системах

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

Однако рассмотрите следующие проблемы, связанные с потреблением потока событий:

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

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

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

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

Как триггер Центров событий обрабатывает события

Функции Azure используют события из концентратора событий, выполнив следующие действия.

Указатель создается и сохраняется в Azure Storage для каждого раздела концентратора событий.
Новые события получаются в пакете (по умолчанию), а хост пытается активировать функцию, предоставляющую пакет событий, для обработки.
После завершения выполнения функции с исключениями или без них указатель будет перемещён, а контрольная точка сохранится в учетной записи хранения узла по умолчанию.
Если условия не позволяют завершить выполнение функции, хост не может сместить указатель. Если указатель не может продвинуться, последующие выполнения повторно обработают те же события.

Это поведение показывает несколько важных моментов:

Необработанные исключения могут привести к потере событий:

Выполнение функций, которые вызывают исключение, продолжается, продвигая указатель. Установка политики повторных попыток или другой логики повторных попыток задерживает продвижение указателя до завершения всего повтора.
Функции гарантируют по крайней мере однократную доставку:

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

Обработка исключений

Хотя весь код функции должен включать блок try/catch на самом высоком уровне кода, наличие catch блока еще более важно для функций, обрабатывающих события Центров событий. Таким образом, при возникновении исключения блок catch обрабатывает ошибку перед тем как указатель продвигается.

Механизмы повтора и политики повторных попыток

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

Политики повторных попыток

Функции предоставляют встроенные политики повторных попыток для Центров событий. При использовании политик повторных попыток вы просто вызываете новое исключение, а хост пытается снова обработать событие на основе определенной политики. Для этого поведения повторных попыток требуется версия 5.x или более поздняя версия расширения Центров событий. Дополнительные сведения см. в разделе Политики повтора.

Настраиваемая логика повторных попыток

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

Попробуйте обработать событие три раза (потенциально с задержкой между повторными попытками).
Если конечный результат всех повторных попыток является сбоем, добавьте событие в очередь, чтобы обработка продолжалось в потоке.
Затем обрабатываются искажённые или необработанные события.

Замечание

Polly — это пример библиотеки устойчивости и временной обработки ошибок для приложений C#.

Ошибки, не относящиеся к исключениям

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

Уверенность в том, что каждое событие обрабатывается по крайней мере один раз, подразумевает, что некоторые события могут обрабатываться более одного раза. Приложения-функции должны учитывать эту возможность и быть построены вокруг принципов идемпотентности.

Обработка состояний сбоя

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

Шаблон разбиения цепи

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

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

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

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

Устойчивые функции и Azure Logic Apps обеспечивают инфраструктуру для управления рабочими процессами и состояниями канала. В этой статье описывается использование Logic Apps для приостановки и перезапуска выполнения функций, предоставляя вам контроль, необходимый для реализации шаблона прерывателя цепи.

Определение порогового значения сбоя между экземплярами

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

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

Сведения о реализации для этой логики мониторинга зависят от конкретных потребностей приложения, но в целом необходимо создать систему, которая:

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

Управление состоянием канала с помощью Azure Logic Apps

Azure Logic Apps поставляется со встроенными коннекторами для различных служб, функций и оркестраций с отслеживанием состояния, и это естественный выбор для управления состоянием цепи. После обнаружения момента, когда необходимо разорвать контур, можно создать логическое приложение для реализации данного рабочего процесса.

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

Сведения об отключении и повторном использовании определенных функций с помощью параметров приложения см. в статье "Как отключить функции в Функциях Azure".

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

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

Стратегии миграции триггеров сетки событий

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

Рекомендуется использовать группы потребителей , чтобы избежать потери или дублирования данных событий во время миграции:

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

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