circuit breaker
Полезное
Смотреть что такое «circuit breaker» в других словарях:
circuit breaker — cir cuit break er, n. (Elec.) A device contained within an electrical circuit designed to interrupt the circuit when the current exceeds a preset value; it is sometimes called a
circuit breaker — circuit breakers also circuit breaker N COUNT A circuit breaker is a device which can stop the flow of electricity around a circuit by switching itself off if anything goes wrong. There is an internal circuit breaker to protect the instrument… … English dictionary
circuit-breaker — ˈcircuit breaker [circuit breaker circuit breakers] noun a device that can automatically stop an electric current if it becomes dangerous … Useful english dictionary
circuit-breaker — ► NOUN ▪ an automatic safety device for stopping the flow of current in an electric circuit … English terms dictionary
circuit breaker — ☆ circuit breaker n. a switchlike safety device that automatically interrupts the flow of an electrical current in a circuit when it has become excessive … English World dictionary
Circuit Breaker — ist: eine Überstromschutzeinrichtung eine Comicfigur von Marvel ein Pseudonym des Musikers Richie Hawtin eine Volatilitätsunterbrechung, ein Begriff aus dem Aktienwesen. Diese Seite ist eine … Deutsch Wikipedia
Circuit Breaker — [engl.], Überstromschalter … Universal-Lexikon
Circuit breaker — For other uses, see Circuit breaker (disambiguation). An air circuit breaker for low voltage (less than 1000 volts) power distribution switchgear … Wikipedia
circuit breaker — A procedure that temporarily halts trading on all US stock markets for one hour when the Dow Jones Industrial Average falls 250 points or more within a trading day. The pause is designed to allow time for the markets to absorb the news that… … Financial and business terms
circuit breakers
Смотреть что такое «circuit breakers» в других словарях:
Circuit Breakers — Éditeur Mindscape Développeur Supersonic Software Date de sortie 1998 Genre Jeu de course Mode de jeu Un à quatre joueurs Plate forme … Wikipédia en Français
circuit breakers — Measures instituted by exchanges to stop trading temporarily when the market has fallen by a certain percentage in a specified period. They are intended to prevent a market free fall by permitting buy and sell orders to rebalance. Bloomberg… … Financial and business terms
circuit breakers — Rules created by the major stock exchanges and the SEC* to halt trading temporarily during periods of severe price fluctuations. These rules were created in response to BLACK MONDAY (1987), when the DJIA* fell over five hundred points in one day … American business jargon
circuit breakers — Measures put in place by the major stock and derivatives exchanges to prevent very large market movements; for example, suspending trading on a particular market when certain extreme price fluctuations take place. These provisions were first… … Big dictionary of business and management
Circuit total limitation — (CTL) is one of the present day standards for electrical panels sold in the United States according to the National Electrical Code. The 1965 edition of the NEC, article 384 15 was the first reference to the circuit total limitation of… … Wikipedia
circuit breaker — cir cuit break er, n. (Elec.) A device contained within an electrical circuit designed to interrupt the circuit when the current exceeds a preset value; it is sometimes called a
Circuit breaker (disambiguation) — Circuit breaker or Circuit breakers may refer to: Circuit breaker, an automatic electrical switch Circuit Breaker (Transformers), a Marvel Comics character Trading curb, a stock market term An alias of Richie Hawtin, an electronic musician and DJ … Wikipedia
circuit breaker — circuit breakers also circuit breaker N COUNT A circuit breaker is a device which can stop the flow of electricity around a circuit by switching itself off if anything goes wrong. There is an internal circuit breaker to protect the instrument… … English dictionary
circuit-breaker — ˈcircuit breaker [circuit breaker circuit breakers] noun a device that can automatically stop an electric current if it becomes dangerous … Useful english dictionary
Circuit breaker — For other uses, see Circuit breaker (disambiguation). An air circuit breaker for low voltage (less than 1000 volts) power distribution switchgear … Wikipedia
circuit breaker — 1. Elect. Also called breaker. a device for interrupting an electric circuit to prevent excessive current, as that caused by a short circuit, from damaging the apparatus in the circuit or from causing a fire. 2. any property tax relief measure… … Universalium
Как использовать шаблон Circuit Breaker в приложении Spring Boot
В этом посте я покажу, как мы можем использовать шаблон Circuit Breaker в приложении Spring Boot. Когда я говорю «шаблон Circuit Breaker» имеется в виду архитектурный шаблон автоматического выключателя. Netflix опубликовал библиотеку Hysterix для работы с автоматическими выключателями. В рамках этого поста я покажу, как мы можем использовать шаблон автоматического выключателя, используя библиотеку resilence4j в приложении Spring Boot.
Что такое автоматический выключатель?
Концепция автоматического выключателя пришла из электротехники. В большинстве электрических сетей автоматические выключатели представляют собой выключатели, которые защищают сеть от повреждений, вызванных перегрузкой по току или коротким замыканием.
Точно так же в программном обеспечении автоматический выключатель останавливает вызов удаленного сервиса, если мы знаем, что вызов этого сервиса либо завершится сбоем, либо истечет время ожидания. Преимущество этого подхода заключается в экономии ресурсов и упреждающем поиске и устранении неисправностей удаленных вызовов процедур.
Автоматический выключатель принимает решение об остановке вызова на основе предыдущей истории вызовов. Но есть альтернативные способы обработки вызовов. Обычно автоматический выключатель отслеживает предыдущие вызовы. Предположим, что 4 из 5 вызовов завершились неудачно или истекло время, тогда следующий вызов завершится ошибкой. Это помогает более активно обрабатывать ошибки при вызове сервиса, а сервис вызывающего абонента может обрабатывать ответ по-другому, предоставляя пользователям приложения что-то лучше, чем просто страницу с ошибкой.
Другой случай срабатывания автоматического выключателя — это, когда вызовы удаленного сервиса не работают в течение определенного времени. Автоматический выключатель сработает и не допустит следующего вызова, пока удаленное обслуживание не исправит ошибку.
Библиотека Resilience4J
У нас есть код, в котором мы вызываем удаленный сервис. Модуль автоматического выключателя из resilience4j библиотеки будет иметь лямбда-выражение для вызова удаленный сервис supplier для получения значений из вызова удаленного сервиса. Я покажу это на примере. Автоматический выключатель декорирует этот вызов удаленного обслуживания таким образом, чтобы он мог отслеживать ответы и состояния переключателя.
Различные конфигурации библиотеки Resilience4j
Чтобы понять концепцию автоматического выключателя, мы рассмотрим различные конфигурации, предлагаемые этой библиотекой.
failureRateThreshold() — настраивает порог частоты отказов в процентах. Если x процентов вызовов не работают, выключатель отключается.
slidingWindowSize() — эта настройка помогает определить количество вызовов, которые следует учитывать при включении автоматического выключателя.
slowCallRateThreshold() — настраивает порог низкой скорости вызова в процентах. Если x процентов вызовов являются медленными, автоматический выключатель отключается.
slowCallDurationThreshold — настраивает порог продолжительности времени, при котором вызовы считаются медленными.
minimumNumberOfCalls() — минимальное необходимое количество вызовов, перед которым автоматический выключатель может рассчитать частоту ошибок.
ignoreException() — этот параметр позволяет вам настроить исключение, которое автоматический выключатель может игнорировать и не будет учитываться при успешном или неудачном вызове удаленного сервиса.
COUNT-BASED автоматический выключатель
При использовании resilience4j библиотеки всегда можно использовать конфигурации по умолчанию, которые предлагает автоматический выключатель. Конфигурации по умолчанию основаны на типе COUNT-BASED скользящего окна.
Так как же нам создать автоматический выключатель для скользящего окна типа COUNT-BASED?
CircuitBreakerRegistry — фабрика по созданию выключателя.
Time-Based автоматический выключатель
Теперь об Time-Based автоматическом выключателе.
Пример автоматического выключателя в приложении Spring Boot
Мы рассмотрели необходимые понятия об автоматическом выключателе. Теперь я покажу, что мы можем использовать автоматический выключатель в приложении Spring Boot.
С другой стороны, в нашем приложении Circuitbreakerdemo есть контроллер с шаблоном thymeleaf, поэтому пользователь может получить доступ к приложению в браузере.
В демонстрационных целях я определил CircuitBreaker в отдельном компоненте, который я буду использовать в своем service классе.
BookStoreService будет содержать вызывающее приложение BooksApplication и отображать доступные книги. Этот сервис будет выглядеть так:
Поэтому, когда пользователь кликает на ссылку на главной странице, мы получаем книги из нашей REST-сервиса BooksApplication.
В этой демонстрации мы вызываем наш REST-сервис последовательно, но вызовы удаленного сервиса также могут происходить параллельно. Автоматический выключатель по-прежнему будет отслеживать результаты независимо от последовательных или параллельных вызовов.
Сначала я запускаю оба приложения и открываю домашнюю страницу Circuitbreakerdemo приложения. На главной странице есть ссылка для просмотра всех книг из магазина.
Теперь, чтобы смоделировать некоторые ошибки, я добавил следующий код в свой вызов RestTemplate, который в основном спит в течение 3 секунд, прежде чем вернуть результат вызова REST.
Теперь давайте переключим COUNT_BASED автоматический выключатель на TIME_BASED автоматический выключатель. В TIME_BASED автоматическом выключателе мы отключим наш REST-сервис через секунду, а затем щелкнем here ссылку с домашней страницы. Если 70 процентов вызовов за последние 10 секунд не работают, наш автоматический выключатель сработает.
Поскольку REST-сервис закрыт, мы увидим следующие ошибки в Circuitbreakdemo приложении
Мы увидим несколько ошибок до того, как автоматический выключатель будет в OPEN состоянии.
Еще одна конфигурация, которую мы всегда можем добавить, как долго мы хотим держать выключатель в разомкнутом состоянии. Для демонстрации я добавил, что автоматический выключатель будет в разомкнутом состоянии в течение 10 секунд.
Как обращаться с OPEN выключателями?
Вывод
В этой демонстрации я не рассмотрел, как отслеживать события выключателя, поскольку библиотека resilience4j позволяет сохранять эти события с метриками, которые можно отслеживать с помощью системы мониторинга.
Go Patterns. Circuit Breaker
Когда одна служба синхронно вызывает другую, всегда существует вероятность того, что другая служба недоступна или имеет такую высокую задержку, что она практически непригодна.
Драгоценные ресурсы, такие как потоки, могут быть использованы вызывающей стороной в ожидании ответа другой службы. Это может привести к исчерпанию ресурсов, из-за чего вызывающая служба не сможет обрабатывать другие запросы.
Сбой одного сервиса может потенциально каскадироваться с другими сервисами по всему приложению.
Stop doing it if it hurts
Клиент должен вызывать удаленный сервис через прокси-сервер, который функционирует аналогично автоматическому выключателю.
Когда количество последовательных сбоев пересекает пороговое значение, автоматический выключатель отключается, и в течение периода времени ожидания все попытки вызвать удаленную службу немедленно завершатся неудачей. После истечения времени ожидания автоматический выключатель пропускает ограниченное количество тестовых запросов. Если эти запросы выполнены успешно, выключатель возобновляет нормальную работу. В случае сбоя период ожидания начинается снова.
Circuit Breaker выступает как прокси-сервис между приложением и удаленным сервисом.
Circuit Breaker предотвращает попытки приложения выполнить операцию, которая скорее всего завершится неудачно, что позволяет продолжить работу дальше не тратя важные ресурсы, пока известно, что проблема не устранена. Приложение должно быстро принять сбой операции и обработать его.
В отличии от паттерна Retry, Circuit Breaker рассчитан на менее ожидаемые ошибки, которые могут длиться намного дольше: обрыв сети, отказ сервиса, оборудования…
В этих ситуациях при повторной попытке отправить аналогичный запрос с большой долей вероятности мы получим аналогичную ошибку.
3 состояния
Closed
Запрос от приложения направляется напрямую к сервису.
Счетчик ошибок = 0 и приложение спокойно функционирует.
Circuit Breaker увеличивает счетчик ошибок, если операция завершилась не успешно.
Если количество ошибок за некоторый промежуток времени превышает заранее заданный порог значений, то Circuit Breaker переходит в состояние Open и запускает таймер времени ожидания.
Когда таймер истекает, он переходит в состояние Half-Open.
Назначение таймера — дать сервису время для решения проблемы, прежде чем разрешить приложению попытаться выполнить операцию еще раз.
Запрос от приложения немедленно завершает с ошибкой и исключение возвращается в приложение.
Half-Open
Ограниченному количеству запросов от приложения разрешено обратиться к сервису. Если эти запросы успешны, то считаем что предыдущая ошибка исправлена и прокси-сервис переходит в состояние Closed (счетчик ошибок сбрасывается на 0).
Если любой из запросов завершился ошибкой, то считается, что ошибка все еще присутствует, тогда прокси-сервис возвращается в состояние Open и перезапускает таймер, чтобы дать системе дополнительное время на восстановление после сбоя.
Состояние Half-Open помогает предотвратить быстрый рост запросов к сервису. Т.к. после начала работы сервиса, некоторое время он может быть способен обрабатывать ограниченное число запросов до полного восстановления.
Приложение, вызывающее операцию через Circuit Breaker, должно быть подготовлено к обработке исключений, возникающих, если операция недоступна.
Способ обработки исключения будет зависеть от приложения. Например, приложение может временно понизить функциональность, вызвать альтернативную операцию для выполнения той же задачи или получения тех же данных или сообщить об исключении пользователю и попросить его повторить попытку позже.
Istio Circuit Breaker: отключаем неисправные контейнеры
Праздники завершились, и мы возвращаемся с нашим вторым постом из серии по Istio Service Mesh.
Сегодняшняя тема – Circuit Breaker, что в переводе на русский электротехнический означает «автоматический выключатель», в просторечии – «автомат защиты». Только в Istio этот автомат отключает не коротнувшую или перегруженную цепь, а неисправные контейнеры.
Как это должно работать в идеале
Когда микросервисы управляются Kubernetes’ом, например, в рамках платформы OpenShift, они автоматически масштабируется вверх-вниз в зависимости от нагрузки. Поскольку микросервисы работают в pod’ах, на одной конечной точке может быть сразу несколько экземпляров контейнеризированного микросервиса, а Kubernetes будет маршрутизировать запросы и балансировать нагрузку между ними. И – в идеале – все это должно прекрасно работать.
Как это работает на самом деле
А теперь представьте, что какой-то конкретный экземпляр микросервиса, то бишь контейнер, пришел в негодность: либо не отвечает (ошибка 503), либо – что неприятнее – реагирует, но слишком медленно. Иначе говоря, он подглючивает или не отвечает на запросы, но из пула он при этом автоматически не убирается. Что надо делать в этом случае? Повторить попытку? Убрать его из схемы маршрутизации? И что значит «слишком медленно» – сколько это в цифрах, и кто их определяет? Может быть, просто дать ему паузу и попробовать позднее? Если да, то насколько позднее?
Что такое Pool Ejection в Istio
И здесь на помощь приходит Istio со своими автоматами защиты Circuit Breaker, которые временно убирают неисправные контейнеры из пула ресурсов маршрутизации и балансировки нагрузки, реализуя процедуру Pool Ejection.
Используя стратегию обнаружения отклонений (outlier detection), Istio детектирует кривые pod’ы, которые выбиваются из общего ряда, и убирает их из пула ресурсов на заданное время, которое называется «окно сна» (sleep window).
Чтобы показать, как это работает в Kubernetes на платформе OpenShift, начнем со скриншота нормально работающих микросервисов из примера в репозитории Red Hat Developer Demos. Здесь у нас есть два pod’а, v1 и v2, в каждом из которых работает по одному контейнеру. Когда правила маршрутизации Istio не используются, Kubernetes по умолчанию применяет равномерно сбалансированную циклическую маршрутизацию:
Готовимся к сбою
Прежде чем делать Pool Ejection, надо создать правило маршрутизации Istio. Допустим, мы хотим распределять запросы между pod’ами в отношении 50/50. Кроме того, мы увеличим количество контейнеров v2 с одного до двух, вот так:
Теперь задаем правило маршрутизации, чтобы трафик распределялся между pod’ами в отношении 50/50.
А вот как выглядит результат работы этого правила:
Можно придраться, что на этом скрине не 50/50, а 14:9, но со временем ситуация выправится.
Устраиваем сбой
А теперь выведем из строя один из двух контейнеров v2, чтобы у нас был один исправный контейнер v1, один исправный контейнер v2 и один неисправный контейнер v2:
Чиним сбой
Итак, у нас есть неисправный контейнер, и настала пора Pool Ejection. С помощью очень простого конфига мы исключим этот сбойный контейнер из любых схем маршрутизации на 15 секунд в расчете на то, что он сам вернется в исправное состояние (либо перезапустится, либо восстановит производительность). Вот как выглядит этот конфиг и результаты его работы:
Как видно, неисправный контейнер v2 больше не используется при маршрутизации запросов, поскольку его убрали из пула. Но по истечении 15 секунд он автоматически вернется в пул. Собственно, мы только что показали, как работает Pool Ejection.
Начинаем строить архитектуру
Pool Ejection в сочетании с возможностями мониторинга Istio позволяет начать выстраивать фреймворк автоматической замены неисправных контейнеров, чтобы сократить, а то и вовсе устранить простои и сбои.
У NASA есть один громкий девиз – Failure Is Not an Option, автором которого считается руководитель полетов Джин Кранц. На русский его можно перевести как «Поражение – это не вариант», и смысл здесь в том, что всё можно заставить работать, имея на то достаточно воли. Однако в реальной жизни отказы не просто случаются, они неизбежны, везде и во всем. И как же с ними справляться в случае микросервисов? На наш взгляд, лучше полагаться не на силу воли, а на возможности контейнеров, Kubernetes, Red Hat OpenShift, и Istio.
Istio, как мы уже писали выше, реализует прекрасно зарекомендовавшую себя в физическом мире концепцию автоматических выключателей. И как электрический автомат отключает проблемный участок цепи, так и программный Circuit Breaker в Istio размыкает связь между потоком запросов и проблемным контейнером, когда с конечной точкой что-то не в порядке, например, когда сервер упал или начал тормозить.
Причем во втором случае проблем только больше, поскольку тормоза одного контейнера не только вызывают каскад задержек в обращающихся к нему сервисах и, как следствие, снижают производительность системы в целом, но и порождают повтор запросов к и так уже медленно работающему сервису, что только усугубляет ситуацию.
Circuit Breaker в теории
Circuit Breaker – это прокси, который контролирует поток к запросов к конечной точке. Когда эта точка перестает работать или – в зависимости от заданных настроек – начинает тормозить, прокси разрывает связь с контейнером. Трафик после этого перенаправляется на другие контейнеры, ну просто из-за балансировки нагрузки. Связь остается разомкнутой (open) на протяжении заданного окна сна, скажем, две минуты, а затем считается полуразомкнутой (half-open). Попытка отправить следующий запрос определяет дальнейшее состояние связи. Если с сервисом все ОК, связь возвращается в рабочее состояние и опять становится замкнутой (closed). Если же с сервисом по-прежнему что-то не то, связь размыкается и заново включается окно сна. Вот как выглядит упрощенная диаграмма смены состояний Circuit Breaker:
Здесь важно отметить, что все это происходит на уровне, так сказать, системной архитектуры. Поэтому в какой-то момент вам придется научить свои приложения работать с Circuit Breaker, например, предоставлять в ответ значение по умолчанию или же, если это возможно, игнорировать существование сервиса. Для этого используется bulkhead pattern, но он выходит за рамки этой статьи.
Circuit Breaker на практике
Для примера мы запустим на OpenShift две версии нашего микросервиса рекомендаций. Версия 1 будет работать нормально, а вот в v2 мы встроим задержку, чтобы имитировать тормоза на сервере. Для просмотра результатов используется инструмент siege:
Все вроде бы работает, но какой ценой? На первый взгляд у нас 100 % доступность, но присмотритесь – максимальная длительность транзакции составляет целых 12 секунд. Это явно узкое место, и его надо расшивать.
Для этого мы с помощью Istio исключим обращения к медленным контейнерам. Вот как выглядит соответствующий конфиг с использованием Circuit Breaker:
Последняя строка с параметром httpMaxRequestsPerConnection сигнализирует, что связь с должна размыкаться при попытке создать еще одно – второе – подключение вдобавок к уже имеющемуся. Поскольку наш контейнер имитирует тормозящий сервис, такие ситуации будут периодически возникать, и тогда Istio будет возвращать ошибку 503, а вот что покажет siege:
ОК, у нас есть Circuit Breaker, что дальше?
Итак, мы реализовали автоматическое отключение, совершенно не трогая исходный код самих сервисов. Используя Circuit Breaker и описанную выше процедуру Pool Ejection, мы можем убирать из пула ресурсов тормозные контейнеры до тех пор, пока они не придут в норму, и проверять их состояние с заданной периодичностью – в нашем примере, это две минуты (параметр sleepWindow).
Обратите внимание, что способность приложения реагировать на ошибку 503 все еще задается на уровне его исходного кода. Существует множество стратегий работы с Circuit Breaker, которые применяются в зависимости от ситуации.
В следующем посте: расскажем о трассировке и мониторинге, которые уже встроены или легко добавляются в Istio, а также о том, как вносить ошибки в систему намеренно.
