# 熔断器说明
# 使用场景
并非每个业务服务都需要使用熔断器
在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以通过 RPC 相互调用。 为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保 证 100% 可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的 请求涌入，Servlet 容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性， 故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 “雪崩” 效应。
为了解决这个问题，业界提出了熔断器模型。
Netflix 开源了 Hystrix 组件，实现了熔断器模式，Spring Cloud 对这一组件进行了整合。 在微服务架构中，一个请求需要调用多个服务是非常常见的，如下图：
较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值(Hystrix 是 5 秒 20 次) 熔断器将会被打开。
熔断器打开后，为了避免连锁故障，通过 fallback 方法可以直接返回一个固定值。
# 什么情况下会触发 fallback 方法
| 名字 | 描述 | 触发 fallback |
|---|---|---|
| EMIT | 值传递 | NO |
| SUCCESS | 执行完成 | ，没有错误 NO |
| FAILURE | 执行抛出异常 | YES |
| TIMEOUT | 执行开始 | ，但没有在允许的时间内完成 YES |
| BAD_REQUEST | 执行抛出 | HystrixBadRequestException NO |
| SHORT_CIRCUITED | 断路器打开 | ，不尝试执行 YES |
| THREAD_POOL_REJECTED | 线程池拒绝 | ，不尝试执行 YES |
| SEMAPHORE_REJECTED | 信号量拒绝 | ，不尝试执行 YES |
# fallback 方法在什么情况下会抛出异常
| 名字 | 描述 | 抛异常 |
|---|---|---|
| FALLBACK_EMIT | Fallback 值传递 | NO |
| FALLBACK_SUCCESS | Fallback 执行完成，没有错误 | NO |
| FALLBACK_FAILURE | Fallback 执行抛出出错 | YES |
| FALLBACK_REJECTED | Fallback 信号量拒绝，不尝试执行 | YES |
| FALLBACK_MISSING | 没有 Fallback 实例 | YES |
# Hystrix Dashboard 界面监控参数
# 其它说明
由于 Hystrix 是一个容错框架，因此我们在使用的时候，要达到熔断的目的只需配置一些参数就可以了。但我们要达到真正的效果，就必须要了解这些参数。Circuit Breaker 一共包括如下 6 个参数。
circuitBreaker.enabled 是否启用熔断器，默认是 TURE。
circuitBreaker.forceOpen 熔断器强制打开，始终保持打开状态。默认值 FLASE。
circuitBreaker.forceClosed 熔断器强制关闭，始终保持关闭状态。默认值 FLASE。
circuitBreaker.errorThresholdPercentage 设定错误百分比，默认值 50%，例如一段时间（10s）内有 100 个请求，其中有 55 个超时或者异常返回了，那么这段时间内的错误百分比是 55%，大于了默认值 50%，这种情况下触发熔断器-打开。
circuitBreaker.requestVolumeThreshold 默认值 20.意思是至少有 20 个请求才进行 errorThresholdPercentage 错误百分比计算。比如一段时间（10s）内有 19 个请求全部失败了。错误百分比是 100%，但熔断器不会打开，因为 requestVolumeThreshold 的值是 20.