Hystrix's workflow

How Hystrix handles requests is described in detail on the official website: https://github.com/Netflix/Hystrix/wiki/How-it-Works , this article focuses on the following flow chart to introduce the main process;

Hystrix wraps our inter-system calls into Commans for execution. A simple example:

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;
    }
 
}

The following explains the specific logic in the flowchart;

1. Packaging request:

　You can use inheritance HystrixCommand or HystrixObservableCommand to wrap business methods;

2. Initiate a request:

　Use execute that calls Command to execute a business method call;

　In addition to providing the execute method, Hystrix also provides 3 ways to enter all requests:

K value = command.execute();

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

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

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

　　As shown in FIG:

　　Execute synchronous call execute method, queue().get() method will be called, queue() will call toObservable().toBlocking().toFuture();

　　Therefore, all method calls depend on Observable method calls, but it depends on whether they need to be called synchronously or asynchronously;

3. Cache processing:

　　When the request comes, it will determine whether the request is enabled for caching (it is enabled by default), and then determine whether the current request carries the cache key;

　　If it hits the cache, it returns directly; otherwise, it enters the rest of the logic;

4. Judge whether the circuit breaker is open (fuse):

　　The circuit breaker is the core of Hystrix's design. The circuit breaker is an important means to achieve rapid failure (the circuit breaker opens and returns to failure directly);

　　You can set the circuit breaker to open for a certain period of time, you can try to make a business request (the default is 5000 milliseconds);

5. Determine whether to make a business request (whether the request needs to be isolated or degraded):

　　Before making a business request, it will judge whether it is necessary to request business services according to the current service processing quality;

　　If the current service quality is low (the thread pool/queue/semaphore is full), it will also fail directly;

　　Choice of thread pool or semaphore (the default is thread pool):

　　　　The main advantage of the thread pool is client isolation and timeout settings, but if it is a massive low-latency request, the loss caused by frequent thread switching is also considerable. In this case, we can use the semaphore strategy;

　　　　The main disadvantage of semaphore is that it cannot handle timeouts. After the request is sent to the client, if it is pending by the client, it needs to wait forever;

6. Execute business request:

　　The current service quality is better, then the request will be submitted to the business server;

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

7. Health monitoring:

　　According to the execution results of historical business methods, statistics of current service health indicators are used as a basis for actions such as whether the circuit breaker is blown or not;　　