Notas de estudio de Spring Cloud [rebaja de tolerancia a fallas-Hystrix]

Language 2023-06-12 07:59:13 views: null

Directorio de artículos

Descripción general de Hystrix

¿Qué es Hystrix?

Hystrix es una biblioteca de latencia y tolerancia a fallas para sistemas distribuidos, desarrollada y de código abierto por Netflix. Está diseñado para aumentar la confiabilidad y la resiliencia de las aplicaciones y para reducir el impacto de las fallas del sistema al proporcionar mecanismos de conmutación por error y respaldo.

Hystrix utiliza el patrón de disyuntores para controlar y detener las llamadas a los servicios remotos para evitar una carga excesiva u otros errores en el sistema. Cuando falla una llamada a un servicio remoto o se agota el tiempo de espera, Hystrix tomará las medidas adecuadas, como usar un método alternativo para devolver un valor preestablecido o proporcionar un servicio alternativo.

Hystrix también proporciona métricas en tiempo real y capacidades de monitoreo, lo que permite a los desarrolladores monitorear el estado de sus aplicaciones y realizar los ajustes y optimizaciones necesarios.

En la arquitectura de microservicios, Hystrix puede brindar protección tolerante a fallas entre servicios para garantizar la confiabilidad y elasticidad de todo el sistema. Al usar Hystrix, los desarrolladores pueden construir sistemas distribuidos más resistentes y confiables.

¿Qué es la degradación del servicio?

La degradación del servicio es una estrategia para hacer frente a situaciones anormales, como una alta concurrencia y fallas del sistema. En el caso de escasez o anomalía de los recursos del sistema, para garantizar la estabilidad de las funciones básicas, algunos servicios no básicos o sin importancia pueden cerrarse temporalmente para reducir la calidad del servicio, pero garantizar la disponibilidad de los servicios básicos.
Por ejemplo, durante un evento promocional importante, el servicio de procesamiento de pedidos de la plataforma de comercio electrónico estará bajo mayor presión. Para garantizar la disponibilidad del servicio de pedidos principal, el servicio de evaluación del usuario puede cerrarse temporalmente para evitar la presión adicional. causados ​​por el servicio de evaluación.

¿Qué es un disyuntor de servicio?

La interrupción del circuito de servicio es una estrategia para hacer frente a las fallas del servicio. Cuando un servicio falla o es anormal, deje de solicitar el servicio a tiempo para evitar que la falla se propague a todo el sistema, asegurando así la disponibilidad del sistema.
Por ejemplo, cuando un servicio no está disponible, puede establecer un período de tiempo de espera antes de llamar al servicio. Si el servicio no responde a tiempo o devuelve un error, deje de solicitar el servicio a tiempo y realice el procesamiento de degradación correspondiente.

¿Qué es la limitación de servicios?

La limitación del servicio es una estrategia para controlar la cantidad de solicitudes del sistema. En el caso de una alta concurrencia del sistema, el volumen de solicitudes del sistema se puede controlar limitando el número de solicitudes simultáneas y la tasa de solicitudes para evitar la sobrecarga del sistema.
Por ejemplo, se puede configurar que solo se permita procesar una cierta cantidad de solicitudes por segundo, y las solicitudes que excedan el límite serán rechazadas para garantizar la estabilidad del sistema.

Usos de Hystrix

Demostración de degradación del servicio

Construir servidor lf-hystrix-usuario

Cree un nuevo módulo de usuario del servidor, consulte el servicio de usuario
para crear un nuevo servicio de usuario lf-hystrix
inserte la descripción de la imagen aquí
pom.xml

	<dependencies>
        <!--hystrix-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>
        <!--eureka client-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>
        <!--web-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

aplicación.yml

server:
  port: 9001

spring:
  application:
    name: lf-hystrix-user
  main:
    allow-bean-definition-overriding: true #当遇到同样名字的时候，是否允许覆盖注册

