Hystrix circuit breaker (service degradation, fusing, current limiting)

Problems faced by distributed systems

Service avalanche: when calling between multiple services, suppose microservice A calls microservice B and microservice C, and microservice B and microservice C call other microservices, which is the so-called "fan out". If the call response time of A microservice on the fan out link is too long or unavailable, the call to microservice A will occupy more and more system resources, resulting in system crash, the so-called "avalanche effect".

For high traffic applications, a single back-end dependency may cause all resources on all servers to saturate in several aspects. Worse than failure, these applications may also lead to increased latency between services, tight backup queues, threads and other system resources, resulting in more cascading failures of the whole system. These all indicate the need to isolate and manage failures and delays so that the failure of a single dependency cannot cancel the entire application or system. Therefore, usually when you find that an instance under a module fails, the module will still accept traffic, and then the problematic module calls other modules, which will lead to cascading failure, or avalanche.

2. Concept and function of Hystrix

Hystrix is an open source library for dealing with latency and fault tolerance of distributed systems. In distributed systems, many dependencies inevitably fail to invoke, such as timeout and exception. Hystrix can ensure that when a dependency fails, it will not lead to the failure of the whole service, avoid cascading failures, and improve the elasticity of distributed systems.

"Circuit breaker" itself is a kind of switching device. When a service unit fails, it returns a predictable and processable FallBack to the caller through the fault monitoring of the circuit breaker (similar to fusing a fuse), rather than waiting for a long time or throwing an exception that the caller cannot handle, This ensures that the thread of the service caller will not be occupied unnecessarily for a long time, so as to avoid the spread and even avalanche of faults in the distributed system.

Key concepts of Hystrix (frequent interview)

1, Service degradation (fallback)

1. When a service unit fails, it returns an expected and processable fallback to the caller through the fault monitoring of the circuit breaker (similar to a blown fuse), rather than waiting for a long time or throwing an exception that the caller cannot handle. For example: the service is busy, please try again later, don't let the client wait, and immediately return a friendly prompt: fallback.

2. What conditions trigger a downgrade
(1) Abnormal program operation
(2) Timeout
(3) Service fuse triggers service degradation
(4) Full thread pool / semaphore will also cause service degradation

2, Service break

1. After the system sends the maximum service access volume, it directly refuses access, restricts subsequent service access, and calls the service degradation method to return a friendly prompt.
2. It is the fuse: service degradation – > and then blow – > restore the call link

3, Service flow limit

1. The purpose of current limiting is to protect the system from being overwhelmed by a large number of requests, and to protect the system by limiting the speed of requests. In the second kill activity of e-commerce, current restriction is an essential link. Limit high concurrency, queue requests, process N requests per second, and proceed in an orderly manner.

Hystrix case

Hystrix service provider

1. Import pom dependencies
Note: the Hystrix dependency of springcloud netfilx comes with Eureka

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

2. Write yml configuration file

server:
  port: 8001

spring:
  application:
    name: cloud-provider-hystrix-payment

eureka:
  client:
    #Indicates that the receiver registers itself with EurekaServer. The default value is true
    register-with-eureka: true
    #Whether to retrieve the existing registration information from EurekaServer is true by default. It doesn't matter for a single node. The cluster must be set to true to use load balancing with ribbon
    fetchRegistry: true
    service-url:
      #      defaultZone: http://localhost:7001/eureka # standalone
      defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka   #Cluster version
  instance:
    instance-id: hystrix-payment8001
    #The access path can display the IP address
    prefer-ip-address: true
    #The time interval between the eureka client sending heartbeat to the server, in seconds (30 seconds by default)
    lease-renewal-interval-in-seconds: 1
    #The maximum waiting time of eureka server after receiving the last heartbeat, in seconds (the default is 90 seconds). If it times out, the service will be deleted
    lease-expiration-duration-in-seconds: 2

3. Main start

@SpringBootApplication
@EnableEurekaClient
public class HystrixMainPayment8001 {
    public static void main(String[] args) {
        SpringApplication.run(HystrixMainPayment8001.class, args);
    }
}

4. Business class

