Node.js의 회로 차단기 메커니즘에 대한 심층 분석

이 기사는 Node.js의 회로 차단기 메커니즘을 안내합니다. 도움이 되기를 바랍니다.

아키텍처 진화로 인한 문제

기존 CS 아키텍처를 사용하면 서버가 장애 등의 이유로 요청을 차단하여 클라이언트의 요청이 응답하지 않게 되어 일괄 처리가 발생하게 됩니다. 일정 시간이 지나면 사용자가 서비스를 받을 수 없습니다. 이 상황으로 인해 발생할 수 있는 영향은 제한적이며 추정할 수 있습니다.

그러나 마이크로서비스 시스템에서는 서버가 여러 다른 마이크로서비스에 의존할 수 있고, 이러한 마이크로서비스는 차례로 다른 마이크로서비스에 의존할 수 있습니다. 이 경우 특정 서비스가 순간적으로(몇 초 내에) 다운스트림 정체를 일으킬 수 있기 때문입니다. 계단식 리소스 소비는 전체 링크에 치명적인 결과를 초래합니다. 이를 "서비스 붕괴"라고 부릅니다. [추천 학습: "nodejs 튜토리얼"]

문제를 해결하는 여러 가지 방법

• 퓨즈 모드: 이름에서 알 수 있듯이 가정용 회로와 마찬가지로 선의 전압이 너무 높으면 화재를 예방하기 위해 퓨즈가 끊어집니다. 서킷 브레이커 모드를 사용하는 시스템에서 업스트림 서비스 호출이 느리거나 타임아웃 횟수가 많은 것으로 확인되면 해당 서비스에 대한 호출을 직접 종료하고 정보를 직접 반환하며 리소스를 해제합니다. 빠르게. 업스트림 서비스가 개선될 때까지 통화는 재개되지 않습니다.

• 격리 모드: 다양한 리소스 또는 서비스에 대한 호출을 여러 요청 풀로 나눕니다. 한 풀의 리소스가 소진되어도 다른 리소스에 대한 요청에 영향을 주지 않으므로 단일 실패 지점이 모든 리소스를 소비하는 것을 방지할 수 있습니다. 이는 매우 전통적인 재해 복구 설계입니다.
• 전류 제한 모드: 퓨즈와 절연은 모두 후처리 방법입니다. 전류 제한 모드는 문제가 발생하기 전에 문제가 발생할 가능성을 줄일 수 있습니다. 현재 제한 모드는 특정 서비스에 대한 요청에 대해 최대 QPS 임계값을 설정할 수 있습니다. 임계값을 초과하는 요청은 직접 반환되며 더 이상 처리를 위한 리소스를 차지하지 않습니다. 그러나 현재의 제한 모드로는 서비스 붕괴 문제를 해결할 수 없습니다. 왜냐하면 서비스 붕괴는 많은 요청이 아닌 여러 캐스케이드 계층의 증폭으로 인해 발생하는 경우가 많기 때문입니다.

회로 차단기의 메커니즘과 구현

회로 차단기의 존재는 우리에게 보호 계층을 제공하는 것과 같습니다. 안정적이지 않거나 실패할 가능성이 있는 서비스 및 리소스를 호출할 때 회로 차단기는 이를 모니터링할 수 있습니다. 리소스의 과도한 소비를 방지하기 위해 특정 임계값에 도달하면 오류를 발생시키고 요청을 실패시킵니다. 또한 서킷 브레이커는 서비스 상태를 자동으로 파악해 복구하는 기능도 갖고 있다. 업스트림 서비스가 정상으로 돌아오면 서킷 브레이커는 자동으로 정상적인 요청을 판단해 재개할 수 있다.

서킷 브레이커가 없는 요청 프로세스를 살펴보겠습니다. 사용자는 ServiceA에 의존하여 서비스를 제공하고 ServiceA는 ServiceB에 의해 제공되는 서비스에 의존합니다. 이때 ServiceB가 10분 이내에 실패한다고 가정합니다. 응답이 10초 지연되었습니다.

ServiceA의 서비스를 요청하는 N명의 사용자가 있다고 가정해 보겠습니다. 몇 초 내에 ServiceB에 대한 요청이 중단되어 ServiceA의 리소스가 소비되어 사용자의 후속 요청이 거부됩니다. 사용자의 경우 이는 ServiceA와 ServiceB가 동시에 실패하여 전체 서비스 링크가 붕괴되었음을 의미합니다.

ServiceA에 차단기를 설치하면 어떻게 되나요?

