En la arquitectura de microservicios actual, un problema importante es que las llamadas entre servicios generarán muchos retrasos y errores, lo que afectará el rendimiento y la confiabilidad de toda la aplicación. Para resolver este problema, Netflix desarrolló una biblioteca llamada Hystrix, que proporciona un mecanismo para lograr la tolerancia a fallas, lo que puede ayudar a lidiar con los retrasos y fallas inevitables en los sistemas distribuidos. Hystrix proporciona soluciones de alta disponibilidad y alto rendimiento para sistemas distribuidos mediante el uso de tecnologías como la tecnología de aislamiento, el modo de disyuntor y los grupos de recursos.

1.2 Características y ventajas de Hystrix

Hystrix es un marco tolerante a fallas de código abierto, que se utiliza principalmente en la fusión de servicios, la degradación de servicios, el aislamiento de grupos de subprocesos y otros aspectos en sistemas distribuidos. Las siguientes son las características y ventajas de Hystrix:

Fusión de servicios: Hystrix puede fusionar automáticamente los servicios no disponibles en función de la tasa de fallas de las solicitudes y la cantidad total de solicitudes para evitar una avalancha de servicios.

Degradación del servicio: Hystrix puede devolver un resultado alternativo a través del método de respaldo para garantizar la disponibilidad del sistema cuando el servicio no está disponible.

Aislamiento del grupo de subprocesos: Hystrix utiliza un grupo de subprocesos independiente para que cada servicio procese las solicitudes, lo que evita que la estabilidad de toda la aplicación se vea afectada por un tiempo de espera o un error del servicio.

Monitoreo en tiempo real: Hystrix proporciona funciones de monitoreo e informes en tiempo real, que pueden monitorear fácilmente las llamadas de servicio y las fallas.

Control adaptativo: Hystrix puede controlar de forma adaptativa el tráfico y la concurrencia de servicios para evitar que el sistema se sobrecargue.

Capacidad de conexión: Hystrix se puede integrar con otros marcos y tecnologías de código abierto, como Spring Cloud, Netflix Eureka, etc., para proporcionar funciones más ricas y un mayor rendimiento.

2. El concepto básico de Hystrix

2.1, comando Hystrix (HystrixCommand)

Proporciona una gran cantidad de funciones de gestión y control de llamadas de servicio, lo que nos facilita lograr la confiabilidad y estabilidad de las llamadas de servicio; es una clase proporcionada por Hystrix para encapsular la lógica de llamadas de servicio. Su función principal es envolver una solicitud de llamada de servicio en un objeto HystrixCommand y proporcionar las siguientes funciones:

Control de tiempo de espera: HystrixCommand permite configurar el período de tiempo de espera. Cuando el tiempo de la llamada de servicio excede el tiempo especificado, Hystrix interrumpirá la llamada de servicio y devolverá una respuesta alternativa.

Control de fusibles: HystrixCommand puede realizar el control de fusión en las llamadas de servicio. Cuando la tasa de fallas de la llamada de servicio supera el umbral especificado, Hystrix activará la protección de fusión, reenviará la solicitud de llamada de servicio a la lógica de reserva y detendrá temporalmente la solicitud de llamada de servicio.

Control de degradación: HystrixCommand proporciona lógica de respaldo. Cuando una llamada de servicio falla o se agota, Hystrix llamará automáticamente a la lógica de respaldo para devolver una respuesta, evitando el reenvío de solicitudes de llamadas de servicio fallidas o agotadas a los servicios posteriores, lo que provoca un efecto de avalancha.

Estadísticas: HystrixCommand puede contar la tasa de éxito, el tiempo de respuesta, la tasa de error y otra información de las solicitudes de llamadas de servicio, lo cual es conveniente para que los desarrolladores analicen el rendimiento y la estabilidad de las solicitudes de llamadas de servicio.

Almacenamiento en caché de solicitudes: HystrixCommand puede almacenar en caché las solicitudes de llamadas de servicio para evitar solicitudes de llamadas de servicio repetidas y mejorar el rendimiento del sistema y la velocidad de respuesta.

2.2, grupo de subprocesos Hystrix (HystrixThreadPool)

Proporciona un grupo de subprocesos independientes para que cada instancia de comando de Hystrix ejecute comandos. En Hystrix, el subproceso de ejecución de comandos y el subproceso de llamada de comando están separados, por lo que la función del conjunto de subprocesos de Hystrix es proporcionar un conjunto de subprocesos aislado para la ejecución de comandos.