@Service
public class PaymentServiceImpl implements PaymentService {

    /**
     * Normal access
     *
     * @return
     * @params
     */
    @Override
    public String paymentInfo_OK(Integer id) {
        return "Thread pool:" + Thread.currentThread().getName() + " paymentInfo_OK,id: " + id + "\t" + "Smiling face, ha ha ha";
    }

    @Override
    public String paymentInfo_Error(Integer id) {
        int time = 3;
        try {
            TimeUnit.SECONDS.sleep(time);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "Thread pool:" + Thread.currentThread().getName() + " paymentInfo_Timeout,id: " + id + "\t" + "Crying face, whining, time consuming" + time + "second";
    }
}

5,controller

@RestController
@Slf4j
public class PaymentController {

    @Resource
    private PaymentService paymentService;

    @GetMapping(value = "/payment/hystrix/ok/{id}")
    public String getOK(@PathVariable("id") Integer id) {
        String result = paymentService.paymentInfo_OK(id);
        log.info("***result:{}" + result);
        return result;
    }

    @GetMapping(value = "/payment/hystrix/error/{id}")
    public String getError(@PathVariable("id") Integer id) {
        String result = paymentService.paymentInfo_Error(id);
        log.info("***result:{}" + result);
        return result;
    }
}

5. JMeter is used for (service provider self-test) test, and the results are analyzed
(1) During normal access, request ok: each refresh will respond to the request quickly, and request error: it will also be responded within the corresponding time.
(2) When JMeter is used to issue 200 requests / s, the response of the request ok service will also slow down, and the error will also slow down.


(3) Conclusion: so why did this result?
The default number of working threads of tomcat is full, and there are no extra threads to decompose pressure and processing.

Hystrix service consumer

1. Introducing pom dependency

<!--Hystrix rely on-->
<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

<!--openfeign rely on-->
<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

<!--Eureka client-->
<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

2. Write yml configuration file

server:
  port: 80

spring:
  application:
    name: cloud-payment-hystrix-order

eureka:
  client:
    #Whether to register yourself with the registry. The default is true
    register-with-eureka: true
    #It doesn't matter whether to grab the existing registration information from EurekaServer. The cluster must be set to true to use load balancing with ribbon
    fetch-registry: true
    service-url:
      #      defaultZone: http://localhost:7001/eureka # standalone
      defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka  #Cluster version
  instance:
    instance-id: hystrix-order80
    #The access path can display the IP address
    prefer-ip-address: true
    #The time interval between the eureka client sending heartbeat to the server, in seconds (30 seconds by default)
    lease-renewal-interval-in-seconds: 1
    #The maximum waiting time of eureka server after receiving the last heartbeat, in seconds (the default is 90 seconds). If it times out, the service will be deleted
    lease-expiration-duration-in-seconds: 4

#Set feign client timeout (OpenFeign supports ribbon by default)
ribbon:
  #It refers to the time taken to establish a connection, which is applicable to the time taken to connect both ends under normal network conditions
  ReadTimeout: 5000
  #It refers to the time taken to obtain available resources from the server after the connection is established
  ConnectTimeout: 4000

3. To omit service invocation, refer to: https://blog.csdn.net/qq_36763419/article/details/120063156
4. High concurrency test

Use JMeter to send out 2w thread pressures 8001 and 8002. When consumer 80 accesses the normal ok micro service 8001 address again, the consumer's response slows down (turns around), or the consumer reports a request timeout error.

Causes and Solutions

1. Cause

Other interface services at the same level of the service provider are trapped because the threads in the tomcat thread pool have been occupied. At this time, the consumer 80 calls the service provider, and the client access response is slow and turns around.

2. Solution

(1) Question:

A. Timeout causes the server to slow down (turn): timeout no longer waits.
B. Error (downtime or program operation error): the error should be explained.

(2) Solution:

A. The other party's service (8001) has timed out, and the caller (80) cannot wait all the time. There must be service degradation.
B. The other party's service (8001) is down. The call cannot be stuck and wait all the time. There must be service degradation.
C. The other party's service (8001) is OK, the caller (80) has its own failure or self request (its own waiting time is less than the service provider's time), and the caller (80) downgrades itself.

