Hystrix系列之执行原理分析

上文中介绍了Hystrix的由来，本文会深入分析Hystrix的执行过程。

Hystrix的大部分逻辑基于RxJava，其实现让很热多人望而却步，停留在了仅仅使用的地步，从一个简单的HelloWorld开始。

public class CommandHelloWorld extends HystrixCommand {

    private final String name;

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

    @Override
    protected String run() {
        // 省略业务逻辑
        // 该方法可能会抛出异常
        return "Hello " + name + "!";
    }

    @Override
    protected String getFallback() {
        return "Hello Failure " + name + "!";
    }
}

通过简单的实现run方法和getFallback 方法，CommandHelloWorld具备了熔断降级的功能，其中HystrixCommand提供了4个方法：execute()，queue()，observe()，toObservable()，平时只需要关注execute和queue即可。

• queue()：
  异步调用，返回一个Future对象，后面可以通过Future获取结果。
• execute()
  同步调用，调用后直接block住，直到依赖服务返回结果，或者抛出异常。

public R execute() {
    try {
        return queue().get();
    } catch (Exception e) {
        throw Exceptions.sneakyThrow(decomposeException(e));
    }
}

其实同步方式是通过直接执行Future的get方法进行实现的，这里需要知道这个返回的Future对象到底是什么？

通过实现可以发现，返回的Futrue对象只是对toObservable返回结果的封装代理，把注意力转移到toObservable方法的实现。

第一次看到这个方法的实现，也许会很崩溃，方法内部初始化了一系列的Action0对象，这是RxJava的内部对象，可以看作是订阅一个事件后的回调。

一开始，不要太过在意这些Action，不然会陷入迷失，在debug的时候，通过不断的回调，经常会不知身处何处。

直接看到toObservable方法的return处，又是一坨回调，崩溃。

如果不熟悉RxJava语法，看这种代码真心的累，call方法的前面部分主要做两件事。
1、记录请求日志（日志功能开启）
2、从缓存中返回结果（定义了cacheKey方法，并且缓存功能开启）

如果缓存没有开启，或者返回null，那只能执行正常逻辑从下游服务拿取数据，这里通过上面定义的applyHystrixSemantics Action进行回调，最终执行的是applyHystrixSemantics方法，这个方法才是精华所在，想调试的同学，直接在这个方法入口打个断点，事半功倍。

其中circuitBreaker.attemptExecution()的返回结果，决定了接下去是执行正常逻辑、还是降级逻辑，这才是精华的精华。

看一下熔断器的attemptExecution方法，内部涉及了多个开关

• forceOpen
  强制开启，所以请求都执行降级逻辑
• forceClose
  强制关闭，所以请求都执行正常逻辑
• circuitOpened
  熔断开关，默认为-1，请求执行正常逻辑，如果发生熔断，该值会被修改成0，请求执行降级逻辑
• HALF_OPEN
  熔断半开，即熔断之后，每隔一段会进行试探

个人觉得，这里的实现过于复杂。

如果没有发生熔断，还有一道门槛，Hystrix提供了一个信号量限流器，限制进入熔断器最大并发数，可以控制请求下游的并发量，如果超过这个阈值，会被降级处理，有效的保护下游服务不会被突发流量给攻击。

通过的请求，继续调用executeCommandAndObserve方法，在该方法中，又定义了一堆让人迷惑的Action，不过这次通过名字和实现，可以知道个大概，先把这些Action放一边，看看接下去会执行的方法。

private Observable executeCommandAndObserve(final AbstractCommand _cmd) {
     // 忽略一堆Action的定义
    Observable execution;
    if (properties.executionTimeoutEnabled().get()) {
        execution = executeCommandWithSpecifiedIsolation(_cmd)
                .lift(new HystrixObservableTimeoutOperator(_cmd));
    } else {
        execution = executeCommandWithSpecifiedIsolation(_cmd);
    }
    return execution.doOnNext(markEmits)
        .doOnCompleted(markOnCompleted)
        .onErrorResumeNext(handleFallback)
        .doOnEach(setRequestContext);
}

Hystrix内部提供了超时检查的机制，如果参数executionTimeoutEnabled开启，则每次请求都会提交一个任务到线程池中延迟执行。由于Hystrix实现中考虑的东西太多，所以在实现上还是很复杂。

这里只给出了关键逻辑，如果配置了超时时间10ms，会提交一个延迟10ms执行的任务，其中tick方法会通过CAS机制保证超时状态的变更，最终对应command的会执行onError方法，这里加入的HystrixContextRunnable主要为了跨线程的上下文数据传递。

在执行正常逻辑的实现中，Hystrix内部提供了信号量、线程池两种模式，默认使用线程池模式。在executeCommandWithSpecifiedIsolation方法中，分别对这两种模式进行了处理，而且可以根据参数随时进行切换，这就是为什么线程池一开始就要初始化的原因，虽然有资源的消耗，但是带来了更好的灵活性，在需要的时候可以从信号量模式变成线程池模式进行隔离。

下面以信号量的方式为例，分析下如何执行用户自定义的run方法.

又想吐槽Hystrix的代码，又是这种回调，在call实现中，暂时忽略前面的一大坨逻辑，跟进getUserExecutionObservable方法。

继续查看getExecutionObservable方法，该方法在HystrixCommand中被重写实现。

run方法终于执行了。run方法执行之后，如果正常返回、抛出异常、或者其它情况，都需要对应的后续处理，这时之前executeCommandAndObserve方法中定义的Action，就开始起作用了。

execution.doOnNext(markEmits)
    .doOnCompleted(markOnCompleted)
    .onErrorResumeNext(handleFallback)
    .doOnEach(setRequestContext);

• markEmits
  run方法正常返回时执行，主要记录执行耗时；触发执行成功的通知事件，可以通过扩展插件做更多事情；如果当前是熔断状态，则关闭熔断。

• handleFallback
  run方法发生异常时执行，最终执行降级逻辑，但是整个过程实现还是很复杂的。

后续文章
Hystrix系列之自动熔断和恢复
Hystrix系列之插件实现