La configuración del grupo de subprocesos Hystrix se puede configurar a través de HystrixThreadPoolProperties, incluidos parámetros como el tamaño del grupo de subprocesos, el tamaño de la cola y el tiempo de supervivencia del subproceso. El tamaño del grupo de subprocesos determina el número máximo de comandos que se pueden ejecutar al mismo tiempo. Si se alcanza el número máximo, los comandos posteriores serán rechazados. El tamaño de la cola significa que cuando todos los subprocesos del grupo de subprocesos ejecutan comandos, los nuevos comandos se colocarán en una cola para su ejecución. Si la cola está llena, los comandos subsiguientes serán rechazados. El tiempo de supervivencia del subproceso determina el tiempo de supervivencia más largo de un subproceso inactivo.

La ventaja de usar el grupo de subprocesos Hystrix es que los comandos se pueden aislar y controlar con una granularidad más fina, lo que evita los problemas de agotamiento del grupo de subprocesos y contención de recursos. Al mismo tiempo, al ajustar el tamaño del grupo de subprocesos y el tamaño de la cola, se puede mejorar el rendimiento y el rendimiento del sistema al tiempo que se garantiza la calidad del servicio.

2.3, fusible Hystrix (disyuntor Hystrix)

Se utiliza para implementar el patrón de disyuntor para proteger la comunicación entre la persona que llama y el destinatario del servicio. El fusible es un mecanismo para evitar fallas en cascada de aplicaciones. Cuando un error o anomalía alcanza un cierto umbral dentro de un cierto período de tiempo, el fusible se disparará automáticamente, rechazará directamente las solicitudes posteriores y regresará directamente a un valor predeterminado dentro de un período de tiempo. Respuesta de error para evitar el impacto de una gran cantidad de solicitudes no válidas en el servicio.

HystrixCircuitBreaker puede monitorear la ejecución de los comandos de Hystrix y juzgar si abrir el fusible de acuerdo con una determinada estrategia. Cuando se abre el fusible, Hystrix cortocircuitará la solicitud, ya no realizará llamadas y devolverá directamente la respuesta de error preestablecida. Cuando el fusible está cerrado, Hystrix reanudará el flujo normal de llamadas.

La implementación de HystrixCircuitBreaker depende de HystrixCommand y HystrixThreadPool, que ajusta dinámicamente el estado del fusible según la ejecución de estos dos componentes. Cuando el número de fallas en la ejecución de HystrixCommand exceda el umbral, el fusible se abrirá; cuando el número de ejecución exitosa de HystrixCommand exceda el umbral, el fusible se cerrará.

HystrixCircuitBreaker proporciona una variedad de parámetros de configuración que se pueden usar para personalizar el comportamiento del interruptor automático. Por ejemplo, podemos configurar el tiempo de suspensión cuando se abre el fusible, el umbral de tasa de error, el período de ventana, etc. Estos parámetros se pueden configurar mediante anotaciones de HystrixCommand y HystrixThreadPool, o mediante archivos de configuración.

3. Uso de Hystrix

3.1, configuración Hystrix

3.1.1, configuración de código

La configuración de Hystrix es muy flexible y puede ajustarse y optimizarse de acuerdo con escenarios comerciales específicos. Aquí hay algunas configuraciones:

Configure en el código a través de clases como HystrixCommandProperties o HystrixThreadPoolProperties.
Configure a través de anotaciones, como el uso de anotaciones @HystrixCommand en los métodos que deben ejecutarse y establezca atributos como fallbackMethod y commandProperties en las anotaciones.
Mediante la configuración en el archivo de configuración, como establecer propiedades relacionadas en application.properties o application.yml.

3.1.2 Introducción a las propiedades de configuración de Hystrix

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: tiempo de espera de ejecución del comando, el valor predeterminado es 1000 milisegundos.

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: tiempo de espera de ejecución del comando, el valor predeterminado es 1000 milisegundos.

hystrix.command.default.execution.timeout.enabled: Ya sea para habilitar el tiempo de espera de ejecución del comando, el valor predeterminado es verdadero.

hystrix.command.default.execution.timeout.enabled: Ya sea para habilitar el tiempo de espera de ejecución del comando, el valor predeterminado es verdadero.

hystrix.command.default.circuitBreaker.requestVolumeThreshold: el volumen de solicitud para que se abra el interruptor automático, el valor predeterminado es 20.

