Шаблоны устойчивости приложения
Совет
Это содержимое является фрагментом из электронной книги, архитектора облачных собственных приложений .NET для Azure, доступных в .NET Docs или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.
Первая линия защиты — устойчивость приложений.
Хотя вы можете инвестировать значительное время на написание собственной платформы устойчивости, такие продукты уже существуют. Polly — это комплексная библиотека устойчивости .NET и временной обработки ошибок, которая позволяет разработчикам выражать политики устойчивости в простом и потокобезопасном режиме. Опрос предназначен для приложений, созданных с помощью платформа .NET Framework или .NET 7. В следующей таблице описываются функции устойчивости, называемые policiesдоступными в библиотеке Polly. Их можно применять по отдельности или сгруппировать по отдельности.
| Политика | Взаимодействие |
|---|---|
| Повторить попытку | Настраивает операции повторных попыток для назначенных операций. |
| Размыкатель цепи | Блокирует запрошенные операции для предопределенного периода, когда ошибки превышают настроенное пороговое значение. |
| Время ожидания | Устанавливает ограничение на длительность, в течение которой вызывающий объект может ожидать ответа. |
| Распределительный блок | Ограничивает действия пула ресурсов фиксированного размера, чтобы предотвратить сбой вызовов, которые не заболеют ресурсом. |
| Cache | Автоматически сохраняет ответы. |
| Резерв | Определяет структурированное поведение при сбое. |
Обратите внимание, как на предыдущем рисунке политики устойчивости применяются к запросам сообщений, поступающих из внешнего клиента или серверной службы. Цель состоит в том, чтобы компенсировать запрос на службу, которая может быть временно недоступна. Эти кратковременные прерывания обычно проявляются с помощью кодов состояния 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. Шаблон разбиения цепи в действии
На предыдущем рисунке шаблон разбиения цепи был добавлен в исходный шаблон повторных попыток. Обратите внимание, что после 100 неудачных запросов автоматические остановы открываются и больше не разрешают вызовы в службу. Значение CheckCircuit, заданное в 30 секундах, указывает, как часто библиотека позволяет одному запросу перейти к службе. Если этот вызов выполнен успешно, канал закрывается и служба снова доступна для трафика.
Помните, что намерение шаблона разбиения цепи отличается от намерения шаблона повтора. Шаблон повторных попыток позволяет приложению повторить операцию в ожидании успешного выполнения. Шаблон разбиения цепи запрещает приложению выполнять операцию, которая, скорее всего, завершится ошибкой. Как правило, приложение объединяет эти два шаблона с помощью шаблона повторных попыток для вызова операции через разбиение цепи.
Тестирование отказоустойчивости
Проверка устойчивости не всегда может быть выполнена так же, как и при тестировании функциональных возможностей приложения (путем выполнения модульных тестов, тестов интеграции и т. д.). Вместо этого необходимо проверить, как сквозная рабочая нагрузка выполняется в условиях сбоя, которые происходят только периодически. Например, внедрение сбоев путем сбоя процессов, истекшего срока действия сертификатов, сделать зависимые службы недоступными и т. д. Платформы, такие как хаос-обезьяна , можно использовать для такого тестирования хаоса.
Устойчивость приложений — это необходимость обработки проблемных запрошенных операций. Но, это только половина истории. Далее мы рассмотрим функции устойчивости, доступные в облаке Azure.
