Устойчивость приложений и инфраструктуры
Устойчивость — это возможность восстановления после временных сбоев. Стратегия восстановления приложения восстанавливает нормальное функционирование с минимальным влиянием на пользователя. Сбои могут произойти в облачных средах, и приложение должно реагировать таким образом, чтобы свести к минимуму время простоя и потерю данных. В идеальной ситуации ваше приложение обрабатывает сбои без того, чтобы пользователь когда-либо знал, что возникла проблема.
Так как среды микрослужб могут быть неустойчивыми, создайте приложения, чтобы ожидать и обрабатывать частичные сбои. Частичный сбой, например, может включать исключения кода, сетевые сбои, неответственные процессы сервера или аппаратные сбои. Даже запланированные действия, такие как перемещение контейнеров на другой узел в кластере Kubernetes, могут привести к временному сбою.
Подходы к обеспечению устойчивости
При разработке устойчивых приложений часто приходится выбирать между сбоем быстрой и корректной деградации. Сбой быстро означает, что приложение немедленно выдает ошибку или исключение, если что-то происходит неправильно, а не пытается восстановить или обойти проблему. Это позволяет быстро определять и устранять проблемы. Грациозное снижение означает, что приложение попытается работать в ограниченной емкости, даже если некоторый компонент завершается сбоем.
В облачных приложениях важно обрабатывать сбои, а не быстро завершать сбои. Так как микрослужбы децентрализованы и независимо развертываются, ожидается частичный сбой. Сбой быстро позволит выполнить сбой в одной службе, чтобы быстро сократить зависимые службы, что снижает общую устойчивость системы. Вместо этого микрослужбы должны быть закодированы для прогнозирования и допуска как внутренних, так и внешних сбоев служб. Это корректное снижение позволяет общей системе продолжать работу, даже если некоторые службы нарушены. Критически важные функции, которые сталкиваются с пользователем, могут быть устойчивыми, избегая полного сбоя. Грациозный сбой также позволяет восстанавливать или самостоятельно исцелять службы, прежде чем влиять на остальную часть системы. Таким образом, для приложений на основе микрослужб более точное снижение качества соответствует рекомендациям по устойчивости, таким как изоляция сбоев и быстрое восстановление. Это предотвращает каскадные инциденты по всей системе.
Существует два основных подхода к поддержке корректного снижения устойчивости: приложений и инфраструктуры. Каждый подход имеет свои преимущества и недостатки. Уместность каждого подхода зависит от ситуации. В этом модуле объясняется, как реализовать устойчивость на основе кода и инфраструктуры.
Обеспечение устойчивости с использованием кода
Для реализации устойчивости на основе кода .NET имеет библиотеку расширений для обеспечения устойчивости и временной обработки сбоев. Microsoft.Extensions.Http.Resilience
Он использует понятный синтаксис для создания кода обработки сбоев в потокобезопасном режиме. Поведение при обработке сбоев определяют несколько политик обеспечения устойчивости. В этом модуле вы применяете стратегии повтора и разбиения цепи к операциям клиента HTTP.
Стратегия повторов
Стратегия повторных попыток — это именно то, что означает имя. Если возникает ошибка, после короткого ожидания запрос повторяется. Время ожидания увеличивается при каждом повторе. Увеличение может быть линейным или экспоненциальным.
После достижения максимального количества повторных попыток стратегия откажется и выдает исключение. С точки зрения пользователя приложение обычно занимает больше времени для выполнения некоторых операций. Приложение также может занять некоторое время, прежде чем сообщить пользователю, что он не смог завершить операцию.
Стратегия разбиения цепи
Стратегия разбиения цепи дает целевой службе перерыв после повторяющегося количества сбоев, приостанавливая попытку взаимодействия с ним. Служба может возникнуть серьезная проблема и временно не сможет реагировать. После определенного количества последовательных сбоев попытки подключения приостанавливаются, открыв канал. Во время этого ожидания дополнительные операции в целевой службе немедленно завершаются ошибкой, даже не пытаясь подключить службу. По истечении времени ожидания система попробует выполнить операцию еще раз. Если служба успешно отвечает, канал закрывается и система возвращается в нормальное состояние.
Обеспечение устойчивости с использованием инфраструктуры
Чтобы обеспечить отказоустойчивость с использованием инфраструктуры, можно использоватьсетки служб. Помимо обеспечения устойчивости без изменения кода, сетка служб обеспечивает управление трафиком, политику, безопасность, надежную идентификацию и наблюдаемость. Эти операции отделяются от приложения и переносятся на уровень инфраструктуры.
Сравнение с методами обеспечения устойчивости с использованием кода
Подход к устойчивости на основе инфраструктуры может использовать представление на основе метрик, которое позволяет динамически адаптироваться к условиям кластера в режиме реального времени. Этот подход привносит еще один аспект в управление кластером, но не добавляет код.
Используя подход на основе кода, выполните следующие действия.
- Определить подходящие параметры повторных попыток и времени ожидания.
- Сосредоточиться на определенном HTTP-запросе.
В коде приложения нет адекватного варианта реакции на сбой инфраструктуры. Представьте, что одновременно обрабатываются сотни или даже тысячи запросов. Службу может перегрузить даже повтор с экспоненциальной задержкой (увеличением времени между запросами).
Напротив, подходы на основе инфраструктуры не знают внутренних приложений. Например, сложные транзакции базы данных невидимы для сеток службы. Такие транзакции можно защитить только от сбоя с помощью подхода на основе кода.
В предстоящих уроках вы реализуете устойчивость для приложения на основе микрослужб с помощью устойчивости .NET HTTP в коде и сетке службы Компоновщика.