Рекомендации по обработке временных сбоев

  • Статья

Применяется к этой рекомендации по контрольным спискам надежности платформы Azure Well-Architected:

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

Связанные руководства:Фоновые задания | Самосохранение

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

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

Ключевые стратегии проектирования

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

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

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

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

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

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

Сложности

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

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

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

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

Общие рекомендации

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

Определение наличия встроенного механизма повтора

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

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

Определение того, подходит ли операция для повторных попыток

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

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

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

Определение соответствующего количества повторных попыток и интервала

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

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

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

    • Экспоненциальная задержка. Приложение ожидает некоторое время до первой повторной попытки, а затем экспоненциально увеличивает время между каждой последующей попыткой. Например, он может повторить операцию через 3 секунды, 12 секунд, 30 секунд и т. д.

    • Интервалы с приращениями. Приложение ожидает некоторое время, прежде чем первая повторная попытка, а затем постепенно увеличивает время между каждой последующей попыткой. Например, она может повторить операцию через 3 секунды, 7 секунд, 13 секунд и т. д.

    • Постоянные интервалы. Для всех повторных попыток применяется одинаковый интервал. Например, операция может повторяться каждые 3 секунды.

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

    • Случайный выбор. Любая из перечисленных ранее стратегий повтора может включать рандомизацию, чтобы предотвратить отправку последующих попыток несколькими экземплярами клиента одновременно. Например, один экземпляр может повторить операцию через 3 секунды, 11 секунд, 28 секунд и т. д., а другой экземпляр может повторить операцию через 4 секунды, 12 секунд, 26 секунд и т. д. Рандомизация — это полезный метод, который можно сочетать с другими стратегиями.

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

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

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

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

  • Используйте тип исключения и все содержащиеся в нем данные или коды ошибок и сообщения, возвращаемые службой, чтобы оптимизировать количество повторных попыток и интервал между ними. Например, некоторые исключения или коды ошибок (например, код HTTP 503, служба недоступна, с заголовком Retry-After в ответе) могут указывать, как долго может длиться ошибка или что служба завершилась сбоем и не будет отвечать на любые последующие попытки.

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

Избегайте антишаблоны

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

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

  • Никогда не выполняйте немедленный повтор больше одного раза.

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

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

Тестирование стратегии повторных попыток и реализации

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

    • Внесите в службу временные и не временные ошибки. Например, отправьте недопустимые запросы или добавьте код, который обнаруживает тестовые запросы и дает отклик с различными типами ошибок.

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

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

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

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

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

Управление конфигурациями политики повторных попыток

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

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

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

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

Регистрировать и отслеживать временные и непереходные ошибки

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

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

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

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

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

Управление операциями, которые постоянно завершаются сбоем

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

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

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

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

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

Другие замечания

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

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

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

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

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

Примечание

Дополнительные рекомендации по компромиссам и рискам см. в разделе Проблемы и рекомендации в статье Шаблон повтора.

Упрощение поддержки Azure

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

Служба Ключевые возможности Настройки политики Область Функции телеметрии
Microsoft Entra ID Собственный код в библиотеке проверки подлинности Майкрософт (MSAL) Внедрено в библиотеку MSAL Внутренние None
Azure Cosmos DB Собственный код в службе Не настраивается. Глобальный TraceSource
Хранилище озера данных Azure Собственный код в клиенте Не настраивается. Индивидуальные операции None
Центры событий Azure Собственный код в клиенте Программный Клиент None
Центр Интернета вещей Azure Собственный код в клиентском пакете SDK Программный Клиент None
Кэш Azure для Redis Собственный код в клиенте Программный Клиент TextWriter
Когнитивный поиск Azure Собственный код в клиенте Программный Клиент Трассировка событий Windows или настраиваемая
служебной шине Azure Собственный код в клиенте Программный NamespaceManager, MessagingFactory и client Трассировка событий Windows
Azure Service Fabric Собственный код в клиенте Программный Клиент None
База данных Azure SQL с ADO.NET Polly Декларативные и программные Единые инструкции или блоки кода Другой
База данных SQL с Entity Framework Собственный код в клиенте Программный Глобальные каждого домена приложения None
База данных SQL с Entity Framework Core Собственный код в клиенте Программный Глобальные каждого домена приложения None
Хранилище Azure Собственный код в клиенте Программный Клиентские и индивидуальные операции TraceSource

Примечание

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

Пример

Пример использования многих шаблонов, рассмотренных в этой статье, см. в разделе Надежный шаблон веб-приложения для .NET . На GitHub также есть эталонная реализация .

Контрольный список надежности

См. полный набор рекомендаций.

Контрольный список надежности