概述：

在开发公司商城项目时，由于采用的是微服务架构，每个模块之间使用OpenFeign组件进行通信，在遇到高并发时，为了保证系统的可用性和 可靠性，我们使用了阿里的Alibaba的Sentinel组件进行降级、限流和熔断处理。接下来介绍下这三个基本的概念：服务熔断、服务降级和服务限流是怎么回事。

一、熔断

在介绍熔断机制之前，我们需要了解微服务的雪崩效应。在微服务架构中，微服务是完成一个单一的业务功能，这样做的好处是可以做到解耦，每个微服务可以独立演进。但是，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。这就带来一个问题，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。

熔断机制是应对雪崩效应的一种微服务链路保护机制。我们在各种场景下都会接触到熔断这两个字。高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。同样，在微服务架构中，熔断机制也是起着类似的作用。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

简明地说：

熔断就是 在服务的依赖调用中，被调用方出现故障时，出于自我保护的目的，调用方会主动停止调用，并根据业务需要进行相应处理。

图解：

为什么要熔断
假定服务A依赖服务B，当服务B处于正常状态，整个调用是健康的，服务A可以得到服务B的正常响应。当服务B出现故障时，比如响应缓慢或者响应超时，如果服务A继续请求服务B，那么服务A的响应时间也会增加，进而导致服务A响应缓慢。如果服务A不进行熔断处理，服务B的故障会传导至服务A，最终导致服务A也不可用。

二、限流

限流是针对服务请求数量的一种自我保护机制，当请求数量超出服务的处理能力时，会自动丢弃新来的请求。

常见限流方式

基于请求限流：指从外部请求的角度考虑限流。
基于资源限流：指从系统内部考虑，找到影响性能的关键资源，对其使用上限限制。

目前主流的限流方法多采用 HPS 作为限流指标。

TPS
系统吞吐量是衡量系统性能的关键指标，按照事务的完成数量来限流是最合理的。
HPS
每秒请求数，指每秒钟服务端收到客户端的请求数量。
QPS
服务端每秒能够响应的客户端查询请求数量。

图解：

为什么要限流
任何一个系统的处理能力都是有极限的，假定服务A的处理能力为QPS=100，当QPS<100时服务A可以提供正常的服务。当QPS>100时，由于请求量增大，会出现争抢服务资源的情况（数据库连接、CPU、内存等），导致服务A处理缓慢；当QPS继续增大时，可能会造成服务A响应更加缓慢甚至奔溃。如果不进行限流控制，服务A始终会面临着被大流量冲击的风险。做好系统请求流量的评估，制定合理的限流策略，是我们进行系统高可用保护的第一步。

三、降级

降级是通过开关配置将某些不重要的业务功能屏蔽掉，以提高服务处理能力。在大促场景中经常会对某些服务进行降级处理，大促结束之后再进行复原。

通常原因为服务器的资源是有限的，而请求是无限的。在用户使用即并发高峰期，会影响整体服务的性能，严重的话会导致宕机，以至于某些重要服务不可用。故高峰期为了保证核心功能服务的可用性，就需要对某些服务降级处理。可以理解为舍小保大，通常处理为不让客户端等待而是立即返回一个友好的提示。

图解：

为什么要降级
在不影响业务核心链路的情况下，屏蔽某些不重要的业务功能，可以节省系统的处理时间，提供系统的响应能力，在服务器资源固定的前提下处理更多的请求。

源码下载：https://gitee.com/charlinchenlin/koo-erp