service degradation

1. Degraded configuration (usually in consumer configuration): @ HystrixCommand
2. Service provider 8001, first find the problem from itself: set the peak value of the service provider's own call timeout, and the service provider will operate normally within the peak value. If it exceeds the need for a thorough method, it will be used as a service degradation fallback.
3,8001 fallback
(1) Business class enable

@Service
public class PaymentServiceImpl implements PaymentService {

    /*
       Use the fallbackMethod attribute in the HystrixCommand annotation to refer to the current
       Method to execute paymentinfo when the call fails_ Errorhandler [find out the details]

       @HystrixProperty(name = "execution.isolation.thread.timeoutMilliseconds", value = "3000") Indicates that the time for changing the thread is 3 seconds, which is the normal peak
    */
    @HystrixCommand(
            fallbackMethod = "paymentInfo_errorHandler",
            commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000")}
    )
    @Override
    public String paymentInfo_Error(Integer id) {
        int time =5000;
//        int a = 10 / 0;
//        System.out.println(a);
        try {
            Thread.sleep(time);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "Thread pool:" + Thread.currentThread().getName() + " paymentInfo_Timeout,id: " + id + "\t" + "Crying face, whining, time consuming" + time + "second";
    }

    public String paymentInfo_errorHandler(Integer id) {
        return "Thread pool:" + Thread.currentThread().getName() + "System busy or running error paymentInfo_errorHandler,id: " + id + "\t" + "Crying face, woo woo";
    }
}

(2) Main startup class activation: add new annotation @ enablercircuitbreaker

4,80 fallback
(1) yml add the following configuration

feign:
  hystrix:
    enabled: true #Fault tolerance is turned on if processing itself. The opening method is different from the production end.

(2) Main startup class activation: add new annotation @ EnableHystrix
(3) Business class

@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT")
public interface PaymentHystrixService {

    @GetMapping(value = "/payment/hystrix/ok/{id}")
    public String getOK(@PathVariable("id") Integer id);

    @GetMapping(value = "/payment/hystrix/error/{id}")
    public String getError(@PathVariable("id") Integer id);

}

(4)controller

package com.atguigu.springcloud.controller;

import com.atguigu.springcloud.service.PaymentHystrixService;
import com.netflix.hystrix.contrib.javanica.annotation.DefaultProperties;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixProperty;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RestController;

import javax.annotation.Resource;

/**
 * @author Li Hongwei
 * @version 1.0
 * @ClassName OrderController
 * @Description
 * @date 2021 September 6, 2014 0:43
 */
@RestController
@Slf4j
//@DefaultProperties(defaultFallback = "payment_Global_FallbackMethod") / / Global
public class OrderHystrixController {

    @Resource
    private PaymentHystrixService paymentHystrixService;

    @GetMapping(value = "/consumer/hystrix/ok/{id}")
    public String getOK(@PathVariable("id") Integer id) {
        String result = paymentHystrixService.getOK(id);
        log.info("***result:{}" + result);
        return result;
    }


    @GetMapping(value = "/consumer/hystrix/error/{id}")
//    @HystrixCommand(
//            fallbackMethod = "getErrorFallbackMethod",
//            commandProperties = {
//                    //Indicates that the normal business logic is within 3 seconds
//                    @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")
//            }
//    )
    public String getError(@PathVariable("id") Integer id) {
        String result = paymentHystrixService.getError(id);
        log.info("***result:{}" + result);
        return result;
    }

    public String getErrorFallbackMethod(Integer id) {
        return "I'm consumer 80. The other party's payment system is busy. Please try again in 10 seconds, or you run an error. Please check yourself,(┬_┬)";
    }

