去年在看spring cloud系列的时候，当时就已经了解到了hystrix，这个组件和eureka，zuul等组件一样都是netflix公司开源的。当时由于没有太多的精力，只简单了解了下hystrix的一些简单功能。这半年因为工作关系一直接触redis相关的东西，redis相关也看过不少书了，有时候一直搞一件事可能觉得有点枯燥。就偶然又产生了想法，就决定重新看一下hystrix，决定搞一个hystrix系列。在阅读hystrix的代码过程中，刚开始看起来很吃力，里面用到了rxjava(采用函数响应式编程模式写的，感觉看起来很费劲)，发现要学习的东西越来越多。就想从最简单的hystrix介绍到使用最后到源码分析，写一个系列的博客，正好也长时间没有研究一些新的框架了。上面废话了很多，下面进入正题，本文主要从以下几方面简要介绍下hystrix，基本都是一些概念性的(基本都是翻译自github上Hystrix主页)。
- Hystrix是什么
- Hystrix用来做什么
- Hystrix解决了什么问题
- Hystrix设计模式
- Hystrix如何实现它的设计目标
Hystrix是什么
在一个分布式的系统当中，不可避免的会出现一些对于外部service的依赖调用报错。Hystrix可以添加一些对于延时的容忍和容错性来帮助你控制与这些外部service的交互，Hystrix是通过隔离这些单个的服务(比如把这些外部服务放在单独的线程池里面执行)来避免瀑布式的报错，并且提供了降级fallback方法，以上这些都可以提供系统的可用性。
Hystrix用来做什么
- 对于调用外部服务提供容错和超时保护机制
- 避免在一个分布式系统中瀑布式报错
- fail fast和及时恢复
- fallback和优雅降级
- 近乎实时的监控，报警和运维
Hystrix解决了什么问题
在一个复杂的分布式系统当中，肯定会存在一系列的外部服务，其中每个服务都可能会在某个时刻发生错误。如果我们的应用不能与这些发生错误的服务隔离，那么我们的应用就有可能被他们拖垮。
所有外部服务都运行正常的情况下，我们服务是这样的:
当其中一个外部服务不可用(或者开始出现延时)，就会开始阻塞用户请求
当一个服务开始延时就会慢慢开始影响上游的一系列相关的服务，导致上游也出现延时。并且更糟糕的是，相关联的上游服务如果有一些重试机制就会耗尽线程池，io和一些其他的系统资源，就会在整个系统之间导致瀑布式的错误
Hystrix采用以下设计原则
- 避免单个的外部依赖耗尽应用资源(例如tomcat)线程
- 通过fail fast机制代替队列来降低负载
- 在适当时候提供fallback机制
- 通过一些隔离的技术手段(例如bulkhead, swimlane, and circuit breaker patterns)来降低单个外部服务故障造成的影响
- 通过近乎实时的监控，报警和运维来更好更实时发现错误
- 通过动态的调整一些配置来修改系统运行的参数实时处理系统异常
- 提供完整的客户端调用保护机制，并不仅仅是网络调用方面。
Hystrix如何实现它的设计目标
- 把对外部系统的一些调用包装成HystrixCommand或者HystrixObservableCommand命令在一个单独的线程池里面执行(command pattern)
- 可以自己设置超时相关的参数，默认情况超过你设置的最大值就超时，还可以通过设置一些属性，比如设置99.5那么比99.5%的请求慢的就是超时
- 对每一个外部调用都创建一个单独的线程池，如果线程池满了，那么就直接拒绝fail fast
- 测量所有的成功，失败，超时，thread rejections请求
- 如果某个服务的错误百分比超过设置的阈值，则通过手动或自动地中断一个断路器停止某一特定服务的所有请求一段时间。
- 当调用失败，超时，reject或者short-circuits时候提供fallback机制
- 监控指标和配置变更实时生效
当在一个分布式系统中使用了Hystrix后，所有对于外部的依赖调用都被隔离在一个单独的线程池，单独的服务故障不会影响其他服务。并通过提供fallback机制应对某个服务出现异常情况。