eureka:
  instance:
    # 配置eureka的状态显示
    hostname: localhost
    instance-id: ${
    
    eureka.instance.hostname}:${
    
    spring.application.name}:${
    
    server.port}
  client:
    #表示是否将自己注册进EurekaServer默认为true。
    register-with-eureka: true
    #是否从EurekaServer抓取已有的注册信息，默认为true。单节点无所谓，集群必须设置为true才能配合ribbon使用负载均衡
    fetchRegistry: true
    service-url:
      #defaultZone: http://localhost:7001/eureka
      defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka  # 集群版

Clase de inicio UserApplication

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

El UserController de clase empresarial
tiene una interfaz para retorno normal
y una interfaz para retorno retrasado

@RestController
@RequestMapping("/user")
public class UserController {
    
    

    /**
     * 获取当前用户信息
     */
    @GetMapping("/info/{username}")
    public String info(@PathVariable("username") String username)
    {
    
    
        return username + " login success 端口：9001";
    }

    /**
     * 获取当前用户信息timeout
     */
    @GetMapping("/info/timeout/{username}")
    public String infoTimeOut(@PathVariable("username") String username)
    {
    
    
        try {
    
    
            Thread.sleep(5*1000);
        } catch (InterruptedException e) {
    
    
            e.printStackTrace();
        }
        return username + " login success 超时端口：9001";
    }

}

Construcción lf-hystrix-auth del lado del consumidor

Nuevo módulo lf-hystrix-auth
inserte la descripción de la imagen aquí
pom.xml

<dependencies>
        <!--openfeign-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-openfeign</artifactId>
        </dependency>
        <!--hystrix-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>
        <!--eureka client-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>
        <!--web-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <!--一般基础通用配置-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

aplicación.yml

server:
  port: 9002

spring:
  application:
    name: lf-hystrix-auth

eureka:
  instance:
    # 配置eureka的状态显示
    hostname: localhost
    instance-id: ${
    
    eureka.instance.hostname}:${
    
    spring.application.name}:${
    
    server.port}
  client:
    #表示是否将自己注册进EurekaServer默认为true。
    register-with-eureka: true
    #是否从EurekaServer抓取已有的注册信息，默认为true。单节点无所谓，集群必须设置为true才能配合ribbon使用负载均衡
    fetchRegistry: true
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka  # 集群版

Iniciar clase HystrixAuthApplication

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

Servicio empresarial

@FeignClient(value = "LF-HYSTRIX-USER")
public interface AuthService {
    
    

    @GetMapping("/user/info/{username}")
    String getUserInfo(@PathVariable("username") String username);

    @GetMapping("/user/info/timeout/{username}")
    String getUserInfoTimeOut(@PathVariable("username") String username);

}

Controlador de clase ejecutiva

@RestController
@RequestMapping("/auth")
public class AuthController {
    
    

    @Autowired
    AuthService authService;

    @PostMapping("login")
    public String login(@RequestBody String name)
    {
    
    
        return authService.getUserInfo(name);
    }

    @PostMapping("/login/timeout")
    public String loginTimeout(@RequestBody String name)
    {
    
    
        return authService.getUserInfoTimeOut(name);
    }

}

prueba

Use jMeter de alta concurrencia multiproceso para solicitar directamente la interfaz de tiempo de espera del usuario del servidor.

Configuración jMeter

inserte la descripción de la imagen aquí
200 subprocesos, bucle 100 veces, iniciar
inserte la descripción de la imagen aquí
configuración de solicitud http en 1 segundo
inserte la descripción de la imagen aquí

Prueba de usuario del lado del servidor

Inicie cada servicio.
jMeter inicia la interfaz de tiempo de espera para solicitudes de servicios de usuario de alta concurrencia.
Al mismo tiempo, solicitamos observaciones normales de la interfaz que solicitan directamente los servicios del usuario.
inserte la descripción de la imagen aquí
Se encuentra que la llamada de la interfaz normal también es significativamente más lenta.
Esto se debe a que el número predeterminado de subprocesos de trabajo de Tomcat está completamente cargado y no hay subprocesos adicionales para descomponer la presión y el procesamiento.

