上文《Hystrix系列之入门》介绍了Hystrix的由来，本文会深入分析Hystrix的执行过程。
Hystrix的大部分逻辑基于RxJava进行实现，让很热多人望而却步，停留在了仅仅使用的地步，今天从一个简单的HelloWorld开始。
public
class
CommandHelloWorld
extends
HystrixCommand
<
String
{
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
<
R
executeCommandAndObserve
(
final
AbstractCommand
<
R
_cmd
)
{
// 忽略一堆Action的定义
Observable
<
R
execution
;
if
(
properties
.
executionTimeoutEnabled
().
get
())
{
execution
=
executeCommandWithSpecifiedIsolation
(
_cmd
)
.
lift
(
new
HystrixObservableTimeoutOperator
<
R
(
_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方法发生异常时执行，最终执行降级逻辑，但是整个过程实现还是很复杂的。
748
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