hystrix.command.default.circuitBreaker.errorThresholdPercentage: Umbral de tasa de error, el disyuntor se abrirá después de alcanzar este valor, el valor predeterminado es 50.

hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds: el tiempo para dormir después de abrir el disyuntor, el valor predeterminado es 5000 milisegundos.

hystrix.command.default.metrics.rollingStats.timeInMilliseconds: El tamaño de la ventana de tiempo estadística, el valor predeterminado es 10000 milisegundos.

hystrix.threadpool.default.coreSize: la cantidad de subprocesos principales en el grupo de subprocesos; el valor predeterminado es 10.

hystrix.threadpool.default.maxQueueSize: la longitud máxima de la cola del grupo de subprocesos, el valor predeterminado es -1, lo que significa usar SynchronousQueue.

hystrix.threadpool.default.queueSizeRejectionThreshold: umbral de rechazo de la cola, cuando la longitud de la cola alcanza este valor, se rechazarán las nuevas solicitudes, el valor predeterminado es 5.

3.2 Cómo usar los comandos de Hystrix en el código

Use el objeto HystrixCommand.Setter para establecer el nombre del grupo y el tiempo de espera de ejecución del comando Hystrix

3.2.1 Definir los comandos de Hystrix

Los comandos de Hystrix se pueden definir heredando la clase HystrixCommand e implementando los métodos run() y getFallback(). El método run() se usa para ejecutar la lógica comercial real, y el método getFallback() se usa para definir la lógica de respaldo cuando falla la ejecución del comando o se agota el tiempo de espera.

public class MyHystrixCommand extends HystrixCommand<String> {
    
    private final String name;

    public MyHystrixCommand(String name) {
        super(HystrixCommandGroupKey.Factory.asKey("MyHystrixCommandGroup"));
        this.name = name;
    }

    @Override
    protected String run() throws Exception {
        // 实际的业务逻辑
        return "Hello " + name + "!";
    }

    @Override
    protected String getFallback() {
        // 命令执行失败或超时时的回退逻辑
        return "Fallback for " + name;
    }
}

3.2.2 Ejecutar comandos de Hystrix

Cuando sea necesario ejecutar un comando Hystrix, cree una instancia de MyHystrixCommand y llame al método execute() para ejecutar el comando Hystrix. Por ejemplo:

String result = new MyHystrixCommand("World").execute();

3.2.3, configuración Hystrix

El comportamiento de los comandos de Hystrix se puede ajustar a través de la configuración. El comportamiento del comando se puede configurar configurando el objeto HystrixCommand.Setter en el constructor MyHystrixCommand. Por ejemplo:

public MyHystrixCommand(String name) {
    super(HystrixCommand.Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("MyHystrixCommandGroup"))
            .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
                    .withExecutionTimeoutInMilliseconds(500)));
    this.name = name;
}

3.3 Cómo usar el panel de monitoreo Hystrix

Cree un proyecto Maven y agregue las siguientes dependencias de Hystrix:

Hystrix-metrics-event-stream: envíe las métricas de monitoreo de Hystrix al navegador en forma de SSE (Eventos enviados por el servidor).
Hystrix-codahale-metrics-publisher: Salida de indicadores de monitoreo de Hystrix en forma de Dropwizard Metrics.
Hystrix-dashboard: el tablero de Hystrix, puede ver fácilmente el fusible, el aislamiento, la degradación y otros indicadores de Hystrix.
Hystrix-turbine: agregue y muestre los datos de múltiples Hystrix Dashboards para una gestión centralizada.
Ejemplos de Hystrix: código de muestra de Hystrix, incluido el uso básico de Hystrix, el uso de Hystrix Dashboard, el uso de Turbine, etc.

3.3.1 Agregue el paquete de dependencia Hystrix Dashboard a la aplicación

<dependency>
    <groupId>com.netflix.hystrix</groupId>
    <artifactId>hystrix-core</artifactId>
    <version>1.5.18</version>
</dependency>

3.3.2 Uso en código`@HystrixCommand`

Utilice anotaciones en el código @HystrixCommandpara marcar los métodos que requieren tolerancia a fallas y tolerancia a retrasos, y especifique el método alternativo en la anotación:

@HystrixCommand(fallbackMethod = "defaultHello")
public String hello(String name) {
    // 正常业务逻辑
    // ...
}

public String defaultHello(String name) {
    // fallback 逻辑
    // ...
}

3.3.3 Inicie Hystrix Dashboard en la clase principal:

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

