Hystrix service fault-tolerant protection

First, what is a catastrophic avalanche effect?

 

 

 

Cause catastrophic avalanche effect, it can simply be attributed to the following three:

The service provider is not available. Such as: a hardware failure, a program BUG, ​​buffer breakdown, such as excessive concurrent requests.

Retry increase traffic. Such as: a user to retry, retry logic codes and the like.

Service the caller is not available. Such as: a synchronization request resource depletion caused by obstruction and so on.

The end result is an avalanche effect: service chain in a certain service is not available, leading to a range of services not available, eventually leading to the collapse of service logic. The consequences of this problem caused by the often unpredictable.

 

Second, how to solve the catastrophic avalanche effect?

 

Way to solve the catastrophic avalanche effect is usually: demotion, isolation, fuse, request caching, request the merger.

In Spring cloud processing services avalanche effect, we need to rely hystrix components.

In pom file you need to rely on the introduction of the following:

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

Generally speaking, when developed, using ribbon processing services disaster avalanche effect, low-cost development. High maintenance costs. The higher cost of using technology feign disaster avalanche effect processing services, development, maintenance and low cost.


2.1 Downgrade

Downgrade means, a service downgrade when requesting overtime, lack of resources occurs, do not call the real service logic, but the use of fast failure (fallback) underpinning a direct return data to ensure complete service chain, to avoid avalanche service .

Solving services avalanche effect, you are requested to avoid the application client application service, service call error or a network problem. Handling are implemented in the application client. We need to import hystrix rely on the information in the relevant application client project. And a corresponding increase in new startup class notes @EnableCircuitBreaker, this annotation is used to turn hystrix fuse, in short, it is to make the code hystrix related annotations take effect.

Enabler snippet

@EnableDiscoveryClient
@SpringBootApplication
@EnableHystrix
@EnableCircuitBreaker
public class HystrixApplicationClientApplication { public static void main(String[] args) { SpringApplication.run(HystrixApplicationClientApplication.class, args); } }

In calling application service-related code, add a new method comment @HystrixCommand, representing the current method enabled Hystrix processing services avalanche effect.

@HystrixCommand properties of the annotation:

fallbackMethod - When the application service when you call on behalf of a problem, which calls fallback fast failure handling method returns underpinning data.

   @Autowired
     Private LoadBalancerClient loadBalancerClient; 

    / ** 
     * Service downgraded. 
     * The current remote method invocation service application service when the service if the service there was any error (time-out, exceptions, etc.) 
     * will not be an exception thrown client, but the use of a local fallback (error return) method to return a prop background data. 
     * Avoid client see an error page. 
     * Use annotations to describe the logic of the current method of service degradation. 
     * 
     * @HystrixCommand - Open comments Hystrix command. If the service representing the current method call problems, use Hystrix logic to handle. 
     * Important attribute - fallbackMethod error Returns the name. 
     * If the current method call service, remote service when problems arise, 
     * which method to call to get underpinning local data. 
     *   
     * Hystrix calls the method specified fallbackMethod, get results, and returned to the client. 
     * / 
    @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 <the Map <String, Object type >>> = new new ParameterizedTypeReference <List <the Map <String, Object >>> () {}; 
        ResponseEntity <List <the Map <String, Object >>> rt.exchange Response = ( sb.toString (), HttpMethod.GET, null , type); 
        List <the Map <String, Object >> Result = response.getBody ();
         return Result; 
    } 
    
    / ** 
     * fallback method. Locally defined. Basic data used to process remote service call when an error is returned. 
     * / 
    @SuppressWarnings ( "unused" )
     Private List <the Map <String, Object >> <the Map <String, Object >>
        <String, Object> data = new HashMap<>();
        data.put("id", -1);
        data.put("name", "downgrade fallback datas");
        data.put("age", 0);
        
        result.add(data);
        
        return result;
    }

 

 2.2 Cache

Request refers to a cache buffer. He said the general sense, is the same GET request cached results, use caching mechanism (such as redis, mongodb) to enhance the efficiency of the response request.

When a request using a cache, it is noted affect non-idempotent operations of cache data.

Relying on request cache is a caching service to achieve. In the case of using redis as a cache server, you can use spring-data-redis redis of access operations to achieve.

We need to import the following related application client in dependence Engineering:

<dependency>
  <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency>

In Spring Cloud applications, enable the spring support for cache needs to be increased in the startup class notes @EnableCaching This comment represents the current application to open spring support for the cache. In short, the spring-data-redis related annotations take effect, such as: @ CacheConfig, @ Cacheable, @ CacheEvict and so on.

spring cloud idempotency checks each request, if the request is exactly the same (path, exactly the same parameters, etc.), you first access the cache redis, view the cached data, if there is data in the cache, no remote service application service calls. If there is no data in the cache, the remote service call, and the results redis cached, the request for subsequent use.

If the request is a non-idempotent operations will redis to dynamically manage cache data in accordance with the method of the annotation, to avoid data inconsistencies.

Note: Use request caching can cause a lot of problems, such as: improper data cache management are not synchronized, troubleshoot difficulties. In commercial projects, the avalanche effect does not resolve service requests recommended cache.

 

 2.3 Merge Request

slightly

 

2.4 fuse

When the certain period of time, the proportion of abnormal request (Request Timeout, network failure, abnormal Service) threshold is reached, to start the fuse, the fuse once started, will stop calling the specific service logic, returned by underpinning fallback data quickly, to ensure complete service chain.

Fuse with automatic recovery mechanism, such as: when the fuse is started, every 5 seconds, attempts to send the new request to the service provider, if the service can be performed normally and returns the result, the fuse is closed, service recovery. If the call still fails, we continue to return data underpinning the fuse continuously open state.

 

 

 

Implementation is blown increased @HystrixCommand annotation on the remote method invocation services. When the annotation configuration meets the open or closed fuse.

Notes property Description:

CIRCUIT_BREAKER_ENABLED

"circuitBreaker.enabled";

Whether to open fusing strategy. The default value is true.

 

CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD

"circuitBreaker.requestVolumeThreshold";

Within 10ms, the number of concurrent requests exceeds the trigger blown strategy. The default value is 20.

 

CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS

"circuitBreaker.sleepWindowInMilliseconds";

When blown open strategy, how long delayed again try to request a remote service. The default is 5 seconds.

 

 CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE

"circuitBreaker.errorThresholdPercentage";

Within 10ms, the error percentage of requests limit is reached, the trigger fuse policy. The default is 50%.

 

CIRCUIT_BREAKER_FORCE_OPEN

"circuitBreaker.forceOpen";

Whether to force open the fuse policy. I.e., all requests return data underpinning fallback. The default is false.

 

CIRCUIT_BREAKER_FORCE_CLOSED

"circuitBreaker.forceClosed";

Whether forced to close blown strategy. That is, all requests must call the remote service. The default is false.

 

 

2.5 Isolation

2.5.1 thread pool isolation

2.5.2 semaphore isolation

slightly

 

 

 

 

Guess you like

Origin www.cnblogs.com/yucongblog/p/11484768.html