Speaking of the springcloud circuit breaker reminds me of the circuit breaker in the stock market last year, and I have experienced many painful realizations that the impact of random circuit breakers on the entire system is catastrophic. Well, let's get down to business.
fuse
Avalanche effect
In a microservice architecture, there are usually multiple service layer calls, and the failure of basic services may lead to cascading failures, resulting in the unavailability of the entire system. This phenomenon is called the service avalanche effect. The service avalanche effect is a process in which the unavailability of "service providers" leads to the unavailability of "service consumers" and gradually enlarges the unavailability.
If the following figure is shown: A is the service provider, B is the service consumer of A, and C and D are the service consumers of B. The unavailability of A causes the unavailability of B, and when the unavailability snowballs to C and D, the avalanche effect is formed.
Fuse (CircuitBreaker)
The principle of a fuse is very simple, like a power overload protector. It can implement fail-fast, if it detects many similar errors over a period of time, it forces multiple subsequent calls to fail-fast and no longer access the remote server, preventing the application from constantly trying to perform operations that might fail , allowing the application to continue executing without waiting for errors to be fixed, or wasting CPU time waiting for a long timeout to occur. Circuit breakers can also enable the application to diagnose whether the error has been fixed, and if so, the application will try to invoke the operation again.
The circuit breaker pattern is like a proxy for operations that are prone to errors. Such a proxy can record the number of times an error occurred on the most recent call, and then decide to continue with the allow operation, or return the error immediately. The logic of the mutual conversion of fuse switches is as follows:
The fuse is the last line of defense to protect the high availability of services.
Hystrix Features
1. Circuit breaker mechanism
The circuit breaker is well understood. When the number of failures of Hystrix Command requests to the backend service exceeds a certain percentage (default 50%), the circuit breaker will switch to the open state (Open). At this time, all requests will fail directly and will not be sent to the backend service. . After the circuit breaker remains in the open state for a period of time (default 5 seconds), it will automatically switch to the half-open state (HALF-OPEN). At this time, the return of the next request will be judged. If the request is successful, the circuit breaker will switch back to the closed state ( CLOSED), otherwise it switches back to the open state (OPEN). Hystrix's circuit breaker is like a fuse in our home circuit. Once the backend service is unavailable, the circuit breaker will directly cut off the request chain, avoiding sending a large number of invalid requests to affect the system throughput. , and the circuit breaker has the ability to self-detect and recover.
2.Fallback
Fallback is equivalent to a downgrade operation. For query operations, we can implement a fallback method. When an exception occurs in the request back-end service, the value returned by the fallback method can be used. The return value of the fallback method is generally the default value set or from the cache.
3. Resource isolation
In Hystrix, resource isolation is mainly achieved through thread pools. Usually, we divide multiple thread pools according to the remote services called. For example, the Command that calls the product service is placed in the A thread pool, and the Command that calls the account service is placed in the A thread pool. Enter the B thread pool. The main advantage of this is that the running environment is isolated. Even if the code that calls the service has bugs or the thread pool in which it is located is exhausted for other reasons, it will not affect other services of the system. But the cost is that maintaining multiple thread pools will bring additional performance overhead to the system. If you have strict performance requirements and you are sure that the client code that calls the service will not have problems, you can use Hystrix's signal mode ( Semaphores) to isolate resources.
Feign Hystrix
Because the circuit breaker only acts on the service call side, we only need to change the relevant code of the spring-cloud-consumer project according to the sample code in the previous article. Because Feign already relies on Hystrix, there is no need to make any changes to the maven configuration.
1. Configuration file
Add this to application.properties:
feign.hystrix.enabled=true
2. Create a callback class
Create a HelloRemoteHystrix class to inherit and implement callback methods with HelloRemote
@Component public class HelloRemoteHystrix implements HelloRemote{ @Override public String hello(@RequestParam(value = "name") String name) { return "hello" +name+", this messge send failed "; } }
3. Add fallback attribute
Add the HelloRemotespecified fallback class to the class, and return the content of the fallback class when the service is blown.
@FeignClient(name= "spring-cloud-producer",fallback = HelloRemoteHystrix.class) public interface HelloRemote { @RequestMapping(value = "/hello") public String hello(@RequestParam(value = "name") String name); }
Just change this, it's easy.
4. Test
Then let's test it and see the effect.
Start the three projects spring-cloud-eureka, spring-cloud-producer, and spring-cloud-consumer in sequence.
Enter in the browser:http://localhost:9001/hello/neo
return:hello neo，this is first messge
Note that adding fuse-related information does not affect normal access. Next we manually stop the spring-cloud-producer project and test again:
Enter in the browser:http://localhost:9001/hello/neo
return:hello neo, this messge send failed
According to the returned result, the fusing is successful.