3.3.4 Acceso en el navegador

Acceda a http://localhost:port/hystrix, ingrese la dirección URL de Hystrix Stream en la interfaz, por ejemplo: http://localhost:port/hystrix.stream, haga clic en el botón Monitor Stream y podrá ver el panel de monitoreo. En el panel de monitoreo, puede ver información como el estado de ejecución de cada comando Hystrix, el estado del fusible y el tráfico solicitado.

Nota: El panel de monitoreo Hystrix Dashboard debe usarse junto con Hystrix Stream. Aquí está managementrelacionado con el módulo Spring Boot Actuator, que se usa para iniciar el punto final de monitoreo de la aplicación. Este elemento de configuración debe agregarse en el archivo application.propertieso . application.ymlHystrix Stream se puede habilitar agregando los siguientes elementos de configuración:

management.endpoints.web.exposure.include=hystrix.stream

En cuarto lugar, el principio de funcionamiento de Hystrix

4.1, aislamiento del grupo de subprocesos

Hystrix proporciona dos estrategias de aislamiento de recursos: aislamiento de grupos de subprocesos y aislamiento de semáforos.

Aislamiento del grupo de subprocesos: el aislamiento del grupo de subprocesos creará un grupo de subprocesos para cada dependencia para procesar las solicitudes de esa dependencia. Los diferentes grupos de subprocesos dependientes están aislados entre sí. Incluso si la dependencia A falla y los recursos del grupo de subprocesos se agotan, no afectará a Otros recursos del grupo de subprocesos dependientes.

método de aislamiento	Ya sea para admitir el tiempo de espera	Ya sea para apoyar la fusión	principio de aislamiento	Si llamar de forma asíncrona	LF
aislamiento del grupo de subprocesos	Soporte, puede regresar directamente	Soporte, cuando el grupo de subprocesos alcanza el tamaño máximo, la solicitud activará la interfaz de reserva para fusionarse	Cada servicio utiliza un grupo de subprocesos independiente, y el subproceso de solicitud y el subproceso de procesamiento de reenvío no son los mismos	Puede ser asíncrono o síncrono. Mira el método de llamada	Es probable que el cambio de contexto grande de una gran cantidad de subprocesos cause una alta carga de la máquina
Aislamiento de semáforo	No compatible, si está bloqueado, solo se puede devolver llamando al protocolo (como: tiempo de espera del socket)	Compatible, cuando el semáforo alcanza maxConcurrentRequests. Volver a solicitar activará el respaldo	A través del contador del semáforo, el hilo de solicitud y el hilo de procesamiento de reenvío son los mismos	Llamada síncrona, no admite asíncrono	pequeño, solo un mostrador

2. Modo fusible

Hystrix es una biblioteca tolerante a fallas y latencia para sistemas distribuidos, que puede proteger los servicios o sistemas para que no continúen funcionando bajo una carga alta o fallas de componentes dependientes. Hystrix fue desarrollado por Netflix y ahora es parte de Spring Cloud.

El principio central de Hystrix es el patrón de disyuntores. Un disyuntor es un poderoso mecanismo de tolerancia a fallas que protege una aplicación de daños adicionales en caso de falla. En un sistema distribuido, si un servicio falla, otros servicios pueden verse afectados y todo el sistema falla. El modo fusible de Hystrix puede proteger en este caso.

El modo fusible de Hystrix se implementa por medio de un disyuntor. Cuando hay un problema con una solicitud de servicio, Hystrix almacenará en caché el resultado de la solicitud dentro del disyuntor. Si hay fallas de solicitud consecutivas, el disyuntor cambiará al estado abierto y las nuevas solicitudes ya no se enviarán directamente al servicio, sino que devolverán un resultado de respaldo preestablecido. Periódicamente, el disyuntor intentará volver a verificar el servicio durante un cierto período de tiempo y, si la verificación tiene éxito, el disyuntor cambiará al estado cerrado; de lo contrario, permanecerá abierto.

El modo de disyuntor de Hystrix también incluye un contador llamado disyuntor, que se utiliza para registrar la cantidad de solicitudes fallidas dentro de un período de tiempo. Cuando se alcance un umbral preestablecido, se abrirá el disyuntor. Después de encender el disyuntor, la solicitud del servicio ya no se enviará directamente al servicio, sino que se devolverá directamente el resultado de reserva para evitar una mayor carga en el servicio. Dentro de un cierto período de tiempo, Hystrix intentará periódicamente cerrar el disyuntor, si detecta que el servicio vuelve a la normalidad, el disyuntor se cerrará, de lo contrario, continuará abierto.