Prueba de llamada remota de autenticación del lado del consumidor

Inicie el servicio lf-hystrix-auth.
La interfaz de tiempo de espera del mismo servicio de usuario de solicitud de alta simultaneidad.
Esta vez observe la situación de usar el servicio de autenticación para llamar a la interfaz común.
inserte la descripción de la imagen aquí
inserte la descripción de la imagen aquí
Como se muestra en la figura, esperará mucho tiempo o expirará e informará un error.

solución

  • Para el lado del servicio: si el tiempo de respuesta de su propio servicio se agota, se reduce o informa un error, se requiere una degradación del servicio.
  • Para la persona que llama: el servicio de llamadas supera el límite de tiempo y necesita manejar la degradación por sí mismo

Configuración de degradación del servicio

Configuración de usuario del servidor

UserController de clase empresarial

@RestController
@RequestMapping("/user")
public class UserController {
    
    

    /**
     * 获取当前用户信息
     */
    @GetMapping("/info/{username}")
    public String info(@PathVariable("username") String username)
    {
    
    
        return username + " login success 端口：9001";
    }

    /**
     * 获取当前用户信息timeout
     */

    @GetMapping("/info/timeout/{username}")
    @HystrixCommand(fallbackMethod = "userInfoTimeOutHandler", commandProperties = {
    
    
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000")
    })
    public String infoTimeOut(@PathVariable("username") String username)
    {
    
    
        try {
    
    
            Thread.sleep(5*1000);
        } catch (InterruptedException e) {
    
    
            e.printStackTrace();
        }
        return username + " login success 超时端口：9001";
    }

    /**
     * 超时访问的降级方法
     *
     * @param username
     * @return
     */
    public String userInfoTimeOutHandler(String username) {
    
    
        return "/(ㄒoㄒ)/调用用户信息接口超时或异常：\t" + "\t当前线程池名字" + Thread.currentThread().getName();
    }

}

La modificación principal es agregar la anotación @HystrixCommand para definir el método de procesamiento específico de la degradación.La
inserte la descripción de la imagen aquí
clase de inicio agrega la anotación
@EnableCircuitBreaker
inserte la descripción de la imagen aquí

Prueba de usuario del lado del servidor

Definimos un tiempo de espera de 3 s y el método se retrasa durante 5 segundos. Al observar los resultados, podemos
inserte la descripción de la imagen aquíver que se detectará la situación anormal y se usará el método de fallbackMethod para tratarla.

Configuración de autenticación de llamadas

Modificación de clase de inicio
Agregar anotación @EnableHystrix
inserte la descripción de la imagen aquí
application.yml modificación
principalmente para cambiar el tiempo de espera de diseño a 5s

server:
  port: 9002

spring:
  application:
    name: lf-hystrix-auth


eureka:
  instance:
    # 配置eureka的状态显示
    hostname: localhost
    instance-id: ${
    
    eureka.instance.hostname}:${
    
    spring.application.name}:${
    
    server.port}
  client:
    #表示是否将自己注册进EurekaServer默认为true。
    register-with-eureka: true
    #是否从EurekaServer抓取已有的注册信息，默认为true。单节点无所谓，集群必须设置为true才能配合ribbon使用负载均衡
    fetchRegistry: true
    service-url:
      defaultZone: http://eureka7001.com:7001/eureka,http://eureka7002.com:7002/eureka  # 集群版

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 5000

feign:
  client:
    config:
      ## default 设置的全局超时时间，指定服务名称可以设置单个服务的超时时间
      default:
        connectTimeout: 5000
        readTimeout: 5000

Modifique la clase empresarial AuthController
como el servidor, establezca un método alternativo
inserte la descripción de la imagen aquí

@RestController
@RequestMapping("/auth")
public class AuthController {
    
    

    @Autowired
    AuthService authService;

