如果你的命令是继承自HystrixCommand，那么可以通过实现HystrixCommand.getFallback()方法返回一个单个的fallback值。

如果你的命令是继承自HystrixObservableCommand，那么可以通过实现HystrixObservableCommand.resumeWithFallback()方法返回一个Observable，并且该Observable能够发射出一个fallback值。

Hystrix会把fallback方法返回的响应返回给调用者。

如果你没有为你的命令实现fallback方法，那么当命令抛出异常时，Hystrix仍然会返回一个Observable，但是该Observable并不会发射任何的数据，并且会立即终止并调用onError()通知。通过这个onError通知，可以将造成该命令抛出异常的原因返回给调用者。

失败或不存在回退的结果将根据您如何调用Hystrix命令而有所不同：

?execute()：抛出一个异常。

?queue()：成功返回一个Future，但是如果调用get()方法，将会抛出一个异常。

?observe()：返回一个Observable，当你订阅它时，它将立即终止，并调用onError()方法。

?toObservable()：返回一个Observable，当你订阅它时，它将立即终止，并调用onError()方法。

9.返回成功的响应

?如果Hystrix命令执行成功，它将以Observable形式返回响应给调用者。根据你在第2步的调用方式不同，在返回Observablez之前可能会做一些转换。

?execute()：通过调用queue()来得到一个Future对象，然后调用get()方法来获取Future中包含的值。

?queue()：将Observable转换成BlockingObservable，在将BlockingObservable转换成一个Future。

?observe()：订阅返回的Observable，并且立即开始执行命令的逻辑，

?toObservable()：返回一个没有改变的Observable，你必须订阅它，它才能够开始执行命令的逻辑。

四：断路器

下图显示了HystrixCommand或HystrixObservableCommand如何与HystrixCircuitBreaker及其逻辑和决策流程进行交互，包括计数器在断路器中的行为方式。

回路器打开和关闭有如下几种情况：

?假设回路中的请求满足了一定的阈值（HystrixCommandProperties.circuitBreakerRequestVolumeThreshold()）

?假设错误发生的百分比超过了设定的错误发生的阈值HystrixCommandProperties.circuitBreakerErrorThresholdPercentage()

?回路器状态由CLOSE变换成OPEN

?如果回路器打开，所有的请求都会被回路器所熔断。

?一定时间之后HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()，下一个的请求会被通过（处于半打开状态），如果该请求执行失败，回路器会在睡眠窗口期间返回OPEN，如果请求成功，回路器会被置为关闭状态，重新开启1步骤的逻辑。

Hystrix的熔断器实现在HystrixCircuitBreaker类中，比较重要的几个参数如下：

1、circuitBreaker.enabled

熔断器是否启用，默认是true

2、circuitBreaker.forceOpen

熔断器强制打开，始终保持打开状态，默认是false

3、circuitBreaker.forceClosed

熔断器强制关闭，始终保持关闭状态，默认是false

4、circuitBreaker.requestVolumeThreshold

滑动窗口内（10s）的请求数阈值，只有达到了这个阈值，才有可能熔断。默认是20，如果这个时间段只有19个请求，就算全部失败了，也不会自动熔断。

5、circuitBreaker.errorThresholdPercentage

错误率阈值，默认50%，比如（10s）内有100个请求，其中有60个发生异常，那么这段时间的错误率是60，已经超过了错误率阈值，熔断器会自动打开。

6、circuitBreaker.sleepWindowInMilliseconds

熔断器打开之后，为了能够自动恢复，每隔默认5000ms放一个请求过去，试探所依赖的服务是否恢复。

?在最新代码中，已经弃用了allowRequest()，取而代之的是attemptExecution()方法。

和allowRequest()方法相比，唯一改进的地方是通过compareAndSet修改状态值。通过attemptExecution()方法的返回值决定执行正常逻辑，还是降级逻辑。

1、如果circuitBreaker.forceOpen=true，说明熔断器已经强制开启，所有请求都会被熔断。

2、如果circuitBreaker.forceClosed =true，说明熔断器已经强制关闭，所有请求都会被放行。

3、circuitOpened默认-1，用以保存最近一次发生熔断的时间戳。

4、如果circuitOpened不等于-1，说明已经发生熔断，通过isAfterSleepWindow()判断当前是否需要进行试探。

这里就是熔断器自动恢复的逻辑，如果当前时间已经超过上次熔断的时间戳 + 试探窗口5000ms，则进入if分支，通过compareAndSet修改变量status，竞争试探的能力。其中status代表当前熔断器的状态，包含CLOSED, OPEN, HALF_OPEN，只有试探窗口之后的第一个请求可以执行正常逻辑，且修改当前状态为HALF_OPEN，进入半熔断状态，其它请求执行compareAndSet(Status.OPEN, Status.HALF_OPEN)时都返回false，执行降级逻辑。

5、如果试探请求发生异常，则执行markNonSuccess()

通过compareAndSet修改status为熔断开启状态，并更新当前熔断开启的时间戳。

6、如果试探请求返回成功，则执行markSuccess()

通过compareAndSet修改status为熔断关闭状态，并重置接口统计数据和circuitOpened标识为-1，后续请求开始执行正常逻辑。

说了这么多，如何实现自动熔断还没提到，在Hystrix内部有一个Metric模块，专门统计每个Command的执行状态，包括成功、失败、超时、线程池拒绝等，在熔断器的中subscribeToStream()方法中，通过订阅数据流变化，实现函数回调，当有新的请求时，数据流发生变化，触发回调函数onNext