En resumen, el modo fusible de Hystrix puede proteger eficazmente los servicios en el sistema distribuido y evitar la falla de todo el sistema debido a la falla de un determinado servicio.

3. Modo de copia de seguridad

El modo de respaldo (Fallback Mode) en Hystrix se refiere a la ejecución de la lógica de respaldo cuando la ejecución del comando Hystrix falla o se agota el tiempo de espera. La lógica de reserva debe ser confiable y debe poder devolver datos o información a través de diferentes estados de la aplicación.

En Hystrix, la lógica de reserva la proporciona el método de reserva. El método Fallback es una estrategia de respaldo que proporciona algunos datos o lógica de respaldo cuando la lógica principal falla por algún motivo. El método Fallback debería poder regresar rápidamente, porque su propósito es manejar fallas y recuperación de fallas, no realizar operaciones complejas durante mucho tiempo.

El modo Fallback en Hystrix se puede implementar de las siguientes maneras:

Método de anotación: el método Fallback se puede especificar a través del atributo fallbackMethod en la anotación @HystrixCommand.

Método de programación: El método Fallback se puede especificar a través del método HystrixCommand.Setter.withFallback().

Cabe señalar que cuando se utiliza Hystrix, se debe especificar un método alternativo para cada HystrixCommand. Si no se especifica ningún método alternativo, se generará una excepción cuando la ejecución del comando falle o se agote el tiempo de espera.

En general, los modos alternativos pueden mejorar la confiabilidad y la estabilidad del sistema. Al utilizar el método Fallback, se puede proporcionar una lógica de respaldo cuando falla la lógica principal, para garantizar el funcionamiento normal del sistema.

4. Almacenamiento en caché de respuestas

Hystrix proporciona un caché de respuesta para almacenar en caché las respuestas a la misma solicitud para reducir la cantidad de llamadas al sistema backend y mejorar el rendimiento. Durante la ejecución del comando Hystrix, cuando la memoria caché de respuesta está habilitada, primero verificará si hay una respuesta correspondiente en la memoria caché y, de ser así, devolverá directamente la respuesta en la memoria caché sin realizar una solicitud al sistema de fondo. .

El uso del almacenamiento en caché de respuestas requiere configurar anotaciones en el comando Hystrix @CacheResulty HystrixCommandespecificar la clave almacenada en él. Para una implementación específica, consulte el siguiente código:

public class MyCommand extends HystrixCommand<String> {

    private final String cacheKey;

    public MyCommand(String cacheKey) {
        super(HystrixCommandGroupKey.Factory.asKey("MyCommandGroup"));
        this.cacheKey = cacheKey;
    }

    @Override
    protected String run() throws Exception {
        // 执行具体的业务逻辑
        return "Hello World";
    }

    @Override
    protected String getCacheKey() {
        return cacheKey;
    }

    @Override
    protected String getFallback() {
        return "Fallback";
    }

    @Override
    protected Setter getCommandProperties() {
        return Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("MyCommandGroup"))
                .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
                        .withExecutionIsolationStrategy(HystrixCommandProperties.ExecutionIsolationStrategy.THREAD)
                        .withCircuitBreakerEnabled(true)
                        .withRequestCacheEnabled(true)); // 开启响应缓存
    }

    @CacheResult // 设置缓存
    @Override
    public String execute() {
        return super.execute();
    }
}

En MyCommand, usamos @CacheResultanotaciones para habilitar el almacenamiento en caché de respuestas y getCacheKey()especificamos la clave de caché en el método. En getCommandProperties()el método, habilitamos el caché de solicitud para que al ejecutar el comando Hystrix, la respuesta se pueda obtener primero del caché. Al ejecutar execute()el método, si hay una respuesta correspondiente en el caché, el resultado en el caché se devuelve directamente. De lo contrario, run()se ejecutará la lógica comercial del método y el resultado se almacenará en caché.

Cabe señalar que la memoria caché de respuesta ocupará espacio en la memoria, y si la cantidad de datos almacenados en la memoria caché es demasiado grande, puede provocar un desbordamiento de la memoria. Por lo tanto, es necesario establecer razonablemente el período de validez de la memoria caché y el tamaño de la memoria caché para evitar efectos adversos en el rendimiento del sistema.

