Springcloud Distributed micro-Service (iv): Fuse hystrix

Fuse Avalanche effect

In a microservices architecture, there are often multiple service layer calls, and the failure of the underlying service can lead to cascading failures that could result in an entire system being unavailable, a phenomenon known as service avalanche effect. The service avalanche effect is a process in which the service consumer is not available and will not be usable due to the unavailability of the service provider.

If: A serves as a service provider, B is a service consumer, and C and D are service consumers of B. A unavailability causes the unavailability of B and will not be available as a snowball to C and D, the avalanche effect is formed.

Fusing Device (Circuitbreaker)

The fuse principle is simple, like a power overload protector. It can achieve rapid failure, and if it detects many similar errors over time, it forces its subsequent calls to fail quickly and no longer accesses the remote server, preventing the application from continually trying to perform operations that might fail, allowing the application to continue without waiting for remediation errors. Or waste CPU time to wait for a long time-out to occur. The fuse can also enable the application to diagnose if the error has been corrected, and if it has been corrected, the application will try to invoke the operation again.

The fuse mode is like a proxy for operations that are prone to errors. This agent can record the number of times a recent call has occurred, and then decide to continue with the allow operation, or return an error immediately. The logic for switching the fuse switches to each other is as follows:

A fuse is the last line of defense for high-availability protection services.

Hystrix characteristics

1. Circuit breaker mechanism

Circuit Breaker It's good to understand that when the Hystrix command requests a backend service failure quantity exceeding a certain percentage (default 50%), the circuit breaker switches to the open State (open). At this point, all requests fail directly and are not sent to the backend service. The circuit breaker remains in the open state for some time (default 5 seconds), automatically switches to the semi-open state (Half-open). This will determine the return of the next request, if the request succeeds, the circuit breaker is switched back to the closed circuit (CLOSED), or re-switch to open mode (open). Hystrix 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, avoid sending a large number of invalid requests affecting 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 the query operation, we can implement a fallback method that can use the value returned by the fallback method when the backend service is requested to have an exception. The return value of the fallback method is typically the default value for the setting or from the cache.

3. Resource Isolation

In Hystrix, resource isolation is achieved primarily through the thread pool. Usually when used, we divide multiple thread pools according to the invocation of the remote service. For example, call the command of the product service into the a thread pool and call the command of the account service into the B-thread pool. The main advantage of this is that the operating environment is isolated. This will not affect other services of the system, even if the code that invokes the service has a bug, or if it is otherwise exhausted by its own online pool. But the cost is that maintaining multiple thread pools can bring additional performance overhead to the system. You can use Hystrix's signal mode (semaphores) to isolate resources if it is not a problem for client code that has stringent performance requirements and is confident that you are invoking the service.

Feign Hystrix

Because the fuse only works at this end of the service invocation, we only need to change the Spring-cloud-consumer project-related code as per the example 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 files

Application.properties Add this article:

Feign.hystrix.enabled=True

2. Create Callback Class

Methods for creating Helloremotehystrix class inheritance and helloremote implementation callbacks

@Component  Public class Implements helloremote{     @Override    public string Hello (@RequestParam (value = "Name ") string name) {         return "Hello" +name+ ", this messge send failed";    }}

3. Add Fallback property

HelloRemoteadds the specified fallback class to the class, returning the contents of the fallback class when the service is fused.

@FeignClient (name= "Spring-cloud-producer", fallback = Helloremotehystrix.  Class)publicinterface  helloremote {     = "/hello")      public string Hello (@RequestParam (value = "Name") string name);}

It's easy to change the point.

4. Testing

Let's test it and see how it works.

Start Spring-cloud-eureka, Spring-cloud-producer, spring-cloud-consumer three items in turn.

In the browser, enter:http://localhost:9001/hello/neo

Return:hello neo，this is first messge

After adding information about the fuse, the normal access is not affected. Next we manually stop the Spring-cloud-producer project from testing again:

In the browser, enter:http://localhost:9001/hello/neo

Return:hello neo, this messge send failed

According to the return results, the fuse was successful. Source Source technical support for complete projects 2147775633

Springcloud Distributed micro-Service (iv): Fuse hystrix