    //The following is the global fallback method
    public String payment_Global_FallbackMethod() {
        return "Global Exception handling information, please try again later,(┬_┬)";
    }
}

5. Current problems and Solutions
(1) Problem: each business method corresponds to a bottom-up method, resulting in code inflation
(2) Solution: separate unified and customized configurations [global configuration and partial customized configuration fallback]. That is, you only need to add an implementation class for service degradation processing to the interface defined by Feign client to realize decoupling. According to the existing PaymentHystrixService interface of cloud consumer Feign hystrix order80, create a class (PaymentFallbackServiceImpl) to implement the interface and handle exceptions for the methods in the interface. The code is as follows:

A. Feign remote call interface class

@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT", fallback = PaymentFallbackServiceImpl.class)
//Global configuration of service degradation, which applies the degradation rule to all requests of microservices
@DefaultProperties(
        commandProperties = {
                @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")
        }
)
public interface PaymentHystrixService {

    @GetMapping(value = "/payment/hystrix/ok/{id}")
    //Restrict the access time of the specified calling interface and degrade the service if there is no response within the specified time
    @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500") 
    public String getOK(@PathVariable("id") Integer id);

    @GetMapping(value = "/payment/hystrix/error/{id}")
    public String getError(@PathVariable("id") Integer id);

}

B. Fallback implementation class

@Component
public class PaymentFallbackServiceImpl implements PaymentHystrixService {

    @Override
    public String getOK(Integer id) {
        return "-------- PaymentFallbackServiceImpl fallback ----------";
    }

    @Override
    public String getError(Integer id) {
        return "-------- PaymentFallbackServiceImpl fallback, request timeout or RunException----------";
    }
}

Service fuse

1, Circuit breakers: fuses

2, Overview of fuse mechanism

Fuse mechanism is a microservice link protection mechanism corresponding to avalanche. When a microservice on the fan out link fails to be available or the response time is too long, the service will be degraded, and then the microservice call of the node will be changed to quickly send back the wrong response information. When it is detected that the microservice call response of the node is normal, the call link will be restored. In the spring cloud framework, the circuit breaker mechanism Rongguo Hystrix will monitor the calls between microservices. When the failed calls reach a certain threshold, the default is 20 calls in 5 seconds, and the circuit breaker mechanism will be started. The annotation of the fuse mechanism is @ HystrixCommand.

Extension: the property values of the degraded and annotation of the Hystrix configuration service come from the HystrixCommandProperties abstract class

@HystrixCommand(commandProperties = {
	@HystrixProperty(name = "Attribute name", value = "Attribute value")
})

3, Case (practical operation)
1. Modify the PaymentService implementation class of cloud provider hystrix payment8001

@Service
public class PaymentServiceImpl implements PaymentService {
/*======================= Service fuse=======================*/
    @HystrixCommand(
            fallbackMethod = "paymentCircuitBreaker_fallback",
            commandProperties = {
                    @HystrixProperty(name = "circuitBreaker.enabled", value = "true"),//Is the circuit breaker open
                    @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),//Number of requests
                    @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000"),//time frame
                    @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60"), //What is the failure rate before tripping
            }
    )
    public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
        if (id < 0) {
            throw new RuntimeException("**** id Cannot be negative");
        }
        String serialNumber = IdUtil.simpleUUID();
        return Thread.currentThread().getName() + "\t" + "Call succeeded, serial number:" + serialNumber;
    }
    public String paymentCircuitBreaker_fallback(@PathVariable("id") Integer id) {
        return " id Cannot be negative, please try again later, crying face  id: " + id;
    }
}

2. Modify PaymentController.java of cloud-provider-hystrix-payment8001

@RestController
@Slf4j
public class PaymentController {

    @Resource
    private PaymentService paymentService;

    /*======================= Service fuse=======================*/
    @GetMapping(value = "/payment/circuit/{id}")
    public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
        String result = paymentService.paymentCircuitBreaker(id);
        log.info("***result:${}" + result);
        return result;
    }
}

Test results: enter a negative number. When the failure rate reaches more than 60%, when we enter a positive number, the service degradation information will be returned. There will be many errors, and then it will be correct slowly. It is found that the conditions are not met at the beginning. Even the correct access address cannot be accessed, and the link needs to be restored slowly.

3. Client cloud consumer feign hystrix order80 complete configuration
(1) feign calling interface class: PaymentHystrixService.java

