Проектирование устойчивых центров событий и функций

  • Статья

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

Azure предоставляет три основных службы обмена сообщениями, которые можно использовать с Функции Azure для поддержки широкого спектра уникальных сценариев на основе событий. Из-за секционированных потребительских моделей и возможности приема данных с высокой скоростью Центры событий Azure часто используются для потоковой передачи событий и сценариев больших данных. Подробное сравнение служб обмена сообщениями Azure см. в разделе "Выбор между службами обмена сообщениями Azure" — "Сетка событий", "Центры событий" и служебная шина.

Преимущества и проблемы потоковой передачи

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

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

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

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

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

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

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

Идемпотентность

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

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

повторяющиеся события;

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

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

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

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

Методы дедупликации

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

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

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

Обработка ошибок и повторные попытки

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

Руководство по обработке ошибок

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

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

  • Добавление структурированной обработки ошибок: применение соответствующих конструкций обработки ошибок для каждого языка программирования для перехвата, журнала и обнаружения ожидаемых и необработанных исключений в коде функции. Например, используйте блок try/catch в C#, Java и JavaScript и воспользуйтесь преимуществами пробных и за исключением блоков в Python для обработки исключений.

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

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

Повторы

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

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

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

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

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

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

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

Стратегии для сбоев и поврежденных данных

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

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

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

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

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

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

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

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

Соавторы

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

Автор субъекта:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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

Прежде чем продолжить, ознакомьтесь со следующими статьями:

Безопасность

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