可以看出，我们创建了一个BookCommand 的实例，然后调用了execute方法来获取结果，这样就基本完成了，Hystrix库类已经给逻辑附上了缓存、自动降级等逻辑了，当然里面使用了大量Hystrix默认的降级策略配置（本文不是Hystrix使用的详细教程，所以这里主要突出的是用法而不强调具体的策略配置）。这里同样也说明了为什么动态调整配置是很容易的，因为每个请求都会新建Command对象（注意，Command对象是有状态的，不能重用），你只需要在创建时调整策略参数就行了，当然，这得用户自己来实现。

虽然看起来很简单，但老司机马上会发现问题：

1. 系统中每一处需要降级的逻辑都需要将其封装成一个Command类，哪怕需要降级的方法只有一行代码。如果一个系统有一百个需要降级的点，那么我们需要在系统中新增一百个Command类，有时候这让人难以接受。
2. 对老的业务系统来说，接入Hystrix将意味着巨大的工作量，因为你要把很多逻辑都封装成Command，你能接受但测试同学未必愿意。
3. 每次请求都将创建一个Command对象，因为Command对象包含了降级逻辑的大部分操作，是个重状态的对象，不能复用，如果QPS过高，将产生大量的朝生夕死的对象，对内存分配和GC将产生一定的压力。

很多用户确实也提出过抱怨，为何Hystrix的侵入性那么强？但Hystrix设计者们这么做自然有他们的道理(详见：https://github.com/Netflix/Hystrix/wiki/FAQ%20:%20General 的Why is it so intrusive?部分)，他们认为，我们需要给应用的依赖提供一个清晰的屏障，使用Command模式不仅仅是出于功能上的原因，也是作为一种标准机制，通过Command对象来向用户传递它是受保护的资源。可见，Hystrix的设计者们并不建议我们使用基于注解或AOP来作为接入Hystrix的方式，但他们仍然说：If you still feelstrongly that you shouldn't have to modify libraries and add command objectsthen perhaps you can contribute an AOP module.（直译过来就是如果你嫌麻烦不想创建这么多Command对象，有本事你自己去实现AOP啊！开个玩笑(*^__^*) ）。

### 数据采集 ###

收集数据是必不可少的一步，每个降级点（需要采取降级保护的点）的数据是独立的，所以我们可以给每个降级点配置单独的策略。这些策略一般是建立在我们对这些降级点的了解之上的，初期甚至可以先观察一下采集的数据来指定降级策略。采集哪些数据？数据如何存储？数据如何上报？这都是Hystrix需要考虑的问题，Hystrix采用的是滑动窗口+分桶的形式来采集数据（具体细节见另一篇），这样既解决了数据在统计周期间切换而带来的跳变问题（通过时间窗口），也控制了切换了力度（通过桶大小）。另一个有意思的地方是，与常规的同步统计数据的方式不同，Hystrix采用的是RxJava来进行事件流的异步统计数据，类似于观察者模式（具体细节见另一篇），这样做的好处是降低统计时阻塞业务逻辑的风险，在某些情况下还能享受多核CPU所带来的性能上的收益。

### 行为干预 ###

一旦发现采集的数据命中了降级策略，那么降级工具就将对请求进行行为干预，行为干预是评价一个降级工具好坏的重要指标，它的设计直接关系到系统的“弹性”到底有多大。但有时候行为干预和上面提到的数据采集这两个动作是同时完成的，比如使用信号量、线程池或者令牌桶算法来进行降级的时候。行为干预的设计是很有技巧的，一般来说有如下两种方案：

1. 实时采集（当前某段时间周期的）数据，对每笔请求都进行策略判断（每笔请求都会加入数据并进行分析），一旦命中策略，当即对这笔请求进行行为干预，如果没有命中，则执行正常的业务逻辑。
2. 实时采集（当前某段时间周期的）数据，对每笔请求都进行策略判断（每笔请求都会加入数据并进行分析），一旦有一笔请求命中了策略，接下来的一段时间（可配）内的所有请求都会被行为干预，哪怕接下来再也没有请求命中策略，一直到该段时间过去。

方案a似乎是比较合理的，它总是将系统的行为尽可能的控制在我们预期之内（即各项指标都在配置的策略之下），但多数情况下，我们配置策略会比较宽泛，不那么严格，那这时候采用方案a对系统来说还是有一定的风险。这时候就出现了相对更激进的方案b！一但某些请求导致统计数据触犯了降级策略，那么系统会对后续一段时间的所有请求进行降级处理，即我们熟知的降级延长。而Hystrix将两者结合起来了，让行为干预更加灵活。

### 结果干预 ###

被降级后的请求是应该返回null？还是默认值？还是抛异常？这些都要根据业务而定。Hystrix也在HystrixCommand提供了getFallback方法来方便用户返回降级后的结果。

### 快速恢复 ###

快速恢复功能在那些经常由于外部因素而导致进入降级状态的系统来说尤为重要，降级系统或工具的一个重大目标就是自动性，摆脱需要人为控制开关来保证功能熔断的“原始时代”，所以当外部条件已经恢复，系统也应该在最短的时间内恢复到正常服务状态，这就要求降级系统能够在让业务系统进入降级状态的同时，让业务系统有探测外界环境的机会。大多数降级系统都会在一段时间后“放”一笔请求进来，让它去“试一试”，如果结果是成功的，那么将让业务系统恢复到正常状态，Hystrix同样也是采用这种做法。

如果看到这里，其实大家已经对Hystrix的功能有一定的了解，这里再给一张官方的图：