An in-depth analysis of the circuit breaker mechanism in Node.js

This article will take you through the circuit breaker mechanism in Node.js, I hope it will be helpful to you!

Problems caused by architecture evolution

When we use the traditional CS architecture, the server blocks requests due to failures and other reasons, which may cause customers to The client's request loses response, resulting in a group of users being unable to obtain services after a period of time. The possible impact of this situation is limited and can be estimated.

However, in a microservice system, your server may depend on several other microservices, and these microservices depend on more other microservices. In this case, a certain service may cause downstream congestion. , which may cause catastrophic consequences on the entire link due to cascading resource consumption in an instant (within seconds), which we call "service collapse". [Recommended learning: "nodejs Tutorial"]

##Several ways to solve problems

• Fuse mode: As the name suggests, just like household circuits, if the voltage of a line is too high, the fuse will blow to prevent fire. In a system using the circuit breaker mode, if it is found that the upstream service call is slow or there are a large number of timeouts, the call to the service will be directly terminated, information will be returned directly, and resources will be released quickly. The call will not be resumed until the upstream service improves.

Isolation mode: Divide calls for different resources or services into several different request pools. Exhaustion of resources in one pool will not affect requests for other resources, preventing a single point. The failure consumes all resources. This is a very traditional disaster recovery design.
• Current limiting mode: Circuit breaker and isolation are both post-processing methods. Current limiting mode can reduce the probability of problems before they occur. The current limiting mode can set a maximum QPS threshold for requests for certain services. Requests that exceed the threshold are returned directly and no longer occupy resources for processing. However, the current limiting mode cannot solve the problem of service collapse, because the collapse is often caused not by the large number of requests, but by the amplification of multiple cascade layers.

The mechanism and implementation of the circuit breaker

The existence of the circuit breaker is equivalent to giving us a layer of protection. When the call stability is poor, or the call is likely to fail, For services and resources, circuit breakers can monitor these errors and fail requests after reaching a certain threshold to prevent excessive consumption of resources. In addition, the circuit breaker also has the function of automatically identifying the service status and restoring it. When the upstream service returns to normal, the circuit breaker can automatically determine and resume normal requests.

Let us take a look at a request process without a circuit breaker: The user relies on ServiceA to provide services, and ServiceA relies on the services provided by ServiceB. Assume that ServiceB fails at this time. Within 10 minutes, for each request There will be a 10 second delay in response.

So suppose we have N Users requesting the service of ServiceA. Within a few seconds, the resources of ServiceA will be consumed because the request to ServiceB is suspended. Empty, thereby rejecting any subsequent requests from the User. For users, this means that both ServiceA and ServiceB failed at the same time, causing the entire service link to collapse.

And what happens when we install a circuit breaker on ServiceA?

• After the number of failures reaches a certain threshold, the circuit breaker will find that the request to ServiceB is invalid. At this time, ServiceA does not need to continue to request ServiceB, but directly returns failure, or Use backup data from other Fallbacks. At this time, the circuit breaker is in the

  open circuit state.

• After a period of time, the circuit breaker will start to periodically query whether ServiceB has been restored. At this time, the circuit breaker is in the

  half-open state.

• If ServiceB has recovered, the circuit breaker will be placed in the

  closed state. At this time, ServiceA will call ServiceB normally and return the result.

The status diagram of the circuit breaker is as follows:

It can be seen that the circuit breaker Several core points are as follows:

• Timeout: how long the request reaches before it causes a failure

• Failure threshold: that is, the circuit breaker triggers an open circuit Before, the number of failures required

• Retry timeout: When the circuit breaker is in the open circuit state, how long does it take to retry the request, that is, enter the half-open state

With this knowledge, We can try to create a circuit breaker:

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;
  }
}

Construct the state machine of the circuit breaker:

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';
    }
  }

Supplement the remaining functions:

// 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();
  }

When using the circuit breaker, you only need to wrap the request Just call it in the Call method in the circuit breaker instance:

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

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

Mature Node.js circuit breaker library

Red Hat created a long time ago called Opossum Mature Node.js circuit breaker implementation, the link is here: Opossum. For distributed systems, using this library can greatly improve the fault tolerance of your service and fundamentally solve the problem of service failure.

Original address: https://juejin.cn/post/7019217344601948173

Author: ES2049 / Looking for Singularity

More programming related knowledge , please visit: programming video! !

The above is the detailed content of An in-depth analysis of the circuit breaker mechanism in Node.js. For more information, please follow other related articles on the PHP Chinese website!