    @PostMapping("login")
    public String login(@RequestBody String name)
    {
    
    
        return authService.getUserInfo(name);
    }

    @PostMapping("/login/timeout")
    @HystrixCommand(fallbackMethod = "loginTimeOutHandler", commandProperties = {
    
    
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")
    })
    public String loginTimeout(@RequestBody String name)
    {
    
    
        return authService.getUserInfoTimeOut(name);
    }

    /**
     * 超时访问的降级方法
     *
     * @param username
     * @return
     */
    public String loginTimeOutHandler(String username) {
    
    
        return "/(ㄒoㄒ)/调用登录接口超时或异常：\t" + "\t当前线程池名字" + Thread.currentThread().getName();
    }

}

Prueba de autenticación de llamadas

inserte la descripción de la imagen aquí
Como se muestra en la figura, se alcanza el método loginTimeOutHandler porque el período de tiempo de espera del servicio de autenticación es de 1,5 s y la interfaz del servidor de usuario tiene un retraso de 5 s. Y el período de tiempo de espera del servidor solo se activa después de 3 segundos, por lo que aquí es donde entra en vigencia el método de degradación de autenticación.
Establecemos el período de tiempo de espera en el lado de autenticación en 4 segundos y luego observamos el efecto, es decir, el método de degradación del lado del servidor entra en vigencia primero.
inserte la descripción de la imagen aquí
El método de degradación del usuario del lado del servidor entra en vigorinserte la descripción de la imagen aquí

configuración unificada de clase

A través del ejemplo anterior, también podemos encontrar que cada método agrega un método de degradación de configuración y el código se expande.
Podemos usar @DefaultProperties(defaultFallback = "") para configurar de manera uniforme el manejo de excepciones globales para los métodos de la clase. Solo aquellos que deben configurarse por separado pueden usar el método anterior.
Modificar el AuthController

@RestController
@RequestMapping("/auth")
@DefaultProperties(defaultFallback = "globalFallbackHandler")
public class AuthController {
    
    

    @Autowired
    AuthService authService;

    @PostMapping("login")
    public String login(@RequestBody String name)
    {
    
    
        return authService.getUserInfo(name);
    }

    @PostMapping("/login/timeout")
    @HystrixCommand
    public String loginTimeout(@RequestBody String name)
    {
    
    
        int a =1/0;
        return authService.getUserInfoTimeOut(name);
    }

    /**
     * 全局的降级方法
     */
    public String globalFallbackHandler() {
    
    
        return "/(ㄒoㄒ)/调用登录接口超时或异常：\t" + "\t当前线程池名字" + Thread.currentThread().getName();
    }

    /**
     * 超时访问的降级方法
     *
     * @param username
     * @return
     */
    public String loginTimeOutHandler(String username) {
    
    
        return "/(ㄒoㄒ)/全局异常降级处理：\t" + "\t当前线程池名字" + Thread.currentThread().getName();
    }

}

inserte la descripción de la imagen aquí
Como se muestra en la figura, establecemos un método de degradación global y luego escribimos una excepción en a= 1/0 para probar el efecto.
inserte la descripción de la imagen aquí

Configuración unificada global

Hystrix también puede configurar la interfaz de simulación de manera uniforme. Por ejemplo, si el servidor está inactivo, se puede tratar de manera uniforme la degradación del servicio. Solo necesita agregar una clase de implementación para el procesamiento de degradación del servicio a la interfaz definida por el cliente de Fingir para lograr el desacoplamiento. Agregue una clase de manejo de excepciones AuthFallbakServiceImpl para implementar la clase AuthFallbakServiceImpl
de interfaz con anotaciones fingidas
inserte la descripción de la imagen aquí

@Component
public class AuthFallbakServiceImpl implements AuthService {
    
    
    @Override
    public String getUserInfo(String username) {
    
    
        return "====AuthService fall back getUserInfo，o(╥﹏╥)o====";
    }

