故障容错
熔断降级
故障熔断，指的是当下游因过载或者BUG等原因，出现请求错误后，为了防止故障级联扩散导致整个链路出现异常，从而对请求进行拒绝或者重试的一种机制。
熔断模型
熔断模型的设计遵循业界标准的熔断器模型设计。熔断器有3类状态：
- 关闭：所有请求皆可访问下游资源，无任何限制。
- 打开：限制访问下游资源的请求，不允许任何请求的访问。
- 半开：限制访问下游资源的请求，只允许部分请求达到下游。
熔断场景
熔断一般会发生在以下场景下：
硬件环境出现故障
服务在运营过程中，因为一些不可抗力的因素，可能会出现机器故障、机器重启、机房断电、网络中断等问题。通过熔断机制，对服务实例或者机房分组的快速熔断，可以避免业务请求持续失败。
版本上线引入BUG
版本新特性开发上线后，因为漏测等原因，某些分支触发了BUG，导致部分的业务逻辑出现故障。常见的是部分方法在遇到某些入参的时候，会出现进程报错或者高负载的问题，影响其他方法的请求处理。通过熔断机制，将故障方法进行隔离，可以避免其他业务请求受到影响。
服务出现过载
因为路由不均或者峰值流量的到来，导致被调服务出现了高负载，导致请求的时延增大，成功率降低。通过熔断机制，合理的拒绝一部分请求，可以降低服务负载，恢复正常的运行状态。
熔断级别
服务级熔断
按照服务粒度进行熔断统计，服务一般对应的是注册中心上注册的服务，实际对应到业务可以是应用或者模块。一旦服务被熔断后，访问该服务的请求都会返回失败走降级逻辑
方法级熔断
按照服务下提供的方法进行熔断统计，方法被熔断后会对请求进行拒绝或者走降级逻辑。
分组级熔断
按照服务实例分组进行熔断统计，实例分组被熔断后，请求往往会重路由到其他实例分组。
实例级熔断
按照具体的服务实例进行熔断统计，实例被熔断后，请求往往会重路由到其他实例。
组合粒度
按照组合的粒度进行熔断统计，常见的组合是方法+实例的组合，对应的场景是，一个实例提供了多个方法，其中一个方法在新版本上线时候出现了BUG，需要对该实例下对应的方法进行熔断，其他方法没有改动，可以正常提供服务。
触发熔断条件
连续错误数熔断
请求调用时，统计周期内，出现连续异常数目超过阈值之后，资源进入熔断状态。
错误率熔断
熔断器按照滑窗对请求总数及成功数进行统计，并汇总时间段内的总错误率，一旦超过阈值，资源进入熔断状态。
错误数熔断
熔断器按照滑窗对请求总数及成功数进行统计，并汇总时间段内的总错误数，一旦超过阈值，资源进入熔断状态。
慢调用率熔断
熔断器按照滑窗对请求总数及慢调用数进行统计，并汇总时间段内的总慢请求率，一旦超过阈值，资源进入熔断状态。
熔断策略
快速失败熔断
一旦触发熔断，则接下来的熔断周期内对资源的访问会自动地被拒绝或重路由。
适用于硬件环境出现故障，以及版本上线出现BUG的快速熔断场景。
代表的算法有Hystrix。
每个请求进入后，会判断熔断器状态，存在3种分支：
- 熔断器打开后，请求直接返回，走降级逻辑。
- 熔断器半开后，则只需要一定量的请求访问下游，其他请求返回。
- 熔断器关闭后，所有请求都可以访问下游。
在请求调用后，通过框架采集请求的调用结果，汇聚熔断器。
熔断器会通过滑窗的方式，统计每个请求的成功数及总请求数，根据成功失败率进行状态转换：
- 熔断器从关闭到打开：一旦请求达到阈值，则熔断器打开。
- 熔断器从打开到半开：熔断器打开经过一段时间，或者通过了故障探测，则进入半开状态。
- 熔断器从半开到打开：熔断器半开后，走递增放量的方式，放量期间出现了失败，则熔断器重新打开。
- 熔断器从半开到关闭：熔断器半开后，走递增放量的方式，放量期间没有失败，最终放量100%后，熔断器关闭。