Explicación detallada y práctica de Hystrix --- componente SpringCloud (4)

1. Introducción a Hystrix

Hystix significa puercoespín en inglés. Todo su cuerpo está cubierto de espinas. Parece que no es fácil meterse con él. Es un mecanismo de protección.
Hystrix también es un componente de Netflix.
Página de inicio: https://github.com/Netflix/Hystrix/

Hystrix es un dispositivo de conmutación, similar a un fusible fundido. Instale un fusible Hystrix en el lado del consumidor. Cuando
Hystrix monitorea que un servicio falla, el fusible se abrirá y el enlace de acceso al servicio se desconectará. Sin embargo, Hystrix no bloquea al consumidor del servicio ni le lanza una excepción, sino que le devuelve una respuesta alternativa esperada (FallBack). A través de las funciones de disyuntor y degradación de Hystrix, se evitan avalanchas de servicios y también se tiene en cuenta la experiencia del usuario. Por tanto, Hystrix es un mecanismo de defensa del sistema.

2. Problema de avalancha

Si Dependency-I falla para un servicio al que necesitamos acceder, en este momento, el servicio que llama a Dependency-I en nuestra aplicación también fallará, provocando el bloqueo. Por el momento, otras empresas parecen no verse afectadas.

Por ejemplo, ocurre una excepción en el microservicio I, la solicitud se bloquea y el usuario no recibirá una respuesta, luego el hilo de Tomcat no se liberará, por lo que llegan cada vez más solicitudes de usuarios y se bloquearán más y más hilos:

La cantidad de subprocesos y la concurrencia admitida por el servidor es limitada y la solicitud siempre está bloqueada, lo que provocará que se agoten los recursos del servidor, lo que provocará que todos los demás servicios no estén disponibles, formando un efecto de avalancha.

Esto es como una línea de producción de automóviles que produce diferentes automóviles y requiere el uso de diferentes piezas. Si una determinada pieza no se puede utilizar por diversas razones, hará que todo el automóvil no se pueda ensamblar y caiga en un estado de espera. Continúe ensamblando hasta que las piezas estén en su lugar. En este momento, si muchos modelos requieren esta pieza, toda la fábrica estará en estado de espera, lo que provocará que se paralice toda la producción. El alcance de una parte continúa ampliándose.

3. Degradación del servicio, aislamiento de subprocesos, principios.

Hystrix asigna un pequeño grupo de subprocesos para cada función de llamada de servicio. Si el grupo de subprocesos está lleno, la llamada será rechazada inmediatamente. La cola no se utiliza de forma predeterminada para acelerar el tiempo de determinación de fallas.

La solicitud del usuario ya no accederá directamente al servicio, sino que accederá al servicio a través del subproceso inactivo en el grupo de subprocesos. Si el grupo de subprocesos está lleno o la solicitud se agota , se degradará: aparecerá un mensaje de error o un resultado alternativo. ser devuelto al usuario .

Aunque la degradación del servicio provocará una falla en la solicitud, no provocará un bloqueo, ocupará hasta los recursos de subprocesos del servicio y no hará que se agoten todos los recursos del contenedor. El impacto de la falla está aislado en el grupo de subprocesos.

3.1 Práctica de degradación del servicio (implementada sobre la base de simulación)

paso:

1. Agregar dependencia de Hystrix
2. Habilitar la función de disyuntor en yml
3. Escribir lógica de degradación

1 Agregar dependencia de Hystrix

Dado que Feign también integra Hystix de forma predeterminada, no es necesario agregar dependencias por separado.

2. Active la función de fusión en yml.

Habilite la configuración del disyuntor en el servicio feign-hystrix-consumer-8080

feign:
  hystrix:
    enabled: true # 开启Feign的熔断功能

3. Escribe la lógica de degradación

1. Agregue la clase DepartServiceFallback a feign-provider-api para implementar la interfaz finge y escriba métodos de degradación específicos en cada método.

   

/**
 1. @ClassName: DepartServiceFallback
 2. @Description: 失败回调类
 3. @Author: wang xiao le
 4. @Date: 2023/05/11 21:56
 **/
@Component
public class DepartServiceFallback implements DepartService {
    
    
    @Override
    public boolean saveDepart(DepartVO depart) {
    
    
        return false;
    }

    @Override
    public boolean removeDepartById(int id) {
    
    
        return false;
    }

    @Override
    public boolean modifyDepart(DepartVO depart) {
    
    
        return false;
    }

    @Override
    public DepartVO getDepartById(int id) {
    
    
        DepartVO departVO = new DepartVO();
        departVO.setId(id);
        departVO.setName("查询异常");
        return departVO;
    }

    @Override
    public List<DepartVO> listAllDeparts() {
    
    
        return null;
    }
}

2. Especifique la clase de implementación recién escrita en DepartService

   

// 注意，接口名与方法名可以随意
// 参数指定了要访问的提供者微服务名称
//@FeignClient(url ="http://127.0.0.1:8081", value="abcmsc-provider-depart", path = "/provider/depart")
//@FeignClient(url ="${feign.client.url}", value="abcmsc-provider-depart", path = "/provider/depart")
@FeignClient(value="feign-provider", path = "/provider/depart",fallback = DepartServiceFallback.class)
public interface DepartService {
    
    
    @PostMapping("/save")
    boolean saveDepart(@RequestBody DepartVO depart);

