Hystrix knowledge sharing of spring cloud

Hystrix fault tolerant protection principle and configuration of spring cloud

1, What is the catastrophic avalanche effect?


The causes of catastrophic avalanche effect can be simply summarized as follows:

The service provider is not available. Such as hardware failure, program BUG, cache breakdown, excessive concurrent requests, etc.
Retry to increase traffic. Such as user retry, code retry logic, etc.
The service caller is not available. Such as resource depletion caused by synchronization request blocking, etc.
The final result of avalanche effect is that a service in the service chain is unavailable, resulting in a series of services are unavailable, and finally cause the service logic to collapse. The consequences of such problems are often unpredictable.

2, How to solve the catastrophic avalanche effect

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

Generally speaking, when developing, ribbon is used to deal with the avalanche effect of service disaster, and the development cost is low. High maintenance cost. Using feign technology to deal with the avalanche effect of service disaster, the development cost is high and the maintenance cost is low.

1. Degradation

Degradation means that when the request times out and resources are insufficient, the service is degraded. Instead of calling the real service logic, it directly returns a supporting data in the form of fast fall back, so as to ensure the integrity of the service chain and avoid service avalanche.

Solving the service avalanche effect is to avoid service call errors or network problems when the application client requests the application service. All processing methods are implemented in the application client. We need to import the hystrix dependency information into the application client related projects. And add a new annotation @ enableccircuitbreaker on the corresponding startup class. This annotation is used to turn on the hystrix fuse. In short, it makes the hystrix related annotations in the code take effect.

Import dependency:

<!-- hystrix Rely on to deal with the avalanche effect of service disaster. -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

Initiator code:

/**
 * @EnableCircuitBreaker - Open the circuit breaker. Is to enable the fault tolerance of the hystrix service.
 * An annotation must be added when the application enables the fault tolerance of the Hystrix service.
 */
@EnableCircuitBreaker
@EnableEurekaClient
@SpringBootApplication
public class HystrixApplicationClientApplication {
    public static void main(String[] args) {
      SpringApplication.run(HystrixApplicationClientApplication.class, args);
    }
}

Add a new method annotation @ HystrixCommand in the code related to calling application service, which means that the current method enables Hystrix to handle the service avalanche effect.

@The attribute in the HystrixCommand annotation: fallbackMethod - represents which fallback quick failure processing method is called to return the supporting data when there is a problem with the called application service.

Implementation class:

@Service
public class HystrixService {

    @Autowired
    private LoadBalancerClient loadBalancerClient;

    /**
     * Service degradation processing.
     * When the current method calls the application service remotely, if any error (timeout, exception, etc.) occurs in the service
     * Instead of throwing exceptions to the client, a local fallback (error return) method is used to return a backing data.
     * Avoid clients seeing error pages.
     * Use annotations to describe the service degradation logic of the current method.
     * @HystrixCommand - Open the annotation of the Hystrix command. Represents the current method. If there is a service call problem, use the Hystrix logic to handle it.
     *  Important attribute - fallbackMethod
     *      Error returned method name. If the current method calls the service, which local method will be called to get the underlying data when there is a problem with the remote service.
     *      Hystrix The method specified in fallbackMethod will be called to obtain the result and return it to the client.
     * @return
     */
    @HystrixCommand(fallbackMethod="downgradeFallback")
    public List<Map<String, Object>> testDowngrade() {
        System.out.println("testDowngrade method : " + Thread.currentThread().getName());
        ServiceInstance si = 
                this.loadBalancerClient.choose("eureka-application-service");
        StringBuilder sb = new StringBuilder();
        sb.append("http://").append(si.getHost())
            .append(":").append(si.getPort()).append("/test");
        System.out.println("request application service URL : " + sb.toString());
        RestTemplate rt = new RestTemplate();
        ParameterizedTypeReference<List<Map<String, Object>>> type = 
                new ParameterizedTypeReference<List<Map<String, Object>>>() {
        };
        ResponseEntity<List<Map<String, Object>>> response = 
                rt.exchange(sb.toString(), HttpMethod.GET, null, type);
        List<Map<String, Object>> result = response.getBody();
        return result;
    }

    /**
     * fallback method. Locally defined. It is used to process the basic data returned when a remote service call error occurs.
     */
    private List<Map<String, Object>> downgradeFallback(){
        List<Map<String, Object>> result = new ArrayList<>();
        
        Map<String, Object> data = new HashMap<>();
        data.put("id", -1);
        data.put("name", "downgrade fallback datas");
        data.put("age", 0);
        result.add(data);
        return result;
    }    
}

Fuse

When the proportion of abnormal requests (request timeout, network failure, service exception, etc.) reaches the threshold within a certain time, start the fuse. Once the fuse is started, it will stop calling the specific service logic and quickly return the supporting data through fallback to ensure the integrity of the service chain.

The fuse has an automatic recovery mechanism. For example, after the fuse is started, try to send a new request to the service provider every 5 seconds. If the service can be executed normally and returns the result, close the fuse and restore the service. If the call still fails, continue to return the base data, and the fuse continues to open.

Tags: Java server

Posted on Sun, 21 Nov 2021 16:24:40 -0500 by Griff1324