Шаблон повтора

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

Контекст и проблема

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

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

Решение

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

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

Стратегии повтора

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

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

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

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

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

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

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

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

Проблемы и рекомендации

При выборе схемы реализации этого шаблона следует учитывать следующие моменты.

Влияние на производительность

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

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

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

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

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

Тип исключения

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

Согласованность транзакций

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

Общее руководство

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

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

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

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

Когда следует использовать этот шаблон

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

Этот шаблон может оказаться неэффективным в следующих случаях:

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

Проектирование рабочей нагрузки

Архитектор должен оценить, как шаблон повторных попыток можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:

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

Пример

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

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

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

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

Связанные ресурсы

• Шаблон надежного веб-приложения показывает, как применить шаблон повторных попыток к веб-приложениям, конвергентным в облаке.

• Для большинства служб Azure клиентские пакеты SDK включают встроенную логику повторных попыток.

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