Выполняйте обработку ошибок, которая может занять разное количество времени при подключении к удаленной службе или ресурсу. Этот шаблон может повысить стабильность и устойчивость приложения.
Контекст и проблема
В распределенной среде вызовы к удаленным ресурсам и службам могут завершиться сбоем из-за временных сбоев, таких как медленные сетевые подключения, тайм-ауты или ресурсы, перезаключаемые или временно недоступные. Эти ошибки обычно устраняются через короткий промежуток времени. Следует подготовить надежное облачное приложение для их обработки с использованием стратегии, такой как шаблон повторов.
Однако в некоторых ситуациях ошибки возникают из-за непредвиденных событий. На их устранение может потребоваться гораздо больше времени. Эти ошибки могут варьироваться по серьезности от частичной потери возможности подключения до полного отказа службы. В таких ситуациях приложение может быть бессмысленным для постоянного повтора операции, которая вряд ли будет успешно выполнена, и вместо этого приложение должно быстро принять, что операция завершилась ошибкой и обработает этот сбой соответствующим образом.
Кроме того, если служба занята, сбой в одной из частей системы может привести к лавинообразному накоплению сбоев. Например, операция, которая вызывает службу, может быть настроена для реализации времени ожидания и ответа с сообщением об ошибке, если служба не сможет ответить в течение этого периода. Однако эта стратегия может привести к блокировке множества параллельных запросов к одной и той же операции до истечения срока ожидания. Эти заблокированные запросы могут содержать критические системные ресурсы, такие как память, потоки, подключения к базе данных и т. д. Таким образом, эти ресурсы могут быть исчерпаны, что приводит к сбою других, возможно, несвязанных частей системы, которые должны использовать те же ресурсы. В этих ситуациях предпочтительно, чтобы операция немедленно завершалась с ошибкой и пыталась вызвать службу, только если такой вызов может быть успешно выполнен. Установка более короткого времени ожидания может помочь устранить эту проблему, но время ожидания не должно быть таким коротким, что операция завершается сбоем большую часть времени, даже если запрос к службе в конечном итоге завершится успешно.
Решение
Шаблон разбиения цепи может предотвратить многократное попытку приложения выполнить операцию, которая, скорее всего, завершится ошибкой. Разрешите ему продолжить выполнение, не ожидая устранения ошибки или расхода ресурсов процессора на определение того, что предполагается долгий сбой. Шаблон автоматического выключения также позволяет приложению определять, была ли устранена неисправность. Если проблема устранена, приложение может попытаться вызвать операцию.
У шаблона автоматического выключения и шаблона повторов разные цели. Шаблон повторов позволяет приложению повторять операцию, ожидая, что она будет успешного выполнена. Шаблон автоматического выключения в приложении предотвращает выполнение операции, которая, вероятнее всего, завершится ошибкой. Приложение может сочетать оба шаблона, используя шаблон повтора для вызова операции через автоматическое выключение. Однако логика повторения должна быть чувствительной к любым исключениям, возвращаемым автоматическим выключением, и отказываться от повторных попыток, если автоматическое выключение указывает, что неисправность не является временной.
Автоматическое выключение действует в качестве прокси-сервера операций, которые могут завершиться со сбоем. Прокси-сервер должен отслеживать количество недавних сбоев, которые произошли, и использовать эти сведения, чтобы решить, разрешать ли операция продолжаться, или немедленно возвращать исключение.
Прокси-сервер может быть реализован как компьютер со следующими состояниями, имитирующими возможности электрического автоматического выключателя:
Закрытый. Запрос приложения перенаправляется на операцию. Прокси-сервер ведет подсчет числа недавних сбоев, и если вызов операции не завершился успешно, прокси-сервер увеличивает это число. Если число недавних сбоев превышает заданный порог в течение заданного периода времени, прокси-сервер переводится в состояние Открытый. На этом этапе прокси-сервер запускает таймер времени ожидания, и когда срок действия этого таймера истекает, прокси-сервер помещается в состояние half-Open.
Целью таймера ожидания является предоставление системного времени для устранения проблемы, вызвавшей сбой, прежде чем позволить приложению повторить операцию.
Открытый. Запрос приложения немедленно завершается со сбоем, и исключение возвращается в приложение.
Полуоткрытый. Ограниченному числу запросов от приложения разрешено проходить через операцию и вызывать ее. Если эти запросы выполняются успешно, предполагается, что ошибка, которая ранее вызывала сбой, устранена, а автоматический выключатель переходит в состояние Закрытый (счетчик сбоев сбрасывается). Если любой запрос завершается ошибкой, средство останова цепи предполагает, что ошибка по-прежнему присутствует, поэтому она возвращается к состоянию Open и перезапускает таймер времени ожидания, чтобы предоставить системе дополнительный период времени для восстановления после сбоя.
Состояние Полуоткрытый полезно для предотвращения внезапного переполнения службы восстановления запросами. По мере восстановления службы она может поддерживать ограниченный объем запросов до полного восстановления, но при восстановлении переполнение может привести к истечению времени ожидания службы или повторному сбою.
На рисунке показан счетчик сбоев на основе времени, используемый состоянием Закрытый. Он сбрасывается через периодические интервалы. Эта конструкция помогает предотвратить ввод в состояние Open, если возникают случайные сбои. Порог сбоев, который переводит автоматическое выключение в состояние Открытый, достигается, только если указанное количество сбоев произошло в течение заданного интервала. Счетчик, используемый состоянием Полуоткрытый, записывает количество успешных попыток вызвать операцию. Автоматическое выключение возвращается в состояние Закрытый после определенного числа последовательных успешных вызовов операций. Если вызов завершается со сбоем, автоматическое выключение немедленно переходит в состояние Открытый, а счетчик успешных выполнений будет сброшен до следующего раза, когда автоматический выключатель перейдет в состояние Полуоткрытый.
Восстановление системы обрабатывается извне, возможно, путем восстановления или перезапуска неисправного компонента либо исправления сетевого соединения.
Шаблон автоматического прерывания обеспечивает стабильность, пока система восстанавливается после сбоя и снижает влияние на производительность. Благодаря этому можно поддерживать определенный показатель времени отклика системы, быстро отклоняя запрос на операцию, которая, скорее всего, завершится со сбоем, вместо того чтобы ждать, пока не истечет время ожидания операции, или ждать в течение неопределенного времени (так как операция никогда не возвратится). Если автоматическое выключение порождает событие каждый раз, когда оно меняет состояние, эта информация может использоваться для мониторинга работоспособности части системы, защищенной автоматическим выключением, или для оповещения администратора о переходе автоматического выключения в состояние Открытый.
Шаблон настраивается и может быть адаптирован в соответствии с типом возможного сбоя. Например, вы можете применить к выключателю время ожидания увеличения времени ожидания. Вы можете поместить выключатель в состояние Открыть в течение нескольких секунд, а затем, если сбой не был решен, увеличьте время ожидания до нескольких минут и т. д. В некоторых случаях вместо состояния Открытый, возвращающего сбой и вызывающего исключение, полезнее возвращать значение по умолчанию, которое было значимо для приложения.
Примечание.
Традиционно средства разбиения каналов зависят от предварительно настроенных пороговых значений, таких как количество сбоев и длительность ожидания, что приводит к детерминированному, но иногда неоптимальному поведению. Однако адаптивные методы с помощью искусственного интеллекта и машинного обучения могут динамически настраивать пороговые значения на основе шаблонов трафика в режиме реального времени, аномалий и исторических сбоев, что делает канал более устойчивым и эффективным.
Проблемы и рекомендации
При выборе схемы реализации этого шаблона следует учитывать следующие моменты.
обработке исключений. Приложение, вызывающее операцию с помощью средства останова цепи, должно быть готово к обработке исключений, вызванных, если операция недоступна. Способ обработки исключения будет зависеть от приложения. Например, приложение может временно понизить функциональность, вызвать альтернативную операцию для выполнения той же задачи или получения тех же данных или сообщить об исключении пользователю и попросить его повторить попытку позже.
Типы исключений: запрос может завершиться ошибкой по многим причинам, некоторые из которых могут указывать на более тяжелый тип сбоя, чем другие. Например, запрос может завершиться сбоем из-за сбоя удаленной службы и займет несколько минут, или из-за времени ожидания из-за временной перегрузки службы. Автоматическое выключение может исследовать типы возникающих исключений и корректировать свою стратегию в зависимости от характера этих исключений. Например, может потребоваться большее количество исключений времени ожидания для передачи останова канала в состояние open Open по сравнению с количеством сбоев из-за того, что служба полностью недоступна.
мониторинг. Средство автоматического останова должно обеспечить четкое наблюдение как в неудачных, так и успешных запросах, что позволяет группам операций оценивать работоспособность системы. Используйте распределенную трассировку для комплексной видимости между службами.
возможность восстановления. Необходимо настроить средство разбиения цепи для соответствия вероятному шаблону восстановления операции, которую она защищает. Например, если автоматическое выключение остается в состоянии Открытый в течение длительного периода времени, оно может создавать исключения, даже если сбой был устранен. Аналогично автоматическое выключение может меняться и уменьшать время отклика приложений, если оно переключится из состояния Открытый в состояние Полуоткрытый слишком быстро.
тестирование неудачных операций. В состоянии открытия открыть, а не использовать таймер, чтобы определить, когда переключиться на состояние half-Open, средство останова цепи может периодически проверять связь с удаленной службой или ресурсом, чтобы определить, станет ли он доступен снова. Проверка связи может принимать форму попытки вызвать операцию, которая ранее завершилась со сбоем, или она может использовать специальную операцию, предоставляемую удаленной службой специально для проверки работоспособности службы, как описано в шаблоне мониторинга конечной точки работоспособности.
переопределение вручную. В системе, в которой время восстановления для операции сбоя является чрезвычайно переменной, полезно предоставить параметр ручного сброса, позволяющий администратору закрыть выключатель (и сбросить счетчик сбоев). Аналогичным образом администратор может принудительно отключить канал в состояние Open (и перезапустить таймер времени ожидания), если операция, защищенная выключателем, временно недоступна.
параллелизм: к одному и тому же выключателю можно получить доступ с помощью большого количества одновременных экземпляров приложения. Реализация не должна блокировать параллельные запросы или добавлять слишком большие нагрузки для каждого вызова операции.
различия ресурсов. Будьте осторожны при использовании одного выключателя для одного типа ресурса, если может быть несколько базовых независимых поставщиков. Например, в хранилище данных, которое содержит несколько сегментов, один сегмент может быть полностью доступен, в то время как другой может испытывать временные проблемы. Если сообщения об ошибках в этих сценариях объединены, приложение может попытаться получить доступ к некоторым сегментам даже при высокой вероятности сбоя, в то время как другие сегменты могут быть заблокированы, несмотря на то что они могут быть успешно выполнены.
ускорение разрыва цепи: иногда ответ на сбой может содержать достаточно сведений для немедленной поездки и оставаться спотыкаться в течение минимального времени. Например, сообщение об ошибке перегруженного общего ресурса может указывать на то, что выполнение немедленной повторной попытки не рекомендуется и приложению следует повторить попытку через несколько минут.
развертывания с несколькими регионами. Средство разбиения цепи может быть разработано для развертывания в одном или нескольких регионах. Последнее можно реализовать с помощью глобальных подсистем балансировки нагрузки или пользовательских стратегий разбиения цепи, которые обеспечивают контрольную отработку отказа, оптимизацию задержки и соответствие нормативным требованиям.
каналы сетки службы: средства разбиения каналов можно реализовать на уровне приложения или в виде перекрестной абстрактной функции. Например, сетки служб часто поддерживают нарушение цепи как боковой или как автономную возможность без изменения кода приложения.
Примечание.
Служба может возвращать HTTP 429 (слишком много запросов), если она регулирует клиент или HTTP 503 (служба недоступна), если служба недоступна в настоящее время. Сообщение может включать дополнительные сведения, например, предполагаемую длительность задержки.
неудачные запросы: в состоянии Open, а не просто сбой, средство разбиения канала также может записывать сведения о каждом запросе в журнал и упорядочивать для воспроизведения этих запросов, когда удаленный ресурс или служба становятся доступными.
неуместное время ожидания во внешних службах: подсистема останова канала может не иметь возможности полностью защитить приложения от операций, которые завершаются сбоем во внешних службах, настроенных с длительным периодом ожидания. Если время ожидания слишком длинное, поток, работающий с разбителем цепи, может быть заблокирован в течение длительного периода до того, как средство разбиения канала указывает, что операция завершилась ошибкой. В это время множество других экземпляров приложений могут также попытаться вызвать службу через автоматическое выключение и связать значительное количество потоков, прежде чем все они завершатся со сбоем.
Адаптируемость к диверсификации вычислений: подсистемы разбиения каналов должны учитывать различные вычислительные среды, от бессерверных до контейнерных рабочих нагрузок, где такие факторы, как холодные запуски и обработка сбоев масштабируемости. Адаптивные подходы могут динамически настраивать стратегии на основе типа вычислений, обеспечивая устойчивость в разнородных архитектурах.
Когда следует использовать этот шаблон
Используйте этот шаблон в следующих случаях:
- Чтобы предотвратить каскадные сбои путем остановки чрезмерного вызова удаленной службы или запросов доступа к общему ресурсу, если эти операции, скорее всего, завершаются ошибкой.
- Чтобы повысить устойчивость нескольких регионов путем интеллектуальной маршрутизации трафика на основе сигналов сбоя в режиме реального времени.
- Чтобы защитить от медленных зависимостей, помогая вам следить за целями уровня обслуживания (SLOS) и избегать снижения производительности из-за высокой задержки служб.
- Для обработки периодических проблем с подключением и уменьшения сбоев запросов в распределенных средах.
Этот шаблон не рекомендуется использовать в следующих случаях:
- Для обработки доступа к локальным закрытым ресурсам в приложении, например, в структуре данных в памяти. В этой среде при использовании автоматического выключения нагрузка в системе возрастет.
- В качестве замены для обработки исключений в бизнес-логике приложений.
- Если хорошо известные алгоритмы повторных попыток достаточно, и ваши зависимости предназначены для работы с механизмами повторных попыток. Реализация автоматического останова в приложении в данном случае может привести к ненужной сложности в системе.
- При ожидании сброса цепи может привести к неприемлемым задержкам.
- Если у вас есть архитектура на основе сообщений или на основе событий, так как они часто направляют сообщения в очередь недоставленных сообщений (DLQ) для ручной или отложенной обработки. Встроенные механизмы изоляции сбоев и повторных попыток, которые обычно реализуются в этих проектах, часто достаточно.
- Если восстановление сбоя управляется на уровне инфраструктуры или платформы, например при проверке работоспособности в глобальных подсистемах балансировки нагрузки или сетках служб, может не потребоваться разбиения каналов.
Проектирование рабочей нагрузки
Архитектор должен оценить, как шаблон разбиения цепи можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:
Принцип | Как этот шаблон поддерживает цели основных компонентов |
---|---|
Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя. | Этот шаблон предотвращает перегрузку неисправной зависимости. Этот шаблон также можно использовать для активации корректного снижения производительности в рабочей нагрузке. Выключатели часто связаны с автоматическим восстановлением, чтобы обеспечить как самосохранение, так и самовосстановление. - Анализ режима сбоя RE:03 - Временные ошибки RE:07 - RE:07 Самосохранение |
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода. | Этот шаблон позволяет избежать подхода повтора по ошибке, что может привести к чрезмерному использованию ресурсов во время восстановления зависимостей, а также может перегружать производительность в зависимости, которая пытается восстановить. - Pe:07 Code и инфраструктура - Ответы pe:11 Live-issues |
Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.
Связанные ресурсы
Следующие шаблоны также могут быть полезными при реализации этого шаблона:
Шаблон надежного веб-приложения показывает, как применить шаблон разбиения каналов к веб-приложениям, конвергентным в облаке.
Шаблон повторов. Описывает механизм обработки ожидаемых временных сбоев, при котором приложение может повторно подключаться к службе или сетевому ресурсу, обращение к которым завершилось сбоем, не прерывая потока событий.
Шаблон мониторинга конечных точек работоспособности. Автоматическое выключение может проверить работоспособность службы, отправив запрос в конечную точку, открытую службой. Служба должна вернуть информацию о своем состоянии.