##Hystrix原理讲解
执行流程讲解：
- 通过配置或注解的方式构建Hystrix的Command对象，调用执行方法
- Hystrix会检查当前服务的熔断器是否开启，若开启，则执行降级逻辑Fallback方法。
- 若熔断器开关关闭，则Hystrix检查当前熔断器的线程池是否能接收新的请求，若线程池已满则拒绝请求，执行降级熔断逻辑，并上报Metrices。（注：不同熔断器可以共用一个线程池，线程池名称不同的话是相互隔离的，commandKey区分熔断器，threadPoolKey区分线程池）
- 若线程池接收请求，则Hystrix调用服务逻辑的run方法。
- 若服务执行失败则执行降级逻辑，并上传Metrices。
- 若服务执行超时则执行降级逻辑，并上传Metrices。
- 若执行成功则直接返回结果。
滑动时间窗口讲解
滑动时间窗口策略：不断收集数据，达到条件就熔断；熔断后拒绝所有请求一段时间
(sleepWindow)；然后放一个请求过去，如果请求成功，则关闭熔断器，否则继续打开熔断器。
滑动事件窗口配置。
metrics相关配置：
- metrics.rollingStats.timeInMilliseconds
表示滑动窗口的时间(the duration of the statistical rolling window)，默认10000(10s)，也是熔断器计算的基本单位。 - metrics.rollingStats.numBuckets
滑动窗口的Bucket数量(the number of buckets the rolling statistical window is divided into)，默认10. （注：每个Bucket中包含了请求的总数，失败数，超时数，拒绝数。滑动时间窗口内所有的Bucket的总的失败请求/总请求=失败率） - timeInMilliseconds和numBuckets可以计算出每个Bucket的时长。
metrics.rollingStats.timeInMilliseconds % metrics.rollingStats.numBuckets 必须等于 0，否则将抛异常。
熔断器的相关配置。 - circuitBreaker.requestVolumeThreshold
滑动窗口触发熔断的最小请求数。如果值是20，但滑动窗口的时间内请求数只有19，那即使19个请求全部失败，也不会熔断，必须达到这个值才行，否则样本太少，没有意义。 - circuitBreaker.sleepWindowInMilliseconds
这个和熔断器自动恢复有关，为了检测后端服务是否恢复，可以放一个请求过去试探一下。sleepWindow指的发生熔断后，必须隔sleepWindow这么长的时间，才能放请求过去试探下服务是否恢复。默认是5s - circuitBreaker.errorThresholdPercentage
错误率阈值，表示达到熔断的条件。比如默认的50%，当一个滑动窗口内，失败率达到50%时就会触发熔断。
讲解：
所有的请求不论请求失败成功都会上传至metrics，metrics就是用来记录请求状态的数据中心。是否开启熔断都是通过metrics中统计的请求失败率来计算的，就是滑动窗口时间内请求的失败率。如滑动事件窗口为10秒，熔断器熔断阈值为50%，这10秒内来了100个请求，失败了30个，没有达到条件，若失败了60则失败率为60%会打开熔断器。但如果设置最小请求数为20，即使总请求数为19并且全失败也不会触发熔断，这是为了保护因网络连接导致的请求失败问题。
服务有可能因各种原因失败，所以会有重新可用的可能性，Hystrix都在sleepWindowInMilliseconds时间后放过一个请求，若请求成功则关闭熔断器，若失败则继续过一段时间放过请求。