차단기 모드

응용 프로그램은 어떻게 실패를 처리합니까?첫 번째 수준의 응답은 오류를 기록하고 표시하는 데 중심을 둘 수 있지만, 문제를 해결하는 것이 아니라 문제를 포착하는 것입니다.
중요한 서비스가 오프라인 상태이거나 과부하인 경우 어떻게 됩니까?만약 네가 바라는 기준에 도달하지 못했을 뿐이라면?
응용 프로그램은 제3자 API 같은 제어할 수 없는 서비스에 더 많이 의존하기 때문에 이러한 변수가 나타날 때 이러한 변수를 처리하는 수요가 더욱 중요해진다.

회로 차단기에 들어가다

차단기는 고장이 검출되었을 때 전력 흐름을 중단함으로써 회로나 전기 설비의 손상을 방지하는 메커니즘이다.
소프트웨어에서 이 개념은 서비스의 가용성을 측정하고 문제가 해결될 때까지 응용 프로그램이 끊임없이 실패한 요청을 하는 것을 방지할 수 있다.Martin Fowler 는 his article on the subject 에서 다음과 같이 설명했습니다.

The basic idea behind the circuit breaker is very simple. You wrap a protected function call in a circuit breaker object, which monitors for failures. Once the failures reach a certain threshold, the circuit breaker trips, and all further calls to the circuit breaker return with an error, without the protected call being made at all.

회로는 세 가지 상태로 설명하는 것이 가장 좋다.
닫기: 닫기 상태는 기본적으로 모든 정상 상태입니다.요청은 자유롭게 통과할 수 있다.

열기: 열기 상태는 모든 요청을 거부하고 보내지 않습니다.

반개방: 자원의 상태를 테스트하기 위해 일정 수량의 요청을 통과할 수 있습니다.이 상태는 회로가 다시 닫히는지 끊기는지 확인합니다.

이러한 상태는 미리 설정된 표준(임계값)에 따라 달라집니다. 이 표준에는 주어진 시간 범위 내의 오류율, 지연, 유량, 심지어 자원 이용률까지 포함될 수 있습니다.노드에 사용되는 opossum 같은 많은 차단기 라이브러리js, 한도값 지표의 조합을 설정의 일부분으로 정의할 수 있습니다.

정확한 임계값 표준 결정

한도값 표준은 여러 가지 형식이 있을 수 있다.속도가 중요한 API의 경우 지연 시간이 핵심 임계값일 수 있습니다.사용자 계정의 API를 처리하는 데 있어 가동 시간은 더욱 중요합니다.
API 호출을 분석하여 이러한 결정을 내릴 수 있습니다.만약 당신이 아직 모니터링 해결 방안이 없다면, 최초의 몇 가지 시도에서 이것이 어려운 임무일 수도 있음을 확정하는 것이다.또는 Bearer Agent 같은 도구를 사용하여 API 호출을 자동으로 모니터링하고 기록할 수 있습니다.그런 다음 데이터를 분석하고 이벤트 알림을 설정할 수 있습니다.이것은 당신의 차단기 결정을 알리는 데 좋은 기초를 제공했다.
우리 기본적인 예를 하나 봅시다.응용 프로그램에 함수가 있다고 가정하면 특정 사용자의 게시물getPosts을 되돌려줍니다.타사 API 클라이언트apiClient의 패키지입니다.차단기를 실현하기 위해서 우리는 유행하는 라이브러리를 사용하자.
다람쥐 중에서 이것은 대략 다음과 같다.

// Require the library and client
const circuitBreaker = require("opossum")
const apiClient = require("our-example-api-client")

// Our example request
const getPosts = (req, res, next) => {
  // Wrap our client get method in the circuit breaker
  const breaker = circuitBreaker(apiClient.get, {
    timeout: 3000,
    errorThresholdPercentage: 50,
    resetTimeout: 5000
  })

  // Call the API from within the circuit breaker
  return breaker
    .fire("/api/posts")
    .then(res.json)
    .catch(next)
}

이제 타사 API의 /api/posts 노드에 문제가 발생하면 차단기가 스크롤 평가 창을 시작합니다.그것은 모든 호출의 유효성을 포착하고 문제가 발생하면 차단기를 촉발한다.
구성 객체를 사용하면 요청 제한 시간(3초), 오류 임계값 백분율(50%) 및 차단기 열기 상태를 반 열기로 변환하는 재설정 제한 시간을 설정할 수 있습니다.(5초).이런 유형의 차단기 라이브러리는 매우 흔하다.

고장에 반응하다

차단기는 재시도를 늦추고 불필요한 요청을 방지하는 데 유용하지만, 진정한 힘은 프로그램이 차단기의 상태에 어떻게 반응하는가에 있다.
기존 라이브러리는 이 점을 실현하는 데 도움을 줄 수 있다.예를 들어 다람쥐는 차단기의 고장 상태를 촉발할 때 리턴 기능을 실행할 수 있습니다.또는 보낸 이벤트에 응답할 수 있습니다.
이렇게 하면 애플리케이션에서 다음 작업을 수행할 수 있습니다.

운영 API가 종료되거나 로드가 부족한 경우 대체 API를 호출합니다.

이전 응답에서 캐시 데이터를 반환하고 사용자에게 알립니다.

사용자에게 피드백을 제공하고 백그라운드에서 다시 시도합니다.

문제를 기본 로깅 서비스에 기록합니다.

응용 프로그램에서 차단기를 실행해야 합니까?

물론외부 API로 인한 불확실성은 애플리케이션의 기술 채무를 빠르게 증가시킵니다.경험증에 의존하는 모델 (예를 들어 차단기) 을 통해 당신의 팀은 응용 프로그램에서 탄력적이고 우아한 강등을 구축할 수 있습니다.본고는 주로 외부 API를 주목하지만 이러한 모델은 당신의 내부 마이크로서비스가 응용 프로그램의 실패를 초래하지 않도록 하는 좋은 방법을 제공합니다.
이 문서에서는 노드와 브라우저의 opossum 에 대해 간략하게 설명하지만, 대부분의 언어에는 사용할 수 있는 커뮤니티 라이브러리가 있습니다.

circuit_breaker 또는 simple_circuit는 Ruby

를 나타냅니다.

go-circuitbreaker Go

circuitbreaker Python

의 경우
사용Microsoft's Guide to Circuit Breakers과 Martin Fowler's original post 자신의 모델과 전략을 실현하는 데 대한 더 많은 정보를 읽으십시오.
📢 The Circuit Breaker Pattern Bearer 블로그에 최초 게시.