Шаблон Circuit Breaker

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

Контекст и проблема

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

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

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

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

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

Решение

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

Замечание

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

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

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

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

  Замечание

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

• Открытый: Запрос от приложения завершается сбоем немедленно, и исключение возвращается приложению.

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

  Замечание

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

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

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

Счетчик сбоев для состояния "Закрыто " основан на времени. Он автоматически сбрасывается с регулярными интервалами. Эта конструкция помогает предотвратить переход автоматического выключателя в открытое состояние при случайных сбоях. Порог сбоя активирует состояние Open только в том случае, если указанное число сбоев происходит в течение указанного интервала.

Счетчик успешного выполнения для состояния Half-Open записывает количество успешных попыток вызова операции. Автоматический выключатель возвращается к закрытому состоянию после заданного количества успешных непрерывных вызовов операций. Если какой-либо вызов завершается сбоем, автоматический выключатель немедленно вводит открытое состояние, а счетчик успешных вызовов сбрасывается при следующем переходе в состояние полуоткрытое.

Замечание

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

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

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

Замечание

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

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

Проблемы и рекомендации

При реализации этого шаблона учитывайте следующие факторы:

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

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

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

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

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

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

• Параллелизм: Большое количество одновременных экземпляров приложения может получить доступ к одному и тому же выключателю. Реализация не должна блокировать параллельные запросы или добавлять слишком большие нагрузки для каждого вызова операции.

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

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

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

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

  Замечание

  Служба может возвращать HTTP 429 (слишком много запросов), если она ограничивает доступ клиента, или HTTP 503 (служба недоступна), если сервис недоступен. Ответ может содержать другие сведения, такие как ожидаемая длительность задержки.

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

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

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

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

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

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

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

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

Этот шаблон может быть не подходит, если:

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

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

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

• Ожидание сброса автоматического выключателя может привести к неприемлемым задержкам.

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

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

Проектирование рабочей нагрузки

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

Столп	Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и гарантировать, что она восстанавливается до полнофункционального состояния после сбоя.	Этот шаблон помогает предотвратить перегрузку зависимостей, подверженных сбоям. Используйте этот шаблон для активации корректной деградации рабочей нагрузки. Соедините автоматические выключатели с функцией автоматического восстановления для обеспечения самосохранения и самовосстановления. - Анализ режима сбоя RE:03 - Временные ошибки - RE:07 Самосохранение
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных и кода.	Этот шаблон избегает подхода повторной попытки в случае ошибки, поскольку это может привести к чрезмерному использованию ресурсов во время восстановления зависимостей и перегрузке производительности зависимостей, пытающихся восстановиться. - Pe:07 Code и инфраструктура - Ответы pe:11 Live-issues

Если этот шаблон вводит компромиссы внутри столпа, рассмотрите их против целей других столпов.

Пример

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

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

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

На схеме есть три основных раздела. Первый раздел содержит два значка веб-браузера. Первый значок отображает полнофункциональный пользовательский интерфейс, а второй значок отображает пониженный пользовательский интерфейс с предупреждением на экране, чтобы указать проблему для пользователей. Второй раздел заключен в прямоугольник дефисной линии, разделенный на две группы. Верхняя группа включает ресурсы рабочей нагрузки, службу приложений и Azure Cosmos DB. Стрелки из обоих значков веб-браузера указывают на экземпляр службы приложений, представляющий входящие запросы от клиента. Кроме того, стрелки из экземпляра службы приложений указывают на Azure Cosmos DB, показывая взаимодействие данных между службами приложений и базой данных. Еще одна стрелка петляет от экземпляра службы приложений обратно к себе, символизируя механизм тайм-аута автоматического отключения. Этот цикл означает, что при обнаружении ответа на слишком много запросов 429 система возвращается к обслуживанию кэшированных ответов, ухудшая взаимодействие с пользователем до тех пор, пока ситуация не будет решена. В нижней группе этого раздела основное внимание уделяется наблюдаемости и предупреждению. Azure Monitor собирает данные из ресурсов Azure в верхней группе. Azure Monitor также подключается к значку правила оповещения. Третий раздел показывает рабочий процесс масштабируемости, который активируется при возникновении оповещения. Стрелка соединяет значок оповещения с утверждающими, указывая, что уведомление отправляется им для проверки. Другая стрелка ведет от утверждающих в консоль разработки, которая обозначает процесс утверждения для масштабирования базы данных. Наконец, дополнительная стрелка исходит из консоли разработки к Azure Cosmos DB, отображая действие масштабирования базы данных в ответ на состояние перегрузки.

Скачайте файл Visio для этой архитектуры.

Поток A: закрытое состояние

• Система работает нормально, и все запросы достигают базы данных без возврата http-ответов 429 .

• Средство разбиения цепи остается закрытым, и не требуется никаких ответов по умолчанию или кэшированных ответов.

Поток B: открытое состояние

1. Когда автоматический выключатель получает первый 429 ответ, он переходит в открытое состояние.

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

3. Azure Monitor получает журналы и данные телеметрии и оценивает их по динамическим пороговым значениям. Оповещение активируется, если выполняются условия правила генерации оповещений.

4. Группа действий заранее уведомляет группу операций о состоянии перегрузки.

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

Flow C: состояние Half-Open

1. После предопределенного времени ожидания автоматический выключатель переходит в состояние Half-Open, которое разрешает ограниченное количество пробных запросов.

2. Если эти пробные запросы завершаются успешно, без возвращения ответов 429, прерывание сбрасывается в закрытое состояние, и нормальные операции восстанавливаются до Flow A. Если сбои сохраняются, прерывание возвращается к открытому состоянию или Flow B.

Компоненты

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

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

• Azure Monitor работает в качестве централизованного решения для мониторинга. Он объединяет все журналы действий для обеспечения комплексной комплексной наблюдаемости. Azure Monitor получает журналы и данные телеметрии из службы приложений и ключевых метрик из Azure Cosmos DB (например, количество 429 ответов) для агрегирования и анализа.

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

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

Связанные ресурсы

• Шаблон Reliable Web App использует шаблон выключателя цепи для веб-приложений, которые объединяются в облаке.

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

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