所谓限流，本质就是对系统的被请求频率以及内部的部分功能的执行频率加以限制，防止因突发的流量激增，导致整个系统不可用。当流量出现激增，触发限流，那么对于那些系统暂时不想或无法处理的“流量”，我们该如何处理呢？这就自然引出了服务降级的概念，其本质就是提供降低系统正常运行所能提供的功能数，亦或是降低某些功能完成的完整度（质量）。而熔断就是众多降级手段中最常见的一种，其在流量过大时（或下游服务出现问题时），可以自动断开与下游服务的交互，并可以通过自我诊断下游系统的错误是否已经修正，或上游流量是否减少至正常水平，来恢复自我恢复。
简而言之，限流是从系统的流量入口考虑，从进入的流量上进行限制，达到保护系统的作用；降级，是从系统内部的平级服务或者业务的维度考虑，流量大了，可以干掉一些，保护其他正常使用；熔断强调的是服务之间的调用能实现自我恢复的状态；
Hystrix的golang版本项目地址是： https://github.com/afex/hystrix-go
Hystrix是Netflix开源的一个限流熔断的项目、主要有以下功能:
项目地址为： https://github.com/sony/gobreaker
gobreaker是索尼的开源的一个限流熔断的项目，是基于《微软云设计模式》一书中的熔断器模式的 Golang 实现的，本质利用的还是原子计数法、主要有以下功能:
微服务集群中，每个应用基本都会依赖一定数量的外部服务。有可能随时都会遇到网络连接缓慢，超时，依赖服务过载，服务不可用的情况,在高并发场景下如果此时调用方不做任何处理，继续持续请求故障服务的话很容易引起整个微服务集群雪崩。比如高并发场景的用户订单服务，一般需要依赖一下服务：
假如此时 账户服务 过载，订单服务持续请求账户服务只能被动的等待账户服务报错或者请求超时，进而导致订单请求被大量堆积，这些无效请求依然会占用系统资源：cpu，内存，数据连接...导致订单服务整体不可用。即使账户服务恢复了订单服务也无法自我恢复。
这时如果有一个主动保护机制应对这种场景的话订单服务至少可以保证自身的运行状态,等待账户服务恢复时订单服务也同步自我恢复，这种自我保护机制在服务治理中叫熔断机制。
熔断是调用方自我保护的机制（客观上也能保护被调用方），熔断对象是外部服务。
降级是被调用方（服务提供者）的防止因自身资源不足导致过载的自我保护机制，降级对象是自身。
熔断这一词来源时我们日常生活电路里面的熔断器，当负载过高时（电流过大）保险丝会自行熔断防止电路被烧坏，很多技术都是来自生活场景的提炼。
熔断器一般具有三个状态：
使用较多的熔断组件：
基于上面提到的熔断器原理，项目中我们要使用好熔断器通常需要准备以下参数：
实际上可选的配置参数还有非常非常多，参考 https://resilience4j.readme.io/docs/circuitbreaker
对于经验不够丰富的开发人员而言，这些参数设置多少合适心里其实并没有底。
那么有没有一种自适应的熔断算法能让我们不关注参数，只要简单配置就能满足大部分场景？
其实是有的， google sre 提供了一种自适应熔断算法来计算丢弃请求的概率：
算法参数：
算法解释：
接下来思考一个熔断器如何实现。
初步思路是：
下面来逐步分析 go-zero 的源码实现：
core/breaker/breaker.go
兵马未动，粮草先行，明确了需求后就可以开始规划定义接口了，接口是我们编码思维抽象的第一步也是最重要的一步。
核心定义包含两种类型的方法：
Allow()：需要手动回调请求结果至熔断器，相当于手动挡。
DoXXX()：自动回调请求结果至熔断器，相当于自动挡，实际上 DoXXX() 类型方法最后都是调用
DoWithFallbackAcceptable(req func() error, fallback func(err error) error, acceptable Acceptable) error
circuitBreaker 继承 throttle，实际上这里相当于静态代理，代理模式可以在不改变原有对象的基础上增强功能，后面我们会看到 go-zero 这样做的原因是为了收集熔断器错误数据，也就是为了实现可观测性。
熔断器实现采用静态代理模式，看起来稍微有点绕脑。
throttle 接口实现类：
loggedThrottle 增加了为了收集错误日志的滚动窗口，目的是为了收集当请求失败时的错误日志。
errorWindow 是一个环形数组，新数据不断滚动覆盖最旧的数据，通过取余实现。
看到这里我们还没看到实际的熔断器实现，实际上真正的熔断操作被代理给了 internalThrottle 对象。
可以看到熔断器属性其实非常简单，数据统计采用的是滑动时间窗口来实现。
滑动窗口属于比较通用的数据结构，常用于最近一段时间内的行为数据统计。
它的实现非常有意思，尤其是如何模拟窗口滑动过程。
先来看滑动窗口的结构体定义：
window 是数据的实际存储位置，其实就是一个数组，提供向指定 offset 添加数据与清除操作。
数组里面按照 internal 时间间隔分隔成多个 bucket。
window 添加数据：
window 统计数据：
熔断器对外暴露两种类型的方法
func (b *googleBreaker) allow() (internalPromise, error)
func (b *googleBreaker) doReq(req func() error, fallback func(err error) error, acceptable Acceptable) error
Acceptable 参数目的是自定义判断请求是否成功。
微软 azure 关于熔断器设计模式
索尼参考微软的文档开源的熔断器实现
go-zero 自适应熔断器文档
