Hystrix是如何处理请求，在官网有详细介绍：https://github.com/Netflix/Hystrix/wiki/How-it-Works， 本文重点围绕下方流程图介绍一下主要的流程；
Hystrix是将我们的系统间调用包装成一个个Comman来执行，举个简单的例子：
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;
}
}
// execute
TestCommand testCommand = new TestCommand(new TestServiceA(), i);
testCommand.execute();
我们只需要用一个Command来包装我们的RPC/RMI调用，上面就使用 TestCommand 包装了一个TestService 方法；
下面解释流程图中具体逻辑；
1、包装请求：
可以使用继承HystrixCommand或HystrixObservableCommand来包装业务方法；
2、发起请求：
使用调用Command的execute来执行一个业务方法调用；
Hystrix除了提供了execute方法，另外还提供了3种方来，所有的请求入口：
K value = command.execute(); Future<K> fValue = command.queue(); Observable<K> ohValue = command.observe(); //hot observable Observable<K> ocValue = command.toObservable(); //cold observable
如上图所示：
执行同步调用execute方法，会调用queue().get()方法，queue()又会调用toObservable().toBlocking().toFuture()；
所以，所有的方法调用都依赖Observable的方法调用，只是取决于是需要同步还是异步调用；
3、缓存处理：
当请求来到后，会判断请求是否启用了缓存（默认是启用的），再判断当前请求是否携带了缓存Key；
如果命中缓存就直接返回；否则进入剩下的逻辑；
4、判断断路器是否打开（熔断）：
断路器是Hystrix的设计核心，断路器是实现快速失败的重要手段（断路器打开就直接返回失败）；
可以设置断路器打开一定时间后，可以进行尝试进行业务请求（默认是5000毫秒）；
5、判断是否进行业务请求（请求是否需要隔离或降级）：
是否进行业务请求之前还会根据当前服务处理质量，判断是否需要去请求业务服务；
如果当前服务质量较低（线程池/队列/信号量已满），那么也会直接失败；
线程池或信号量的选择（默认是线程池）：
线程池主要优势是客户端隔离和超时设置，但是如果是海量低延迟请求时，频繁的线程切换带来的损耗也是很可观的，这种情况我们就可以使用信号量的策略；
信号量的主要缺点就是不能处理超时，请求发送到客户端后，如果被客户端pending住，那么就需要一直等待；
6、执行业务请求：
当前服务质量较好，那么就会提交请求到业务服务器去；
HystrixObservableCommand.construct() or HystrixCommand.run()
7、健康监测：
根据历史的业务方法执行结果，来统计当前的服务健康指标，为断路器是否熔断等动作作为依据；
8/9、响应失败或成功的处理结果