• 실패 횟수가 특정 임계값에 도달한 후 회로 차단기는 ServiceB에 대한 요청이 유효하지 않음을 발견합니다. 이때 ServiceA는 ServiceB를 계속 요청할 필요가 없으며 직접 실패를 반환하거나 다른 Fallback을 사용합니다. 백업 데이터. 이때 차단기는 개방회로 상태입니다.

• 일정 시간이 지나면 차단기는 ServiceB가 복원되었는지 주기적으로 쿼리하기 시작합니다. 이때 차단기는 half-open 상태입니다.

• ServiceB가 복원되면 회로 차단기는 off 상태가 됩니다. 이때 ServiceA는 정상적으로 ServiceB를 호출하고 결과를 반환합니다.

회로 차단기의 상태 다이어그램은 다음과 같습니다.

회로 차단기의 여러 핵심 지점은 다음과 같다는 것을 알 수 있습니다.

• Timeout: 요청이 지속되는 기간 오류가 발생하기 전에

• 실패 임계값: 회로 차단기가 개방 회로를 트리거하기 전에 도달해야 하는 오류 수

• 재시도 시간 초과: 회로 차단기가 개방 회로 상태에 있을 때 요청 재시도를 시작하는 데, 즉 반 개방 상태로 들어가는 데 걸리는 시간

이 지식을 바탕으로 다음을 만들 수 있습니다. 회로 차단기:

class CircuitBreaker {
  constructor(timeout, failureThreshold, retryTimePeriod) {
    // We start in a closed state hoping that everything is fine
    this.state = 'CLOSED';
    // Number of failures we receive from the depended service before we change the state to 'OPEN'
    this.failureThreshold = failureThreshold;
    // Timeout for the API request.
    this.timeout = timeout;
    // Time period after which a fresh request be made to the dependent
    // service to check if service is up.
    this.retryTimePeriod = retryTimePeriod;
    this.lastFailureTime = null;
    this.failureCount = 0;
  }
}

회로 차단기 구성 상태 머신:

async call(urlToCall) {
    // Determine the current state of the circuit.
    this.setState();
    switch (this.state) {
      case 'OPEN':
      // return  cached response if no the circuit is in OPEN state
        return { data: 'this is stale response' };
      // Make the API request if the circuit is not OPEN
      case 'HALF-OPEN':
      case 'CLOSED':
        try {
          const response = await axios({
            url: urlToCall,
            timeout: this.timeout,
            method: 'get',
          });
          // Yay!! the API responded fine. Lets reset everything.
          this.reset();
          return response;
        } catch (err) {
          // Uh-oh!! the call still failed. Lets update that in our records.
          this.recordFailure();
          throw new Error(err);
        }
      default:
        console.log('This state should never be reached');
        return 'unexpected state in the state machine';
    }
  }

보조 나머지 기능:

// reset all the parameters to the initial state when circuit is initialized
  reset() {
    this.failureCount = 0;
    this.lastFailureTime = null;
    this.state = 'CLOSED';
  }

  // Set the current state of our circuit breaker.
  setState() {
    if (this.failureCount > this.failureThreshold) {
      if ((Date.now() - this.lastFailureTime) > this.retryTimePeriod) {
        this.state = 'HALF-OPEN';
      } else {
        this.state = 'OPEN';
      }
    } else {
      this.state = 'CLOSED';
    }
  }

  recordFailure() {
    this.failureCount += 1;
    this.lastFailureTime = Date.now();
  }

회로 차단기를 사용할 때 회로 차단기 인스턴스의 Call 메서드에 요청을 래핑하고 호출하기만 하면 됩니다.

...
const circuitBreaker = new CircuitBreaker(3000, 5, 2000);

const response = await circuitBreaker.call('http://0.0.0.0:8000/flakycall');

성숙한 Node.js 회로 차단기 라이브러리

Red Hat은 오랫동안 Opossum이라는 성숙한 Node.js 회로 차단기 구현을 만들었습니다. 링크는 Opossum입니다. 분산 시스템의 경우 이 라이브러리를 사용하면 서비스의 내결함성을 크게 향상시키고 서비스 실패 문제를 근본적으로 해결할 수 있습니다.

원본 주소: https://juejin.cn/post/70192173444601948173

작성자: ES2049 / Looking for Singularity

더 많은 프로그래밍 관련 지식을 보시려면 프로그래밍 영상을 방문해 주세요! !

위 내용은 Node.js의 회로 차단기 메커니즘에 대한 심층 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!