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

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

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

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

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

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

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

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

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

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

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

  1. Триггер создаёт и сохраняет указатель в служба хранилища Azure для каждого раздела хаба событий.
  2. Триггер получает новые события в пакете (по умолчанию), и хост пытается активировать функцию, предоставляя пакет событий для обработки.
  3. Когда функция завершает выполнение, независимо от того, возникли исключения или нет, триггер перемещает указатель и сохраняет контрольную точку в учетную запись хранилища узла по умолчанию.
  4. Если условия мешают выполнению функции, хост не может продвинуть указатель. Если указатель не может продвинуться, последующие выполнения повторно обработают те же события.

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

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

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

  • Функции гарантируют по крайней мере однократную доставку:

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

  • Состояние контрольной точки хранится в служба хранилища Azure:

    Триггер сохраняет контрольную точку (указатель обработки) в учётной записи хранения, заданной параметром AzureWebJobsStorage приложения-функции. Эта ссылка на сохранённую контрольную точку означает следующее:

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

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

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

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

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

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

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

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

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

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

Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы узнать, как отключать и повторно включать определённые функции с помощью настроек приложения, смотрите раздел «Как отключить функции в Функции Azure».

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

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

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

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

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

  1. Создайте новую группу потребителей для нового целевого приложения.

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

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

  3. Убедитесь, что новое приложение правильно обрабатывает события.

  4. Остановите оригинальное приложение или удалите его подписку или потребительскую группу.

  • Last updated on