限流、熔断与降级是流量过大时，通过一定的方式去保护系统的手段，是应对海量流量的三大“杀器”。

限流

限流是从系统的流量入口考虑，从进入的流量上进行限制，通过对并发访问进行限速，达到保护系统的作用。限制并发请求的访问量，超过阈值则拒绝。

限流的行为

• 拒绝服务：最简单的方式，把多余的请求直接拒绝
• 服务降级：降级甚至关掉后台的某些服务。
• 延时处理：利用队列处理

主流的限流算法

• 计数器
• 令牌桶
• 漏桶

使用限流需要注意的事项

• 限流越早设计越好，越往后越不容易加入
• 限流模块不要成为系统的瓶颈，性能要求高
• 最好能手动或自动的控制
• 限流发生时能及时发出通知事件
• 限流发生时提供友好的提示

降级

服务降级一般是指在服务器压力剧增的时候为了解决资源不足和访问量增加的矛盾，在有限的资源情况下，根据实际业务使用情况以及流量，对一些服务和页面有策略的不处理或者用一种简单的方式进行处理，为了能抗住大量的请求，就需要对系统做出一些牺牲，有点“弃卒保帅”的意思。放弃一些功能，保证整个系统能平稳运行。

服务降级是对系统整体资源的合理分配。区分核心服务和非核心服务。对某个服务的访问延迟时间、异常等情况做出预估并给出兜底方法。这是一种全局性的考量，服务分优先级，牺牲非核心服务（不可用），保证核心服务稳定，对系统整体负荷进行管理。

场景

多用于微服务架构中，一般当整个微服务架构整体的负载超出了预设的上限阈值（和服务器的配置性能有关系），或者即将到来的流量预计会超过预设的阈值时（比如双11、6.18等活动或者秒杀活动）

降级所带来的牺牲

• 强强一致性变成最终一致性。大多数的系统是不需要强一致性的。强一致性要求多种资源的占用，而减少强一致性就能释放更多资源。
• 干掉一些次要功能。停止访问不重要的功能，从而释放出更多的资源。比如电商网站，评论功能流量大的时候就能停掉，当然能不直接干掉就别直接，最好能简化流程或者限流最好。
• 简化功能流程。把一些功能简化掉。

降级需要注意的事项

• 对业务进行仔细的梳理和分析，哪些是核心流程必须保证的，哪些是可以牺牲的
• 什么指标下能进行降级，吞吐量、响应时间、失败次数等达到一个阈值才进行降级处理
• 如何降级，降级最简单的就是在业务代码中配置一个开关或者做成配置中心模式，直接在配置中心上更改配置，推送到相应的服务。

熔断

服务熔断是应对系统服务雪崩的一种保险措施，给出的一种特殊降级措施。

系统发生异常或者延迟或者流量太大，都会触发该服务的服务熔断措施。服务熔断依赖于下游服务，避免引发系统崩溃，系统自动执行和恢复，这是对局部的一种保险措施。

场景

微服务之间的数据交互是通过远程调用来完成的。服务A调用服务，服务B调用服务C，某一时间服务C的调用响应时间过长或者服务C不可用，随着访问增长，对服务C的调用也越来越多，然后服务C崩溃了，但是链路调用还在，对服务B的调用也在持续增多，然后服务B崩溃，随之A也崩溃，导致雪崩效应。

服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

总结

• 限流一般是在被调时生效
• 降级是用户所享有的服务变差了
• 熔断是在主调生效，也有一部分熔断设计是在被调生效的
• 限流和熔断都会带来降级