熔断、限流、降级都是保持系统稳定运行的策略，但针对的场景有所不同，常用框架有 hystrix 和 sentinel
限流
限流是指上游服务对本服务请求 QPS 超过阙值时，通过一定的策略(如延迟处理、拒绝处理)对上游服务的请求量进行限制，以保证本服务不被压垮，从而持续提供稳定服务。常见的限流算法有滑动窗口、令牌桶、漏桶等
如上图，当 服务 B 对 服务 D 请求过多时，服务 D 可以放弃一部分请求，保证自身服务的稳定
常见限流算法
https://www.cnblogs.com/taromilk/p/11751211.html
限流规则参数说明：
限流类型：分为 HSF 限流和 HTTP 限流。请根据应用的访问类型，选择具体的限流类型。
需要限流的接口：列出了应用中所有的接口。请根据实际情况选择需要限流的接口。
需要限流的方法：针对选择的接口，自动加载接口内所有的方法。可以根据实际情况选择某个方法进行限流，也可以选择对全部方法都进行限流。
被限流的应用：此时列表中将加载除当前应用以外的所有应用，因为每一个应用都可能会访问当前应用。请根据实际情况，选择被限流的应用。
限流粒度：主要分为 QPS 限流和 Thread 限流。
QPS 限流表示对请求中每秒请求次数的限制；
Thread 限流是对线程数的限制。
一般来讲线程越大则 QPS 越大，但是一个线程的 QPS 一般都会 >1，因为一个线程会持续发请求，请求的响应时间一般就几十毫秒。
限流阈值：高于阈值时将触发限流动作。
熔断
服务熔断的作用类似于我们家用的保险丝，当下游某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用
上面的解释中有两个很关键的词，一个是暂时，一个是停止。
停止是说，当前服务一旦对下游服务进行熔断，当请求到达时，当前服务不再对下游服务进行调用，而是使用设定好的策略(如构建默认值)直接返回
暂时是说，熔断后，并不会一直不再调用下游服务，而是以一定的策略(如每分钟调用 10 次，若均返回成功，则增大调用量)试探调用下游服务，当下游服务恢复可用时，自动停止熔断。
如上图，当 服务 D 不可用时，服务 B 应对 服务 D 进行熔断。
熔断器的设计思路
Closed：初始状态，熔断器关闭，正常提供服务
Open: 失败次数，失败百分比达到一定的阈值之后，熔断器打开，停止访问服务
Half-Open：熔断一定时间之后，小流量尝试调用服务，如果成功则恢复，熔断器变为 Closed 状态
熔断机制
https://www.cnblogs.com/yawen/p/6655352.html
降级
降级是指当自身服务压力增大时，采取一些手段，增强自身服务的处理能力，以保障服务的持续可用。比如，下线非核心服务以保证核心服务的稳定、降低实时性、降低数据一致性
常见降级策略
业务降级，是指牺牲非核心的业务功能，保证核心功能的稳定运行。
简单来说，要实现优雅的业务降级，需要将功能实现拆分到相对独立的不同代码单元，分优先级进行隔离。在后台通过开关控制，降级部分非主流程的业务功能，减轻系统依赖和性能损耗，从而提升集群的整体吞吐率。
降级的重点是：业务之间有优先级之分。降级的典型应用是：电商活动期间。
总结
| 措施 | 产生原因 | ** 针对服务** |
|---|---|---|
| 限流 | 上游服务请求增多 | 上游服务 |
| 熔断 | 下游服务不可用 | 下游服务 |
| 降级 | 自身服务的处理能力不够 | 自身服务 |
降级熔断相似点
- 目的一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段
- 最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用
- 粒度一般都是服务级别
- 自治性要求很高，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段
降级熔断区别
- 触发原因不一样，服务熔断一般是某个服务（下游服务）故障引起，
- 服务降级一般是从整体负荷考虑
- 自愈能力要求不一样，服务熔断在发生后有自愈能力，而服务降级没有该职责
