Flujo de trabajo de Hystrix

La forma en que Hystrix maneja las solicitudes se describe en detalle en el sitio web oficial: https://github.com/Netflix/Hystrix/wiki/How-it-Works , este artículo se centra en el siguiente diagrama de flujo para presentar el proceso principal;

Hystrix envuelve nuestras llamadas entre sistemas en Commans para su ejecución. Un ejemplo simple:

public class TestCommand extends HystrixCommand<Integer> {
 
    private TestServiceA serviceA;
 
    private int index;
 
    private static HystrixCommandProperties.Setter setter = HystrixCommandProperties.Setter()
                                                                                    //至少有10个请求，熔断器才进行错误率的计算
                                                                                    .withCircuitBreakerRequestVolumeThreshold(3)
                                                                                    //熔断器中断请求5秒后会进入半打开状态,放部分流量过去重试
                                                                                    .withCircuitBreakerSleepWindowInMilliseconds(5000)
                                                                                    //错误率达到50开启熔断保护
//                                                                                    .withCircuitBreakerErrorThresholdPercentage(30)
                                                                                    .withExecutionIsolationSemaphoreMaxConcurrentRequests(2)
                                                                                    .withExecutionTimeoutEnabled(true)
                                                                                    .withExecutionTimeoutInMilliseconds(1000);
 
    protected TestCommand(TestServiceA serviceA, int index) {
        super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("testGroupKey"))
        .andCommandKey(HystrixCommandKey.Factory.asKey("testCommandKey"))
        .andCommandPropertiesDefaults(setter)

                 .andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter().withCoreSize(10)));
        this.serviceA = serviceA;
        this.index = index;
    }
 
    @Override
    protected Integer run() throws Exception {
        return serviceA.service(index);
    }
 
    @Override
    protected Integer getFallback() {
        // if service execute fail, do sth
        return -1;
    }
 
}

A continuación, se explica la lógica específica del diagrama de flujo;

1. Solicitud de embalaje:

　Puede utilizar la herencia HystrixCommand o HystrixObservableCommand para ajustar métodos comerciales;

2. Inicie una solicitud:

　Utilice ejecutar que llama al comando para ejecutar una llamada a un método comercial;

　Además de proporcionar el método de ejecución, Hystrix también proporciona 3 formas de ingresar todas las solicitudes:

K value = command.execute();

Future<K> fValue = command.queue();

Observable<K> ohValue = command.observe(); //hot observable

Observable<K> ocValue = command.toObservable(); //cold observable

　　Como se muestra en la FIG:

　　Ejecutar la llamada sincrónica ejecutar el método, queue (). Get () se llamará al método, queue () llamará a toObservable (). ToBlocking (). ToFuture ();

　　Por lo tanto, todas las llamadas a métodos dependen de las llamadas a métodos observables, pero depende de si deben llamarse de forma sincrónica o asincrónica;

3. Procesamiento de caché:

　　Cuando llegue la solicitud, determinará si la solicitud está habilitada para el almacenamiento en caché (está habilitado de manera predeterminada) y luego determinará si la solicitud actual lleva la clave de caché;

　　Si golpea la caché, regresa directamente, de lo contrario, ingresa al resto de la lógica;

4. Juzgue si el disyuntor está abierto (fusible):

　　El disyuntor es el núcleo del diseño de Hystrix El disyuntor es un medio importante para lograr una falla rápida (el disyuntor se abre y vuelve a fallar directamente);

　　Puede configurar el disyuntor para que se abra durante un cierto período de tiempo, puede intentar realizar una solicitud comercial (el valor predeterminado es 5000 milisegundos);

5. Determine si realizar una solicitud comercial (si la solicitud debe aislarse o degradarse):

　　Antes de realizar una solicitud comercial, juzgará si es necesario solicitar servicios comerciales de acuerdo con la calidad de procesamiento del servicio actual;

　　Si la calidad del servicio actual es baja (el grupo de subprocesos / cola / semáforo está lleno), también fallará directamente;

　　Elección de grupo de subprocesos o semáforo (el valor predeterminado es grupo de subprocesos):

　　　　La principal ventaja del grupo de subprocesos es el aislamiento del cliente y la configuración del tiempo de espera, pero si se trata de una solicitud masiva de baja latencia, la pérdida causada por el cambio frecuente de subprocesos también es considerable.En este caso, podemos usar la estrategia de semáforo;

　　　　La principal desventaja del semáforo es que no puede manejar tiempos de espera, después de que la solicitud es enviada al cliente, si está pendiente por el cliente, necesita esperar eternamente;

6. Ejecutar solicitud comercial:

　　La calidad del servicio actual es mejor, luego la solicitud se enviará al servidor comercial;

　　`HystrixObservableCommand.construct()` o `HystrixCommand.run()`

7. Vigilancia de la salud:

　　De acuerdo con los resultados de ejecución de los métodos comerciales históricos, las estadísticas de los indicadores de salud del servicio actual se utilizan como base para acciones tales como si el interruptor automático está quemado o no;　　