Shulou(Shulou.com)06/03 Report--

This article will explain in detail how the mechanism of Node.js interrupter is for you. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

Problems caused by the evolution of architecture

When we use the traditional CS architecture, the server will block the request due to failure and other reasons, which may cause the client's request to lose response, and then lead to a group of users can not get the service after a period of time. The scope of impact of this situation may be limited and can be predicted.

However, under the micro-service system, your server may rely on several other micro-services, which in turn rely on other micro-services, in which case, the downstream congestion of a service may happen instantly (within seconds) because the consumption of cascading resources can cause catastrophic consequences on the entire link, which we call "service blood collapse". [recommended: "nodejs tutorial"]

Several ways to solve the problem

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

Isolation mode: divide the calls of different resources or services into several different request pools. The depletion of resources in one pool will not affect the requests of other resources, preventing a single point of failure from consuming all resources. This is a very traditional disaster recovery design.

Current limiting mode: circuit breaker and isolation are both a way to deal with the problem afterwards, while the current limiting mode can reduce the probability of problems before they occur. The current limit mode can set a highest QPS threshold for requests for some services. Requests that exceed the threshold are returned directly and no longer take up resources for processing. However, the current-limiting mode can not solve the problem of service avalanche, because it is often caused not because of the large number of requests, but because of the amplification of multiple cascade layers.

Mechanism and implementation of Circuit Breaker

The existence of circuit breakers gives us a layer of assurance that when calling services and resources that are not stable, or are likely to call failed 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 judge and resume the normal request.

Let's take a look at a request process without a circuit breaker: the user relies on ServiceA to provide the service, and ServiceA relies on the service provided by ServiceB. Suppose ServiceB fails at this time, and the response is delayed by 10 seconds for each request within 10 minutes.

So suppose we have N User requesting the service of ServiceA, and within seconds, the resources of ServiceA will be exhausted because the request to ServiceB is suspended, thus rejecting any request after User. For users, this means that both ServiceA and ServiceB failed at the same time, causing the collapse of the entire service link.

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

After the number of failures reaches a certain threshold, the circuit breaker will find that the request for ServiceB is no longer valid, so ServiceA does not need to continue to request ServiceB, but directly returns the failure, or uses the backup data of other Fallback. At this point, the circuit breaker is in an open state.

After a period of time, the circuit breaker will start to regularly query whether the ServiceB has been restored, at this time, the circuit breaker is in a half-open state.

If ServiceB has been restored, the circuit breaker will be turned off, and ServiceA will call ServiceB normally and return the result.

The state diagram of the circuit breaker is as follows:

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

Timeout: how long the request reaches, it causes a failure

Failure threshold: the number of failures that need to be reached before the circuit breaker triggers the open circuit

Retry timeout: when the circuit breaker is in the open state, how often does it start to retry the request, that is, to 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',}); / / Yayflowers! The API responded fine. Lets reset everything. This.reset (); return response;} catch (err) {/ / Uhmurohtogether! 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 features:

/ / 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 a circuit breaker, you only need to wrap the request in the Call method in the circuit breaker instance and call it:

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 mature Node.js circuit breaker implementation called Opossum a long time ago, and 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 blood collapse.

This is the end of this article on "what the Node.js interrupter mechanism is like". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.