    @DeleteMapping("/del/{id}")
    boolean removeDepartById(@PathVariable("id") int id);

    @PutMapping("/update")
    boolean modifyDepart(@RequestBody DepartVO depart);

    @GetMapping("/get/{id}")
    DepartVO getDepartById(@PathVariable("id") int id);

    @GetMapping("/list")
    List<DepartVO> listAllDeparts();
}

4. Reinicie la prueba

Solo reiniciamos al consumidor, no iniciamos el servicio del proveedor y simulamos el tiempo de inactividad del servicio del proveedor.

Al acceder a http://localhost:8080/consumer/depart/get/1
se muestra el resultado de la devolución de llamada fallida.

4. Disyuntor de servicio (Disyuntor), principio

4.1 Principio de fusión

Aunque el aislamiento puede evitar fallos en cascada en los servicios, para otros servicios que acceden al servicio I (el servicio defectuoso) , cada solicitud de procesamiento tiene que esperar varios segundos hasta el retorno, lo que obviamente es un desperdicio de recursos del sistema.

Por lo tanto, cuando Hystix determina que un servicio dependiente tiene una alta tasa de fallas, realizará un procesamiento de disyuntor en él: interceptará las solicitudes de servicios fallidos, fallará rápidamente y ya no bloqueará la espera, al igual que el disyuntor del circuito se desconecta para proteger el circuito.

Fusible, también llamado disyuntor, su palabra en inglés es: Circuit Breaker
Modelo de máquina de estados de fusibles de Hystix:

La máquina de estados tiene 3 estados:

• Cerrado: estado cerrado (el disyuntor está cerrado), se accede a todas las solicitudes normalmente.
• Abierto: estado abierto (el disyuntor está abierto), todas las solicitudes se degradarán. Hystix contará las solicitudes. Cuando el porcentaje de solicitudes fallidas alcance el umbral dentro de un cierto período de tiempo, se activará el fusible y se abrirá el disyuntor. El umbral de tasa de error predeterminado es 50% y el número de solicitudes es al menos 20.
• Medio abierto: Estado medio abierto. El estado abierto no es permanente. Entrará en tiempo de suspensión después de la apertura (el valor predeterminado es 5S). El disyuntor entrará automáticamente en estado medio abierto. En este momento, se liberará una solicitud. Si la solicitud es correcta, el disyuntor se cerrará. De lo contrario, permanecerá abierto y se ejecutará nuevamente el temporizador de suspensión de 5 segundos.

4.2.Práctica práctica

Para controlar con precisión el éxito o el fracaso de la solicitud, agregue una parte de lógica al negocio de llamadas de módulos-proveedor-fingidos:

    @GetMapping("/get/{id}")
    public DepartVO getHandle(@PathVariable("id") int id) {
    
    
        if(id == 1){
    
    
            throw new RuntimeException("太忙了");
        }
        return new DepartVO();
    }

De esta forma, si el parámetro id es 1, definitivamente fallará y, en otros casos, tendrá éxito.

Preparamos dos ventanas de solicitud:

• Una solicitud: http://localhost:8080/consumer/1, condenada al fracaso
• Una solicitud: http://localhost:8080/consumer/2, definitivamente exitosa

El umbral de activación predeterminado del fusible es 20 solicitudes, lo que no es fácil de activar. El tiempo de sueño es de 5 segundos, lo cual es demasiado corto y difícil de observar, por conveniencia de la prueba. Modificamos la política de disyuntores en la configuración del servicio al consumidor:

  hystrix:
    enabled: true # 开启Feign的熔断功能
    command:
      default:
        execution.isolation.thread.timeoutInMilliseconds: 2000
        circuitBreaker:
          errorThresholdPercentage: 50 # 触发熔断错误比例阈值，默认值50%
          sleepWindowInMilliseconds: 10000 # 熔断后休眠时长，默认值5秒
          requestVolumeThreshold: 10 # 触发熔断的最小请求次数，默认20

Interpretación :

• requestVolumeThreshold: El número mínimo de solicitudes para activar el disyuntor, el valor predeterminado es 20, aquí lo configuramos en 10 para facilitar la activación.
• errorThresholdPercentage: Proporción mínima de solicitudes fallidas que activan el disyuntor, valor predeterminado 50%
• sleepWindowInMilliseconds: Duración del sueño, el valor predeterminado es 5000 milisegundos, aquí está configurado en 10000 milisegundos para facilitar la observación del fenómeno de la fusión.

Cuando accedamos locamente a la solicitud con ID 1 (unas 10 veces), se activará el disyuntor. El disyuntor entrará en estado abierto y todas las solicitudes se degradarán.

En este momento, cuando acceda a la solicitud con ID 2, encontrará que la respuesta también falló y el tiempo de falla es muy corto, solo unos 20 milisegundos:

5.Análisis del código fuente central de Hystrix