Шаблоны устойчивости приложений

Подсказка

Это фрагмент из электронной книги «Архитектура облачных нативных приложений .NET для Azure», доступен на .NET Docs или как бесплатный загружаемый PDF-файл, который можно прочитать в автономном режиме.

Скачать в формате PDF

Первая линия защиты — устойчивость приложений.

Хотя вы можете инвестировать значительное время на написание собственной платформы устойчивости, такие продукты уже существуют. Polly — это комплексная библиотека устойчивости .NET и временной обработки ошибок, которая позволяет разработчикам выражать политики устойчивости в простом и потокобезопасном режиме. Polly предназначен для приложений, созданных с использованием .NET Framework или .NET 7. В следующей таблице описываются функции устойчивости, называемые policiesдоступными в библиотеке Polly. Их можно применять по отдельности или сгруппировать по отдельности.

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

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

Код состояния HTTP	Причина
404	Не найдено
408	Время ожидания запроса
429	Слишком много запросов (скорее всего, ваш доступ временно ограничен)
502	Недопустимый шлюз
503 (Сервис временно недоступен)	Служба недоступна
504	Тайм-аут шлюза

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

Как рекомендуется в главе 1, разработчики Майкрософт, создающие облачные приложения, должны использовать платформу .NET. Версия 2.1 представила библиотеку HTTPClientFactory для создания экземпляров HTTP-клиента для взаимодействия с ресурсами на основе URL-адресов. Заменяя исходный класс HTTPClient, класс фабрики поддерживает множество расширенных функций, одной из которых является тесная интеграция с библиотекой устойчивости Polly. С его помощью можно легко определить политики устойчивости в классе запуска приложения для обработки частичных сбоев и проблем с подключением.

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

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

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

Шаблон повторных попыток позволяет службе повторить неудачную операцию запроса (настраиваемую) количество раз с экспоненциальным увеличением времени ожидания. На рисунке 6-2 показан процесс повторной попытки в действии.

Рис. 6-2. Шаблон повтора в действии

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

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

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

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

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

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

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

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

Рис. 6-3. Шаблон разбиения цепи в действии

На предыдущем рисунке в исходный шаблон повторных попыток был добавлен шаблон Circuit Breaker. Обратите внимание, что после 100 неудачных запросов автоматические выключатели открываются и больше не позволяют выполнять вызовы к сервису. Значение CheckCircuit, установленное на 30 секунд, указывает, как часто библиотека позволяет направить один запрос в службу. Если этот вызов выполнен успешно, канал закрывается и служба снова доступна для трафика.

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

Тестирование устойчивости

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

Устойчивость приложений — это необходимость обработки проблемных запрошенных операций. Но, это только половина истории. Далее мы рассмотрим функции устойчивости, доступные в облаке Azure.

НазадДалее