前言
什么是hystrix的熔断？
hystrix熔断主要是指在一定的时间窗口内，当请求的次数达到一定的失败比率后，hystrix就会主动拒绝服务，采取将请求直接降级等方式，从而有效的缓解了服务雪崩的问题，通过快速错误的方式，有效的控制服务之间链路调用的响应时间，保证整个微服务的健康。
使用hystrix熔断功能的配置
开启hystrix熔断并配置hystrix的超时时间，需要注意ribbon的超时配置的影响，具体可以参考hystrix请求超时配置文章中的示例。
//超时时间
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=2000
//开启熔断
hystrix.command.default.execution.timeout.enabled=true
//熔断触发的最小个数，即在一定的时间窗口内请求达到一定的次数，默认20
hystrix.command.default.circuitBreaker.requestVolumeThreshold=10
//时间窗口，默认10s
hystrix.command.default.metrics.rollingStats.timeInMilliseconds=5000
//失败率达到多少百分比后熔断 默认值：50
hystrix.command.default.circuitBreaker.errorThresholdPercentage=50
//熔断多长时间后，尝试放一次请求进来，默认5秒
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=5000
以上配置表示，5秒内，如果请求次数达到10次，且50%都失败了，则开启熔断功能，并在熔断功能开启5秒后，允许一次请求（即此时熔断为半开状态），如果请求访问成功则关闭熔断，恢复正常调用，否则继续熔断5秒，以此循环。
close状态
达到条件后，断路器开启
断路器的三个状态：
- 关闭状态
关闭状态时客户端的请求是可以正常到达的。 - 开启状态
开启状态时客户端的请求是不会到达服务端，直接走降级方法。 - 半开状态
当状态为开启时，一定时间后，熔断器就会由开启状态变成半开状态。
这时候是可以接收客户端的一次请求，如果请求成功则熔断器状态变为关闭，如果请求失败则熔断器的状态变为开启状态，等待下一个时间周期继续尝试服务调用。
Hystrix 工作原理
Hystrix工作流
- 创建HystrixCommand 或者 HystrixObservableCommand 对象
- 执行命令execute()、queue()、observe()、toObservable()
- 如果请求结果缓存这个特性被启用，并且缓存命中，则缓存的回应会立即通过一个Observable对象的形式返回
- 检查熔断器状态，确定请求线路是否是开路，如果请求线路是开路，Hystrix将不会执行这个命令，而是直接执行getFallback
- 如果和当前需要执行的命令相关联的线程池和请求队列，Hystrix将不会执行这个命令，而是直接执行getFallback
- 执行HystrixCommand.run()或HystrixObservableCommand.construct()，如果这两个方法执行超时或者执行失败，则执行getFallback()
- Hystrix 会将请求成功，失败，被拒绝或超时信息报告给熔断器，熔断器维护一些用于统计数据用的计数器。这些计数器产生的统计数据使得熔断器在特定的时刻，能短路某个依赖服务的后续请求，直到恢复期结束，若恢复期结束根据统计数据熔断器判定线路仍然未恢复健康，熔断器会再次关闭线路。
- 依赖隔离Hystrix采用舱壁隔离模式隔离相互之间的依赖关系，并限制对其中任何一个的并发访问。
可能会有人有疑问，为什么不依赖于HTTP Client去做容错保护（快速失败、熔断等），而是在访问依赖之外通过线程&线程池隔离的方式做这个断路器（Hystrix）`
主要是以下几个方面：
- 不同的依赖执行的频率不同，需要分开来对待
- 不同的依赖可能需要不同的Client的工具/协议来访问，比如我们可能用HTTP Client，可能用Thrift Client。
- Client在执行的过程中也可能会出现非网络异常，这些都应该被隔离
- Client的变化会引起断路器的变化