Sentinel的熔断降级实现有两个模式，一开始是基于熔断规则的简单处理(说简单其实不简单)，目前已改为了基于断路器模式实现，这也是业内常见实现。
断路器模式中讨论了 3 个主要状态。他们是：
CLOSED
OPEN
HALF OPEN
让我们简要了解一下状态……
CLOSED State
当正在交互的两个服务都启动并运行时，断路器默认关闭。断路器会持续统计远程 API 调用的次数。
OPEN State
一旦远程 API 调用失败百分比超过给定阈值，断路器就会将其状态更改为 OPEN 状态。调用微服务会立即失败，返回异常。也就是说，流量中断了。
HALF OPEN State
在 OPEN 状态停留给定的超时时间后，断路器自动将其状态变为 HALF OPEN 状态。在这种状态下，只允许有限数量的远程 API 调用通过。如果失败调用计数大于此有限数量，则断路器再次变为 OPEN 状态，流量继续中断。否则关闭断路器，流量恢复正常。
流程图可描述如下：
最经典的实现就是Hytrix，而且它的实现是基于响应式编程来做的；其次Spring官方出品的Resilience4j、Sentinel也是基于此方式实现。
我个人对Sentinel比较推崇，功能强大，源码易读，而且设计架构简介。Sentinel框架中有三个关键的对象是一直贯彻整个框架的，也是最关键的三个个点：ProcessorSlot、Rule(规则)与指标数据统计(Bucket)。
这里不多讲，实现了责任链模式，基于SPI机制支持可扩展性，这个设计很好，值得借鉴。其实也类似MVC框架的管道模式。DegradeSlot插槽实现断路器模式，最终达到限流降级的目的。
对于熔断降级或是限流等场景，最后的实现结果一定是由于当前的流量或是异常等维度指标超出了限定值，这个过程就是规则(Rule)的体现，而规则背后的开关实现就是指标数据的统计。这是我个人的理解，大白话表述。
指标数据统计在Sentinel中对应着三个抽象；暂时先不表述。如果要我来实现的话，我的思考是，有一个数据结构存储着在某个时间段内，统计了某些维度的数据(比如成功、异常、总计)，而且这个数据结构是随着时间的推移不断地统计；现在给定一个时间点或是时间段，判断是否需要限流或是熔断；在这里就需要注意两个问题点：
Sentinel是基于滑动窗口实现资源的实时指标数据统计的。
Sentinel使用Bucket统计一段时间内的各项指标数据，这些指标数据包括请求总数、成功总数、异常总数、总耗时、最小耗时等。一个Bucket可以记录1秒内的数据，也可以记录10毫秒内的数据，这由采样周期决定。采样周期就是每个Bucket的时间窗口大小。
WindowWrap，用于记录Bucket的时间窗口信息（包括时间窗口的开始时间戳和大小），而WindowWrap数组就是一个滑动窗口。当收到一个请求时，可以根据收到请求时的时间戳和滑动窗口大小计算出一个索引值，从滑动窗口（WindowWrap数组）中获取一个WindowWrap类，从而获取WindowWrap类包装的Bucket，并调用Bucket实例的add方法统计指标。
LeapArray，Sentinel 中统计指标的基本数据结构。基于滑动窗口算法来计算数据返回windowWrap时间窗口对象。前面说的两个问题在这个数据结构里面都有对应的算法实现，当然还有别的统计算法，但最后都是算时间窗口。
脑图概览
