熔断与降级
1.\ 熔断
1.1 熔断来源
我们家用电闸上都有保险丝模块，当电压出现短路问题时，自动跳闸，此刻电路主动断开，我们的电器就会收到保护。否则，不能断开，后果不堪设想。
保险丝就是一个自我保护装置，保护整个电路。
1.2 分布式系统中的熔断
在分布式系统中，我们往往需要依赖下游服务，不管是内部系统还是第三方服务，如果下游出现问题，我们还是盲目地去请求，及时失败了多次，还是傻傻的去请求，去等待。
这样，
一是增加了整个链路的请求时间
第二，下游系统本身就出现了问题，不断的请求又把系统问题加重了，恢复困难。
1.3 熔断的作用
熔断模式可以防止应用程序不断地尝试可能超时和失败的服务，能达到应用程序执行而不必等待下游服务修正错误服务。
熔断器模式最牛的是能让应用程序自我诊断下游系统的错误是否已经修正，如果没有，不放量去请求，如果请求成功了，慢慢的增加请求，再次尝试调用。
1.4 像不像代理模式？
熔断器模式像那些，容易导致错误操作的，一种代理
这种代理能够记录调用发生的错误次数，并根据次数，自我决定是否继续调用还是立刻返回错误。
比如说A服务调用B服务，B服务是下游的服务提供，或者是第三方服务，容易发生问题。这样既能防止不断的调用，是下游服务更坏，保护了下游方，还能降低自己的执行成本，快速的响应，减少延迟，增加吞吐量。
业内目前流行的熔断器很多，例如阿里出的Sentinel,以及最多人使用的Hystrix。
2.\ 降级
2.1 降级的本质
降级就是为了解决资源不足和访问量增加的矛盾
在有限的资源情况下，为了能抗住大量的请求，就需要对系统做出一些牺牲，有点“弃卒保帅”的意思。放弃一些功能，保证整个系统能平稳运行
2.2 降级牺牲的是什么？
强强一致性变成最终一致性
大多数的系统是不需要强一致性的。
强一致性就要求多种资源的占用，减少强一致性就能释放更多资源
这也是我们一般利用消息中间件来削峰填谷，变强一致性为最终一致性，也能达到效果
干掉一些次要功能
停止访问不重要的功能，从而释放出更多的资源
举例来说，比如电商网站，评论功能流量大的时候就能停掉，当然能不直接干掉就别直接，最好能简化流程或者限流最好
简化功能流程。把一些功能简化掉
2.3 降级的注意点
对业务进行仔细的梳理和分析
哪些是核心流程必须保证的，哪些是可以牺牲的
什么指标下能进行降级
吞吐量、响应时间、失败次数等达到一个阈值才进行降级处理
如何降级
降级最简单的就是在业务代码中配置一个开关或者做成配置中心模式，直接在配置中心上更改配置，推送到相应的服务。
3.\ 限流
3.1 限流的目的
通过对并发访问进行限速。
3.2 限流有哪些行为
拒绝服务
最简单的方式，把多余的请求直接拒绝掉
做的高大上一些，可以根据一定的用户规则进行拒绝策略。
服务降级
降级甚至关掉后台的某些服务。
特权请求
在多租户或者对用户进行分级时，可以考虑让一些特殊的用户有限处理，其他的可以考虑干掉
延时处理
可以利用队列把请求缓存住。削峰填谷。
3.3 限流的实现方式
计数器
最简单的实现方式 ，维护一个计数器，来一个请求计数加一，达到阈值时，直接拒绝请求。
一般实践中用 ngnix + lua + redis 这种方式，redis 存计数值
漏斗模式
流量就像进入漏斗中的水一样，而出去的水和我们系统处理的请求一样，当流量大于漏斗的流出速度，就会出现积水，水对了会溢出。
漏斗很多是用一个队列实现的，当流量过多时，队列会出现积压，队列满了，则开始拒绝请求。
令牌桶
看图例，令牌通和漏斗模式很像，主要的区别是增加了一个中间人，这个中间人按照一定的速率放入一些token，然后，处理请求时，需要先拿到token才能处理，如果桶里没有token可以获取，则不进行处理。
3.4 限流的一些注意点
限流越早设计约好，架构成型后，不容易加入
限流模块不要成为系统的瓶颈，性能要求高
最好有个开关，可以直接介入
限流发生时，能及时发出通知事件
限流发生时，给用户提供友好的提示 。
4.\ 三者的关系
熔断强调的是服务之间的调用能实现自我恢复的状态；
限流是从系统的流量入口考虑，从进入的流量上进行限制，达到保护系统的作用；
降级，是从系统内部的平级服务或者业务的维度考虑，流量大了，可以干掉一些，保护其他正常使用；
熔断是降级方式的一种；
降级又是限流的一种方式；
三者都是为了通过一定的方式去保护流量过大时，保护系统的手段。