    @Override
    public String getUserInfoTimeOut(String username) {
    
    
        return "====AuthService fall back getUserInfoTimeOut，o(╥﹏╥)o====";
    }
}

Al mismo tiempo, modifique la información de la anotación AuthService @FeignClient

@Component
@FeignClient(value = "LF-HYSTRIX-USER",fallback = AuthFallbakServiceImpl.class)
public interface AuthService {
    
    

    @GetMapping("/user/info/{username}")
    String getUserInfo(@PathVariable("username") String username);

    @GetMapping("/user/info/timeout/{username}")
    String getUserInfoTimeOut(@PathVariable("username") String username);

}

Prueba
Inicie el proyecto
Apague el usuario del servidor intencionalmente, simule el tiempo de inactividad del usuario del servidor y luego solicite la interfazinserte la descripción de la imagen aquí

Disyuntor de servicio

Mecanismo de fusible de Hystrix

  1. Disyuntor El
    disyuntor de Hystrix se abrirá cuando la llamada de servicio falle o se agote el tiempo de espera. Cuando el disyuntor está abierto, Hystrix ejecutará la lógica de reserva y reenviará la solicitud al servicio de reserva. La condición para que se abra el disyuntor suele ser que la tasa de fallas de la solicitud alcance un cierto umbral dentro de un cierto período de tiempo. Cuando se abre el disyuntor, Hystrix comprobará si el servicio original debe volver a intentarse a través de la tarea programada. Si el servicio es normal después de volver a intentar la solicitud, el disyuntor se cerrará.
  2. Control de tiempo de espera
    El control de tiempo de espera se realiza configurando el valor máximo del tiempo de respuesta del servicio. Cuando el tiempo de respuesta del servicio supere el valor máximo predeterminado, Hystrix reenviará la solicitud de servicio al servicio de reserva.
  3. Control de fusibles
    El control de fusibles se logra mediante el establecimiento de umbrales. Cuando la tasa de fallas de la solicitud de servicio alcanza cierto umbral, Hystrix abrirá automáticamente el disyuntor y reenviará la solicitud al servicio de reserva. Cuando la tasa de éxito de la solicitud de servicio alcanza un cierto umbral dentro de un período de tiempo, Hystrix cerrará automáticamente el disyuntor y volverá a llamar al servicio original.
  4. Aislamiento de recursos
    El aislamiento de recursos se logra mediante el aislamiento de grupos de subprocesos y el aislamiento de semáforos. El aislamiento del grupo de subprocesos se logra colocando las solicitudes de servicio en grupos de subprocesos separados para evitar la interferencia mutua entre las solicitudes de servicio. El aislamiento de semáforos se implementa limitando el número de solicitudes simultáneas para evitar la sobrecarga del servicio.

Código de configuración del fusible

Probamos en el usuario del servidor
y agregamos el siguiente código al controlador

// =====服务熔断=====
    @HystrixCommand(fallbackMethod = "userCircuitBreaker_fallback", commandProperties = {
    
    
            @HystrixProperty(name = "circuitBreaker.enabled", value = "true"),// 是否开启断路器
            @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),// 请求次数
            @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000"),// 时间窗口期
            @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60"),// 失败率达到多少后跳闸
    })
    @GetMapping("/circuit/{id}")
    public String paymentCircuitBreaker(@PathVariable("id") Integer id) {
    
    
        if (id < 0) {
    
    
            int a =1/0;
        }
        String serialNumber = UUID.randomUUID().toString();

        return Thread.currentThread().getName() + "\t" + "调用成功，流水号: " + serialNumber;
    }

    public String userCircuitBreaker_fallback(@PathVariable("id") Integer id) {
    
    
        return "id 不能负数，请稍后再试，/(ㄒoㄒ)/~~   id: " + id;
    }

prueba

Probado una vez solo, dos casos entero y negativo, sin problema
inserte la descripción de la imagen aquí

