纸上得来终觉浅，绝知此事要躬行。
hystrix([hɪst'rɪks])是豪猪的意思（刺猬？）。豪猪是一种哺乳动物，全身是刺用以更好的保护自己。netflix使用这来命名这框架实在是非常的贴切，意味着hystrix能够像豪猪的刺一样保护着你的应用。下面是一张豪猪的高清无码大图。
Hystrix 解决的问题
在微服务时代，微服务之间相互依赖相互调用。我们可以通过各种技术优化来保证我们自己的服务代码可靠可控，但是对于我们依赖的其他微服务提供的外部接口，我们是不可控的，不能保证其调用总是可靠的。
对于在我们代码中调用的其他服务提供的外部接口，或者说第三方服务接口，比如我们的系统接入了OA系统，我们创建OA，查询OA审批信息和状态，都是需要调用OA对外提供的相关接口来实现的。但是我们不能保证这些外部接口的可靠性，对于网络调用来说，总是会存在网络不通故障，网络延迟超时等问题。特别是微服务众多，依赖复杂的情况下，这些单点故障可能会蔓延到整个微服务系统上游，导致整个系统不可用。
所以，Hystrix的出现就是为了解决这样的外部系统接口调用问题，因为这些问题是固定的，是在微服务系统中普遍存在的问题，所以针对这类问题设计并实现了Hystrix这套框架来解决这类问题，我们只需要引入框架，继承并实现相关类和接口方法即可解决相关问题，保护我们的系统在调用外部接口时的可靠性可用性。
问题实例
比如我们的服务依赖OA外部接口，在调用查询OA审批信息的接口时，OA接口服务实现存在问题，特定情况下调用会产生死循环。如果此时突然来了大量请求查询OA审批信息的请求，因为每个请求都会长期阻塞（直到超时），连接得不到释放，所以很快会将线程池中的线程耗尽，导致系统整体不可用。比如此时来了一个查询用户信息的请求，我们的服务也是依赖外部接口来查询用户信息，但是因为现在没有线程资源可以使用，所以这个请求也是无法完成的。
Hystrix提供了资源隔离来解决这个问题。我们可以使用Hystrix提供的功能，将OA外部接口的调用封装在Hystrix里，可以设置一个OA外部接口专用的线程池，这样我们系统中所有调用OA相关接口的请求都会在一个单独的线程池里，同理，查询用户信息的外部接口封装隔离在Htstrix提供的另一个独立的线程池里。这样，即使OA接口不可用，也不会影响其他外部接口，也阻断了故障向上游系统蔓延。同时，隔离池也需要设置timeout来避免隔离池长期全部卡死。
同时，资源隔离因为提供了单独的线程池，而且线程池线程数量可控（资源隔离另一种方式是使用信号量），所以也达到了接口限流的目的。单位时间内只允许一定数量的请求进行处理，超过目标值的请求会被拒绝或者执行降级。
如果我们依赖的OA服务挂短时间内发生了大量异常，比如报错、隔离池已满拒绝、超时等，Hystrix会接收并统计这些信息，达到一定条件就会触发熔断降级。这是对依赖服务接口异常的一种容错保护。接口熔断之后，对接口的调用将会在一定的时间内不可用，即不会真正调用外部接口，可以转而调用fellBack降级逻辑，也可以快速直接失败。而fellback逻辑可言提供一些默认的信息或者查询缓存信息，作为临时可以用的数据返回。这样，接口降级后，便不再进行缓慢无效的网络请求，直接高效的返回默认数据。经过一段时间的容错保护后，Hystrix将会放行一部分请求去真正调用接口，以试探接口服务是否恢复正常，如果恢复正常，则关闭熔断。
接口降级还有一种应用，就是针对短时间内的系统高并发，可以采取丢车保帅的策略，将一些不重要的业务接口临时采用降级逻辑处理，不再进行实际耗时的复杂操作，直接返回默认数据，让出宝贵的系统资源，以供那些重要的业务接口使用。比如商品大促时段，可以采取临时降级历史查询，用户信息查询修改等业务接口，全力保障下单接口的正常使用。
Hystrix的使用
使用Hstrix的话，可以使外部接口的调用实现继承Hystrix提供的相关父类，然后重写相关接口即可。当然，也可以选择使用声明式的服务，使用注解来完成相关接口。
以上就是自己学习Hystrix的一些理解和总结。如下，贴一篇写的不错的博客，既有原理又有使用的介绍。
使用hystrix保护你的应用