@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT", fallback = PaymentFallbackServiceImpl.class)
@DefaultProperties(
        commandProperties = {
                @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500"),
                @HystrixProperty(name = "circuitBreaker.enabled", value = "true"),//Is the circuit breaker open
                @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),//Number of requests
                @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000"),//time frame
                @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60"), //What is the failure rate before tripping
        }
)
public interface PaymentHystrixService {

     /*======================= Service fuse=======================*/
    @GetMapping(value = "/payment/hystrix/circuitbreaker/{id}")
    public String paymentCircuitBreaker(@PathVariable("id") Integer id);
}

(2) feign calls the interface implementation class: PaymentHystrixServiceImpl.java

@Component
public class PaymentFallbackServiceImpl implements PaymentHystrixService {

    @Override
    public String paymentCircuitBreaker(Integer id) {
        return "-------- PaymentFallbackServiceImpl circuit breaker ----------";
    }
}

(3) controller layer

@RestController
@Slf4j
public class OrderHystrixController {
	@Resource
    private PaymentHystrixService paymentHystrixService;

    /*======================= Service fuse=======================*/
    @GetMapping(value = "/consumer/hystrix/circuitbreaker/{id}")
    public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
        String result = paymentHystrixService.paymentCircuitBreaker(id);
        log.info("***result:{}" + result);
        return result;
    }
}

Test results: enter a negative number. When the failure rate reaches more than 60%, when we enter a positive number, the service degradation information will be returned. There will be many errors, and then it will be correct slowly. It is found that the conditions are not met at the beginning. Even the correct access address cannot be accessed, and the link needs to be restored slowly.

Conclusion: the service is degraded -- > and then the call link is restored -- >

4, Principle of service fusing (summary)

1. Schematic structure diagram of service fuse

This simple circuit breaker avoids making the protected call when the circuit is open, but would need an external intervention to reset it when things are well again. This is a reasonable approach with electrical circuit breakers in buildings, but for software circuit breakers we can have the breaker itself detect if the underlying calls are working again. We can implement this self-resetting behavior by trying the protected call again after a suitable interval, and resetting the breaker should it succeed.
This simple circuit breaker avoids making a protected call when the circuit is disconnected, but requires external intervention to reset it when the situation returns to normal. For the electrical circuit breaker in the building, this is a reasonable method, but for the software circuit breaker, we can let the circuit breaker itself detect whether the bottom call works again. We can achieve this self resetting behavior by trying the protected call again after an appropriate time interval and resetting the circuit breaker after success.

2. Fuse type

(1) Fusing off: fusing off will not fuse the service memory.
(2) Fusing on: when the request is not in progress and the current service is called, the internal set clock is generally MTTR (average fault handling time). When it is turned on for as long as the set clock, it will enter the semi fusing state.
(3) Fusing half open: some requests use the current service according to the rule. If the request is successful and meets the rules, it is considered that the current service returns to normal and the fusing is turned off.

3. When does the Hystrix circuit breaker work?

/*======================= Service fuse=======================*/
   @HystrixCommand(
           fallbackMethod = "paymentCircuitBreaker_fallback",
           commandProperties = {
          			//Is the circuit breaker open
                   @HystrixProperty(name = "circuitBreaker.enabled", value = "true"),
                   //If the number of requests exceeds the peak value, the circuit breaker will change from closed state to open state
                   @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),
                   //time frame
                   @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000"),
                   //What is the failure rate before tripping
                   @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60"), 
           }
   )
   public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
   ......
   }

Three important parameters of the circuit breaker are involved: time snapshot window, threshold value of total requests and threshold value of error percentage.
(1) Snapshot time window: the circuit breaker determines whether to open some requests and error data that need to be counted, and the statistical time range is the quick find time window, which defaults to the last 90 seconds.
(2) Threshold value of total number of requests: in the fast search time window, the threshold value of total number of requests must be met before being eligible for fusing. The default value is 20 times. This means that if the number of calls of the hystrix command is less than 20 within the time range, the circuit breaker will not open even if all requests timeout or fail for other reasons. (that is, within the time snapshot window, the circuit breaker will be triggered only when the request times out or abnormally exceeds the threshold of the total number of requests)
(3) Error percentage threshold: when the total number of requests exceeds the threshold within the snapshot time window and the error percentage meets the threshold, it will fuse. The default is 50%.