inserte la descripción de la imagen aquí
Luego, pruebe el número negativo varias veces seguidas, haciendo que entre en el método alternativo. Luego pruebe el número positivo y descubra que el número positivo también comienza a informar un error. Espere un momento antes de que el número positivo vuelva a la normalidad. Este tiempo de espera es el período de la ventana de tiempo. El parámetro del período de la ventana de tiempo representa el tiempo durante la
suspensión después de que se enciende el disyuntor, es decir, durante este período, HystrixCommand se negará a intentar ejecutar el comando, pero devolverá directamente una respuesta de respaldo (si se define la lógica de respaldo).

Específicamente, cuando HystrixCommand ejecuta una solicitud, si el tiempo de espera, la falla, el grupo de subprocesos está lleno, etc. alcanzan un determinado umbral, HystrixCommand cambiará al estado abierto y el disyuntor interceptará la solicitud y devolverá una respuesta alternativa. Al mismo tiempo, el parámetro sleepWindowInMilliseconds iniciará una ventana de suspensión para limitar la ejecución de solicitudes posteriores, y solo después de que finalice el período de suspensión, intentará ejecutar HystrixCommand nuevamente.
inserte la descripción de la imagen aquí

Tipo de fusible

  • Estado de fusible abierto: cuando el sistema es anormal o la carga es demasiado alta, el fusible entrará en el estado de fusible abierto, dejará de enviar solicitudes al sistema y devolverá directamente una respuesta de error predefinida (como un retroceso). Durante este período, el sistema no recibirá ninguna solicitud nueva hasta que alcance el tiempo de espera del fusible (también conocido como tiempo de inactividad) o el número de reintentos de solicitud y entre en el estado de medio abierto del fusible.
  • Estado de fusible cerrado: en circunstancias normales, el fusible está en estado cerrado quemado, lo que permite que el sistema procese las solicitudes normalmente y registre la tasa de éxito de la solicitud y el tiempo de respuesta y otros indicadores para el ajuste adaptativo del fusible.
  • Estado semiabierto: después de que el tiempo de espera del fusible o el número de reintentos de solicitud alcanza el umbral, el fusible entra en estado semiabierto. En este estado, el disyuntor permite que una o más solicitudes pasen al sistema para probar la disponibilidad y la estabilidad del sistema. Si estas solicitudes tienen éxito, el interruptor automático entrará en el estado de interruptor automático desactivado y se volverán a calcular los parámetros y las métricas del interruptor automático. Si estas solicitudes fallan, el interruptor automático volverá a entrar en el estado de apertura del interruptor automático y evitará que lleguen más solicitudes al sistema hasta el siguiente tiempo de espera del interruptor automático.

¿Cuándo entra en juego el disyuntor?

inserte la descripción de la imagen aquí

  • Umbral de solicitud total: especifique el valor mínimo del número total de solicitudes que el interruptor automático debe recibir dentro de un período de tiempo. Si el número total de solicitudes cae por debajo de este umbral, el disyuntor no se abrirá, incluso si hubo algunas solicitudes fallidas durante ese tiempo. Si el número total de solicitudes está por encima de este umbral, se puede abrir un disyuntor, lo que impide que más solicitudes lleguen al servicio y protege el sistema de cargas y daños adicionales.

  • Ventana de tiempo de la instantánea: especifica el período de tiempo para que el interruptor automático recopile estadísticas. Durante este período de tiempo, el interruptor automático registrará indicadores como el tiempo de respuesta del servicio, la tasa de éxito y la tasa de falla, y realizará ajustes adaptativos basados ​​en estos indicadores. Si la ventana de tiempo de la instantánea es demasiado corta, es posible que el disyuntor no refleje con precisión la carga y las condiciones anormales del sistema; si la ventana de tiempo de la instantánea es demasiado larga, el disyuntor puede causar demoras innecesarias e impacto en el tiempo de respuesta y fallas del sistema. tasa.

  • Umbral de porcentaje de error: especifique el umbral para el porcentaje de solicitudes fallidas registradas por el disyuntor en la ventana de tiempo de la instantánea con respecto al número total de solicitudes. Si el porcentaje de error supera este umbral, se puede abrir un disyuntor, lo que impide que lleguen más solicitudes al servicio y devuelve una respuesta de error predefinida (como una reserva) para proteger el sistema de daños y cargas adicionales. Si el porcentaje de error está por debajo de este umbral, el disyuntor permanecerá cerrado, permitiendo que las solicitudes lleguen al servicio con normalidad.

