目录
限流、降级和熔断是三种常用的系统稳定性策略，它们在高并发和高负载的场景下尤为重要。通常我们说为了保证系统的可用性，限流、降级、熔断一把梭，但是其实他们是三个不太相同的概念，作用也不太一样。
一、限流
1.1 简介
限流的是控制系统的并发流量，通过限制请求流量的手段防止过度的流量导致系统崩溃。一般用于应对突发流量高峰。
一般是被调用方对调用方进行限流。举个例子，我提供了一个查询用户信息服务，给集团内外的很多调用方使用，但是我为了保证我的可用性，我会对每个调用方做限流，防止某个月调用方不守规矩，把我的服务打挂了。
当然，也有在服务端给客户端直接做限流的，一般用于外部服务能力不太好的时候，比如电商网站大促的时候，可能会依赖很多银行的服务，但是银行服务本身可能没那么高的并发，所以在电商网站上自己控制一下QPS，起到限流的目的，避免下游系统被打挂。
1.2 限流算法
常见的限流算法有：
- 漏桶算法（常用）：系统请求先进入漏桶，再从漏桶中逐一取出请求执行，控制漏桶的流量。
- 令牌桶算法（常用）：系统请求会得到一个令牌，从令牌桶中取出一个令牌执行，控制令牌桶中令牌的数量。
- 计数器算法（简单）：系统请求被计数，通过比较当前请求数与限流阈值来判断是否限流。
- 可以阻塞算法：当系统达到限流阈值时，不再接受新请求，等到限流阈值降下来再接受请求。
- 令牌环算法：与令牌桶算法类似，但是在多个令牌桶之间形成环形结构，以便在不同的请求处理速率之间进行平衡。
- 最小延迟算法：基于预测每个请求的处理时间，并在处理完请求后进行延迟，以控制请求的速率。
- 滑动窗口（常用）：基于一个固定大小的时间窗口，允许在该时间窗口内的请求数不超过设定的阈值。这个时间窗口随着时间的推移不断滑动，以适应不同时间段内的请求流量。
二、降级
2.1 简介
降级是当系统负载过高时，主动关闭一些非核心功能，以确保核心功能的正常运行。一般用于在系统资源有限或响应时间过长时，通过降低服务质量保障核心服务。
举例来说，双十一期间，淘宝上面会把退款功能关闭，这就是一种降级手段，通过把一些非核心功能降级掉来保证核心功能可用。或者在某次腾讯视频挂了的时候用户名称默认显示腾讯用户，这也是一种降级方式，用兜底名称做展示。
降级可以在客户端，也可以在服务端，比如关闭部分非核心功能的话，可以直接把入口关掉，及服务端直接下掉入口。也可以客户端直接返回兜底逻辑，不做业务逻辑处理起到降级的目的。
2.2 降级的方式
延迟服务
比如发表了评论，重要服务，比如在文章中显示正常，但是延迟给用户增加积分，只是放到一个缓存中，等服务平稳之后再执行。
在粒度范围内关闭服务（片段降级或服务功能降级）
比如关闭相关文章的推荐，直接关闭推荐区。
页面异步请求降级
比如商品详情页上有推荐信息/配送至等异步加载的请求，如果这些信息响应慢或者后端服务有问题，可以进行降级；
写降级
比如秒杀抢购，我们可以只进行Cache的更新，然后异步同步扣减库存到DB，保证最终一致性即可，此时可以将 DB降级为Cache。
读降级
比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，这种方式适用于对读一致性要求不高的场景；
11月11日的零点到11月12日的零点之间无法退款，其实是采用了关闭服务的降级方式。
2.3 降级的介入方式
降级共有两种介入方式，分别是：自动开关降级和人工开关降级。
自动开关降级
自动开关降级的方式一般是当系统达到某些设定的条件（系统负载、资源使用情况、SLA等指标）之后，自动执行一些策略。
常见的可以作为自动降级条件的指标有以下几个：
服务超时
当访问的数据库/http服务/远程调用响应慢或者长时间响应慢，且该服务不是核心服务的话可以在超时后自动降级；
比如前面提到的详情页上有推荐和收藏功能，即使出现问题也不会影响用户的正常下单。如果是调用别人的远程服务，和对方定义一个服务响应最大时间，如果超时了则可以自动降级。
失败次数
调用外部服务的时候，除了超时以外最常见的异常情况就是调用失败。比如详情页中的库存信息，如果是某一次查询请求失败了，那么可以通过读取缓存数据等方式直接降级掉。
但是，这种降级可能存在一个问题，就是虽然一次请求展示了缓存，但是其他用户访问的时候还是会查询库存信息，这对于库存在系统来说就是雪上加霜。因为他可能已经有问题了，但是上游系统还是在不断的对他发送请求。
所以，可以针对这个查询库存的接口做统一的降级。设定一个失败次数的阈值，一旦整体失败次数达到这个阈值了，就对后续一段时间内的该查询接口做降级。直到其功能恢复。
发生故障
上面提到的失败可能是服务不稳定造成的，过一段时间可以自动恢复的。还有一种情况可能是依赖的服务彻底跪了、或者网络不通了等等。这种情况就可以直接降级了。
当HTTP请求返回固定的错误码、或者一个RPC请求的时候底层服务抛了异常以后，就认为有效障发生，对其进行降级即可。
限流降级
还有种电商网站常见的策略，那就是限流降级。对于某些功能，设定一个流量阈值，一旦流量达到阈值的话，就进行降级。
比如秒杀功能，如果一瞬间流量太大，就可以进行限流降级。对于后续访问的用户直接提示已售空、跳转错误页、或者让他输入验证码重试等。
人工开关降级
还有一种降级方式，那就是人工开关降级。
人工开关降级是指当系统维护人员在发现系统异常之后，通过人工修改参数、关闭服务等方式进行降级的方法。
这种方式的好处是比较灵活，能够根据异常情况灵活应对，但弊端是对人的要求比较高，一来需要维护人员对系统有足够的了解，另外要求维护人员在系统异常时能够在第一时间进行处置。
还有一种情况，可能也会人工介入，那就是在大促之前，预估到流量会十分巨大，提早的识别出风险，为了节省资源保证主流程的可用，开发人员可以手动将某个功能降级掉。
这里说的人工开关降级，并不一定是要人工操作，也可能是人工通过一个定时任务进行定时触发的。
2.4 降级工具
目前市面上，针对流量控制，限流降级主要有以下两种选择：Netflix Hystrix 和 Alibaba Sentinel。
Hystrix
Hystrix是一个库，它提供了服务与服务之间的容错功能，主要体现在延迟容错和熔断，从而做到控制分布式系统中的联动故障。Hystrix通过隔离服务的访问点，阻止联动故障，并提供故障的解决方案，从而提高了这个分布式系统的弹性。
Hystrix 的关注点在于以 隔离 和 熔断 为主的容错机制，超时或被熔断的调用将会快速失败，并可以提供 fallback 机制。
Sentinel
Sentinel 是阿里中间件团队开源的，面向分布式服务架构的轻量级高可用流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。
二者对比
| 特性 | Sentinel | Hystrix |
|---|---|---|
| 隔离策略 | 信号量隔离 | 线程池隔离/信号量隔离 |
| 熔断降级策略 | 基于响应时间或失败比率 | 基于失败比率 |
| 实时指标实现 | 滑动窗口 | 滑动窗口（基于RxJava） |
| 规则配置 | 支持多种数据源 | 支持多种数据源 |
| 扩展性 | 多个扩展点 | 插件的形式 |
| 基于注解的支持 | 支持 | 支持 |
| 限流 | 基于QPS，支持基于调用关系的限流 | 有限的支持 |
| 流量整形 | 支持慢启动、匀速器模式 | 不支持 |
| 系统负载保护 | 支持 | 不支持 |
| 控制台 | 开箱即用，可配置规则、查看秒级监控、机器发现等 | 不完善 |
| 常见框架的适配 | Servlet、Spring Cloud、Dubbo、gRPC等 | Servlet、Spring Cloud Netflix |
三、熔断
3.1 简介
熔断是为了防止系统因某个服务的故障而导致整体崩溃，类似于电路的熔断器。在检测到下游服务异常时，自动停止向该服务发送请求，并在一定时间后尝试恢复。
熔断一般发生在调用方，举个例子，当电商平台上有用户支付时，收银台发现某个支付渠道，如微信支付失败率突增，超时严重，那么就可以临时把这个支付方式熔断掉。
3.2 为什么需要熔断？
其实，在分布式系统中，为了保证整体服务可用性和一致性，很多系统都会引入重试机制，在有些情况下，重试其实是可以解决问题的，比如网络问题等，都可以通过重试来解决。
但是，有些情况下，重试并不能解决问题，反而会加剧问题的严重性，比如下游系统因为请求量太大，导致CPU已经被打满，数据库连接池被占满，这时候上游系统调不通就会不断进行重试，这种重试请求，对于下游系统来说，无疑是雪上加霜，给下游系统造成二次伤害。
而分布式系统，大多数的服务雪崩也是因为不断重试导致的，这种重试有可能是框架级别的自动重试、有可能是代码级别的重试逻辑、还有可能是用户的主动重试。
有些重试是无法避免的，而且如果因为防止雪崩，就不设计重试机制，也是一种因噎废食。