Spring Cloud Eight: Service Fault tolerant protection (Hystrix circuit Breaker) "version Dalston"

Circuit Breaker

The circuit breaker model originates from Martin Fowler's circuit breaker. "Circuit Breaker" itself is a switch device, used in the circuit to protect the line overload, when the circuit has a short circuit, "circuit breaker" can timely cut off the fault circuit, to prevent the occurrence of overload, heat, and even fire serious consequences.

In a distributed architecture, the role of the circuit breaker mode is similar, when a service unit fails (similar to a short-circuit with electrical appliances), through the fault monitoring of the circuit breaker (similar to the fuse fuse), directly cut off the original main logic call. However, in the Hystrix circuit breaker in addition to cutting off the function of the main logic, there are more complex logic, below we look at its deeper processing logic.

Example of a service downgrade implemented in the article "Building MicroServices Architecture in Spring Cloud: Service Fault tolerance protection (hystrix service degradation)", let's say how the circuit breaker works. When we add the service provider to the eureka-client latency of the simulation, the service degradation logic on the consumer side of the service triggers the downgrade logic because the Hystrix command invokes the dependent service timeout, but even then, due to the problem of hystrix time-out, our calls are still likely to accumulate.

This time the circuit breaker will play a role, then the circuit breaker in what circumstances began to function? Here are three important parameters of a circuit breaker: the snapshot window, the lower total number of requests, and the lower error percentage. The function of this parameter is:

• Snapshot time window: The circuit breaker determines whether to open the need to count some requests and error data, and the time range of the statistics is the snapshot time window, the default is the last 10 seconds.
• Minimum number of requests: Within the snapshot time window, the minimum total number of requests must be met to qualify for the fuse. The default is 20, which means that in 10 seconds, if the call to the Hystrix command is less than 20 times, all requests are timed out or other reasons fail, and the circuit breaker will not open.
• Error percent lower limit: When the total number of requests in the snapshot time window exceeds the lower limit, such as 30 calls, if in these 30 calls, 16 times the time-out exception, that is, more than 50% error percentage, at the default setting of 50% lower limit, this time the circuit breaker will open.

So what happens when the breaker is open? Let's say that before the circuit breaker is not open, the case for the previous example is that each request is returned after the Hystrix timeout, fallback each request time delay is approximate hystrix timeout, and if set to 5 seconds, then each request will be delayed by 5 seconds to return. When the fuse finds that the total number of requests exceeds 20 in 10 seconds and the error percentage exceeds 50%, the fuse is turned on at this time. When the request is opened, the main logic is not invoked, but the demotion logic is called directly, and this time it does not wait 5 seconds before returning to fallback. Through the circuit breaker, the automatic discovery error is realized and the downgrade logic is switched to primary logic, which reduces the effect of response delay.

After the circuit breaker is open, the processing logic is not over, and our downgrade logic has become the main logic, so how to restore the original master logic? For this problem, Hystrix also realized the automatic recovery function for us. When the circuit breaker opens, the main logic of the fuse, Hystrix will start a sleep time window, in this time window, the demotion logic is temporary into the primary logic, when the sleep time window expires, the circuit breaker will enter the semi-open state, release a request to the original master logic, if the request returned normally, Then the circuit breaker will continue to close, master logic recovery, if the request still has a problem, the circuit breaker continues to enter the open state, the Sleep time window re-timed.

Through a series of mechanisms above, the Hystrix circuit breaker realizes the port of dependent resource failure, automatic switching of downgrade policy and the mechanism of automatic recovery of main logic. This enables our microservices to be very well protected when relying on external services or resources, while automating switchover and recovery for some business requirements with degraded logic, which is smarter and more efficient than the traditional way of setting switches from monitoring and operation to switching.

Reference:

http://blog.didispace.com/spring-cloud-starter-dalston-4-3/

Spring Cloud Eight: Service Fault tolerant protection (Hystrix circuit Breaker) "version Dalston"