4. How does the circuit breaker work after it is opened?

(1) After the circuit breaker is opened, when there is a request to call again, the main logic will not be called, but the service degradation fallback will be called directly. Through the circuit breaker, it can automatically find exceptions or errors and switch the service degradation logic to the main logic to reduce the response delay.
(2) How to restore the original main logic?
For this problem, hystrix also implements the automatic recovery function for us. When the circuit breaker is opened and the main logic is fused, hystrix will start a sleep time window. In this time window, the service degradation logic will replace the main logic. When the sleep time window expires, the circuit breaker will also enter the semi open state and release a request to the original main logic. If the request returns correctly, the circuit breaker will continue to close and the main logic will recover, If there is still a problem with this request, the circuit breaker will continue to open and the sleep time window will be timed again.

5. Detailed explanation of Hystrix configuration parameters
Official website address: https://github.com/Netflix/Hystrix/wiki/Configuration
forward: https://www.cnblogs.com/zhenbianshu/p/9630167.html

Service current limit (subsequent update)

Hystrix workflow

Hystrix workflow: https://github.com/Netflix/Hystrix/wiki/How-it-Works

Service monitoring HystrixDashboard

1, Overview

In addition to isolating the calls of dependent services, hystrix also provides a quasi real-time call monitoring (hystrix dashboard). Hystrix will continuously record the execution information of all requests initiated through hystrix and display it to users in the form of statistical reports and graphics, including how many requests are executed, how many successes, how many failures, etc. per second. Netflix monitors the above indicators through the hystrix metrics event stream project. Spring cloud also provides the integration of the hystrix dashboard to transform the monitoring content into a visual interface.

2, Instrument cluster 9001
1. Create a new cloud consumer hystrix dashboard9001
2. Introducing pom dependency

<!--hystrix dashboard rely on-->
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>

3. yml profile

server:
  port: 9001

4. Main startup class

@SpringBootApplication
//Turn on service monitoring
@EnableHystrixDashboard
public class HystrixDashboardMain9001 {
    public static void main(String[] args) {
        SpringApplication.run(HystrixDashboardMain9001.class, args);
    }
}

5. Launch and open browser http://localhost:9001/hystrix
The results are as follows:

3, Circuit breaker demonstration
1. Note: the new version of Hystrix needs to specify the monitoring path in the startup class MainAppHystrix8001 of the main monitored service

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

    /*
        This configuration is for service monitoring and has nothing to do with the service fault tolerance itself. After the spring cloud upgrade,
        ServletRegistrationBean Because the default path of springboot is not "/ hystrix.stream"
        Just configure the following servlet s in your project
    */
    @Bean
    public ServletRegistrationBean<HystrixMetricsStreamServlet> getServlet() {
        HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
        ServletRegistrationBean<HystrixMetricsStreamServlet> registrationBean = new ServletRegistrationBean<>();
        registrationBean.setServlet(streamServlet);
        registrationBean.setLoadOnStartup(1);
        registrationBean.addUrlMappings("/hystrix.stream");
        registrationBean.setName("HystrixMetricsStreamServlet");
        return registrationBean;
    }
}

2. Testing
(1) Enter the monitored microservice address in the monitoring panel

(2) Test address

http://localhost/consumer/hystrix/circuitbreaker/10
http://localhost/consumer/hystrix/circuitbreaker/-10

3. Analysis of service monitoring diagram (seven colors, one circle and one line)

(1) Seven colors
(2) A circle
Filled circle: there are two meanings. It represents the health degree of the instance through the change of color, and its health degree decreases from green < yellow < orange < red.
In addition to the change of color, the size of the solid circle will also change according to the requested flow of the instance. The larger the flow, the larger the solid circle. Therefore, through the display of the solid circle, we can quickly find fault cases and high pressure cases in a large number of examples.
(3) First line: request access frequency.

Analysis of the whole diagram:

Tags: Hystrix

Posted on Sun, 26 Sep 2021 03:42:24 -0400 by yanti