Cinco, escenarios de aplicación de Hystrix

Hystrix se usa principalmente para resolver problemas de tolerancia a fallas en sistemas distribuidos y se puede usar en diferentes niveles en el sistema, incluidos los niveles de front-end, servidor y base de datos. Estos son algunos escenarios de aplicación de Hystrix:

Llamada de servicio: Hystrix puede evitar problemas de avalancha de servicio causados por errores de parte confiable o tiempos de espera durante las llamadas de servicio.
Acceso a la base de datos: Hystrix puede evitar bloqueos de la aplicación causados por demasiadas conexiones a la base de datos o errores de acceso a la base de datos cuando la aplicación accede a la base de datos.
Acceso a recursos de red: Hystrix puede evitar bloqueos de aplicaciones causados por falta de disponibilidad de recursos o tiempo de espera cuando la aplicación accede a recursos externos.
Arquitectura de microservicios: en la arquitectura de microservicios, las dependencias entre servicios son complejas.Hystrix puede proporcionar un mecanismo de tolerancia a fallas en este entorno para garantizar la estabilidad de todo el sistema.
Aplicaciones de alto tráfico: en el caso de alta concurrencia, Hystrix puede limitar la cantidad de solicitudes simultáneas para evitar que el sistema se sobrecargue y provoque que el servicio no esté disponible.

En resumen, Hystrix es adecuado para varios escenarios tolerantes a fallas en sistemas distribuidos y puede proporcionar mecanismos de protección para evitar efectos de avalanchas en las aplicaciones y garantizar la confiabilidad y estabilidad del sistema.

Hystrix-Deje que GPT le diga cómo usarlo

1. ¿Qué es Hystrix?

1.1 Antecedentes y propósito de Hystrix

1.2 Características y ventajas de Hystrix

2. El concepto básico de Hystrix

2.1, comando Hystrix (HystrixCommand)

2.2, grupo de subprocesos Hystrix (HystrixThreadPool)

2.3, fusible Hystrix (disyuntor Hystrix)

3. Uso de Hystrix

3.1, configuración Hystrix

3.1.1, configuración de código

3.1.2 Introducción a las propiedades de configuración de Hystrix

3.2 Cómo usar los comandos de Hystrix en el código

3.2.1 Definir los comandos de Hystrix

3.2.2 Ejecutar comandos de Hystrix

3.2.3, configuración Hystrix

3.3 Cómo usar el panel de monitoreo Hystrix

3.3.1 Agregue el paquete de dependencia Hystrix Dashboard a la aplicación

3.3.2 Uso en código`@HystrixCommand`

3.3.3 Inicie Hystrix Dashboard en la clase principal:

3.3.4 Acceso en el navegador

En cuarto lugar, el principio de funcionamiento de Hystrix

4.1, aislamiento del grupo de subprocesos

2. Modo fusible

3. Modo de copia de seguridad

4. Almacenamiento en caché de respuestas

Cinco, escenarios de aplicación de Hystrix

Supongo que te gusta

Hystrix-Deje que GPT le diga cómo usarlo

1. ¿Qué es Hystrix?

1.1 Antecedentes y propósito de Hystrix

1.2 Características y ventajas de Hystrix

2. El concepto básico de Hystrix

2.1, comando Hystrix (HystrixCommand)

2.2, grupo de subprocesos Hystrix (HystrixThreadPool)

2.3, fusible Hystrix (disyuntor Hystrix)

3. Uso de Hystrix

3.1, configuración Hystrix

3.1.1, configuración de código

3.1.2 Introducción a las propiedades de configuración de Hystrix

3.2 Cómo usar los comandos de Hystrix en el código

3.2.1 Definir los comandos de Hystrix

3.2.2 Ejecutar comandos de Hystrix

3.2.3, configuración Hystrix

3.3 Cómo usar el panel de monitoreo Hystrix

3.3.1 Agregue el paquete de dependencia Hystrix Dashboard a la aplicación

3.3.2 Uso en código@HystrixCommand

3.3.3 Inicie Hystrix Dashboard en la clase principal:

3.3.4 Acceso en el navegador

En cuarto lugar, el principio de funcionamiento de Hystrix

4.1, aislamiento del grupo de subprocesos

2. Modo fusible

3. Modo de copia de seguridad

4. Almacenamiento en caché de respuestas

Cinco, escenarios de aplicación de Hystrix

Supongo que te gusta

3.3.2 Uso en código`@HystrixCommand`