flujo de trabajo hystrix

inserte la descripción de la imagen aquí
El flujo de trabajo de Hystrix es el siguiente:

  1. Las aplicaciones realizan llamadas remotas o llamadas locales a través de HystrixCommand.
  2. HystrixCommand contiene una o más instancias de HystrixObservableCommand, y cada instancia de HystrixObservableCommand es responsable de una llamada de servicio.
  3. HystrixCommand ejecuta la llamada de servicio real ejecutando el método run().
  4. HystrixCommand usa HystrixThreadPool para administrar grupos de subprocesos y usa HystrixCommandKey y HystrixThreadPoolKey para identificar y clasificar grupos de subprocesos.
  5. HystrixCommand utiliza HystrixCommandProperties en la llamada de servicio para configurar el comportamiento del interruptor automático, incluida la ventana de tiempo del interruptor automático, la tasa de error, el tiempo de espera, etc.
  6. Si hay un problema con la llamada de servicio, HystrixCommand ejecutará el método fallback() y devolverá un resultado alternativo.
  7. Si la proporción de errores de las llamadas de servicio supera un determinado umbral, HystrixCommand abrirá el interruptor automático y activará el evento de apertura del interruptor automático.
  8. Después de abrir el interruptor automático, HystrixCommand ejecutará el método circuitBreaker() y rechazará todas las llamadas de servicio dentro de un período de tiempo determinado.
  9. Si el interruptor automático no recibe una nueva llamada de servicio dentro de un período de tiempo determinado, ingresa al estado semiabierto y HystrixCommand intentará ejecutar una llamada de servicio.
  10. Si la llamada de servicio tiene éxito, el disyuntor se cerrará; de lo contrario, permanecerá abierto.

Servicio de monitoreo HystrixDashboard

servicio de compilación

Nuevo módulo
cloud-consumer-hystrix-dashboard9999
inserte la descripción de la imagen aquí
pom.xml

<dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

aplicación.yml

server:
  port: 9999

Clase de inicio
HystrixDashboardMain9999

@SpringBootApplication
@EnableHystrixDashboard
public class HystrixDashboardMain9999 {
    
    

    public static void main(String[] args) {
    
    
        SpringApplication.run(HystrixDashboardMain9999.class, args);
    }

}


Agregue el siguiente código a la clase de inicio del servidor
inserte la descripción de la imagen aquí

    @Bean
    public ServletRegistrationBean getServlet() {
    
    
        HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
        ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);
        registrationBean.setLoadOnStartup(1);
        registrationBean.addUrlMappings("/hystrix.stream");
        registrationBean.setName("HystrixMetricsStreamServlet");
        return registrationBean;
    }

prueba

Visite http://localhost:9999/hystrix y complete la dirección del servidor http://localhost:9001/hystrix.stream
inserte la descripción de la imagen aquí
para ingresar a la página de monitoreo
inserte la descripción de la imagen aquí
Solicite la interfaz del servidor y podrá ver los datos de monitoreo.
Descripción de la interfaz del gráfico de seguimiento
inserte la descripción de la imagen aquí

Supongo que te gusta

Origin blog.csdn.net/qq_33129875/article/details/129625645
Recomendado
Clasificación
Diario
Más
2024-05-19(0)
2024-05-18(30)
2024-05-17(4)
2024-05-16(22)
2024-05-15(5)
2024-05-14(10)
2024-05-13(7)
2024-05-12(22)
2024-05-11(31)
2024-05-10(32)

Code World

© 2018 codetd.com