第四章 Sentinel--服务容错

@RestController
@Slf4j
public class OrderController2 {
@Autowired
private OrderService orderService;
@Autowired
private ProductService productService;
@RequestMapping("/order/prod/{pid}")
public Order order(@PathVariable("pid") Integer pid) {
log.info("接收到{}号商品的下单请求,接下来调用商品微服务查询此商品信息", pid);
//调用商品微服务,查询商品信息
Product product = productService.findByPid(pid);
log.info("查询到{}号商品的信息,内容是:{}", pid, JSON.toJSONString(product));
//模拟一次网络延时
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
//下单(创建订单)
Order order = new Order();
order.setUid(1);
order.setUsername("测试用户");
order.setPid(pid);
order.setPname(product.getPname());
order.setPprice(product.getPprice());
order.setNumber(1);
//为了不产生太多垃圾数据,暂时不做订单保存
//orderService.createOrder(order);
log.info("创建订单成功,订单信息为{}", JSON.toJSONString(order));
return order;
}
@RequestMapping("/order/message")
public String message() {
return "高并发下的问题测试";
}
}

server:
port: 8091
tomcat:
max-threads: 10 #tomcat的最大并发值修改为10,默认是200

3 接下来使用压测工具 , 对请求进行压力测试

下载地址 https://jmeter.apache.org/

第一步：修改配置，并启动软件

进入 bin 目录 , 修改 jmeter.properties 文件中的语言支持为 language=zh_CN ，然后点击 jmeter.bat

启动软件。

第二步：添加线程组

第三步：配置线程并发数

第四步：添加 Http 取样

第五步：配置取样，并启动测试

4 访问ｍ essage 方法观察效果

此时会发现 , 由于 order 方法囤积了大量请求 , 导致ｍ essage 方法的访问出现了问题，这就是 服务雪

崩 的雏形。

4.2 服务雪崩效应

在分布式系统中 , 由于网络原因或自身的原因 , 服务一般无法保证 100% 可用。如果一个服务出现了

问题，调用这个服务就会出现线程阻塞的情况，此时若有大量的请求涌入，就会出现多条线程阻塞等

待，进而导致服务瘫痪。

由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是

服务故障的 “ 雪崩效应 ” 。

雪崩发生的原因多种多样，有不合理的容量设计，或者是高并发下某一个方法响应变慢，亦或是某

台机器的资源耗尽。我们无法完全杜绝雪崩源头的发生，只有做好足够的容错，保证在一个服务发生问

题，不会影响到其它服务的正常运行。也就是＂雪落而不雪崩＂。

4.3 常见容错方案

要防止雪崩的扩散，我们就要做好服务的容错，容错说白了就是保护自己不被猪队友拖垮的一些措

施 , 下面介绍常见的服务容错思路和组件。

常见的容错思路

常见的容错思路有隔离、超时、限流、熔断、降级这几种，下面分别介绍一下。

隔离

它是指将系统按照一定的原则划分为若干个服务模块，各个模块之间相对独立，无强依赖。当有故

障发生时，能将问题和影响隔离在某个模块内部，而不扩散风险，不波及其它模块，不影响整体的

系统服务。常见的隔离方式有：线程池隔离和信号量隔离．

超时

在上游服务调用下游服务的时候，设置一个最大响应时间，如果超过这个时间，下游未作出反应，

就断开请求，释放掉线程。

限流

限流就是限制系统的输入和输出流量已达到保护系统的目的。为了保证系统的稳固运行 , 一旦达到

的需要限制的阈值 , 就需要限制流量并采取少量措施以完成限制流量的目的。

熔断 在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整

体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。

服务熔断一般有三种状态：

熔断关闭状态（ Closed ）

服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制

熔断开启状态（ Open ）

后续对该服务接口的调用不再经过网络，直接执行本地的 fallback 方法

半熔断状态（ Half-Open ）

尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率。如果成功率达到预

期，则说明服务已恢复，进入熔断关闭状态；如果成功率仍旧很低，则重新进入熔断关闭状

态。

降级

降级其实就是为服务提供一个托底方案，一旦服务无法正常调用，就使用托底方案。

常见的容错组件

Hystrix

Hystrix 是由 Netflix 开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止

级联失败，从而提升系统的可用性与容错性。

Resilience4J

Resilicence4J 一款非常轻量、简单，并且文档非常清晰、丰富的熔断工具，这也是 Hystrix 官方推

荐的替代产品。不仅如此， Resilicence4j 还原生支持 Spring Boot 1.x/2.x ，而且监控也支持和

prometheus 等多款主流产品进行整合。

Sentinel

Sentinel 是阿里巴巴开源的一款断路器实现，本身在阿里内部已经被大规模采用，非常稳定。

下面是三个组件在各方面的对比：

4.4 Sentinel 入门

4.4.1 什么是 Sentinel

Sentinel ( 分布式系统的流量防卫兵 ) 是阿里开源的一套用于 服务容错 的综合性解决方案。它以流量

为切入点 , 从 流量控制、熔断降级、系统负载保护 等多个维度来保护服务的稳定性。

Sentinel 具有以下特征 :

丰富的应用场景 ： Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景 , 例如秒杀（即

突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用

应用等。

完备的实时监控 ： Sentinel 提供了实时的监控功能。通过控制台可以看到接入应用的单台机器秒

级数据 , 甚至 500 台以下规模的集群的汇总运行情况。

广泛的开源生态 ： Sentinel 提供开箱即用的与其它开源框架 / 库的整合模块 , 例如与 Spring

Cloud 、 Dubbo 、 gRPC 的整合。只需要引入相应的依赖并进行简单的配置即可快速地接入

Sentinel 。 完善的 SPI 扩展点 ： Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快

速地定制逻辑。例如定制规则管理、适配动态数据源等。

Sentinel 分为两个部分 :

核心库（ Java 客户端）不依赖任何框架 / 库 , 能够运行于所有 Java 运行时环境，同时对 Dubbo /

Spring Cloud 等框架也有较好的支持。

控制台（ Dashboard ）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等

应用容器

4.4.2 微服务集成 Sentinel

为微服务集成 Sentinel 非常简单 , 只需要加入 Sentinel 的依赖即可

1 在 pom.xml 中加入下面依赖

<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

2 编写一个 Controller 测试使用

@RestController
@Slf4j
public class OrderController3 {
@RequestMapping("/order/message1")
public String message1() {
return "message1";
}
@RequestMapping("/order/message2")
public String message2() {
return "message2";
}
}

4.4.3 安装 Sentinel 控制台

Sentinel 提供一个轻量级的控制台 , 它提供机器发现、单机资源实时监控以及规则管理等功能。

1 下载 jar 包 , 解压到文件夹

https://github.com/alibaba/Sentinel/releases

2 启动控制台

# 直接使用jar命令启动项目(控制台本身是一个SpringBoot项目)
java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -
Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.7.0.jar

3 修改 shop - order , 在里面加入有关控制台的配置

spring:
cloud:
sentinel:
transport:
port: 9999 #跟控制台交流的端口,随意指定一个未使用的端口即可
dashboard: localhost:8080 # 指定控制台服务的地址

第 4 步 : 通过浏览器访问 localhost:8080 进入控制台 ( 默认用户名密码是 sentinel/sentinel )

补充：了解控制台的使用原理

Sentinel 的控制台其实就是一个 SpringBoot 编写的程序。我们需要将我们的微服务程序注册到控制台上 ,

即在微服务中指定控制台的地址 , 并且还要开启一个跟控制台传递数据的端口 , 控制台也可以通过此端口

调用微服务中的监控程序获取微服务的各种信息。

4.4.4 实现一个接口的限流

1 通过控制台为 message1 添加一个流控规则

4.5 Sentinel 的概念和功能

4.5.1 基本概念

资源

资源就是 Sentinel 要保护的东西

资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，可以是一个服务，也可以是

一个方法，甚至可以是一段代码。

我们入门案例中的 message1 方法就可以认为是一个资源

规则

规则就是用来定义如何进行保护资源的

作用在资源之上 , 定义以什么样的方式保护资源，主要包括流量控制规则、熔断降级规则以及系统

保护规则。

我们入门案例中就是为 message1 资源设置了一种流控规则 , 限制了进入 message1 的流量

4.5.2 重要功能

Sentinel 的主要功能就是容错，主要体现为下面这三个：

流量控制

流量控制在网络传输中是一个常用的概念，它用于调整网络包的数据。任意时间到来的请求往往是

随机不可控的，而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。

Sentinel 作为一个调配器，可以根据需要把随机的请求调整成合适的形状。

熔断降级

当检测到调用链路中某个资源出现不稳定的表现，例如请求响应时间长或异常比例升高的时候，则

对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联故障。

Sentinel 对这个问题采取了两种手段 :

通过并发线程数进行限制

Sentinel 通过限制资源并发线程的数量，来减少不稳定资源对其它资源的影响。当某个资源

出现不稳定的情况下，例如响应时间变长，对资源的直接影响就是会造成线程数的逐步堆

积。当线程数在特定资源上堆积到一定的数量之后，对该资源的新请求就会被拒绝。堆积的

线程完成任务后才开始继续接收请求。

通过响应时间对资源进行降级

除了对并发线程数进行控制以外， Sentinel 还可以通过响应时间来快速降级不稳定的资源。

当依赖的资源出现响应时间过长后，所有对该资源的访问都会被直接拒绝，直到过了指定的

时间窗口之后才重新恢复。

Sentinel 和 Hystrix 的区别

两者的原则是一致的 , 都是当一个资源出现问题时 , 让其快速失败 , 不要波及到其它服务

但是在限制的手段上 , 确采取了完全不一样的方法 :

Hystrix 采用的是线程池隔离的方式 , 优点是做到了资源之间的隔离 , 缺点是增加了线程

切换的成本。

Sentinel 采用的是通过并发线程的数量和响应时间来对资源做限制。

系统负载保护

Sentinel 同时提供系统维度的自适应保护能力。当系统负载较高的时候，如果还持续让

请求进入可能会导致系统崩溃，无法响应。在集群环境下，会把本应这台机器承载的流量转发到其

它的机器上去。如果这个时候其它的机器也处在一个边缘状态的时候， Sentinel 提供了对应的保

护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请

求。

总之一句话 : 我们需要做的事情，就是在 Sentinel 的资源上配置各种各样的规则，来实现各种容错的功

能。

4.6 Sentinel 规则

4.6.1 流控规则

流量控制，其原理是监控应用流量的 QPS( 每秒查询率 ) 或并发线程数等指标，当达到指定的阈值时

对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。

第 1 步 : 点击簇点链路，我们就可以看到访问过的接口地址，然后点击对应的流控按钮，进入流控规则配

置页面。新增流控规则界面如下

资源名 ：唯一名称，默认是请求路径，可自定义

针对来源 ：指定对哪个微服务进行限流，默认指 default ，意思是不区分来源，全部限制

阈值类型 / 单机阈值 ：

QPS （每秒请求数量） : 当调用该接口的 QPS 达到阈值的时候，进行限流

线程数：当调用该接口的线程数达到阈值的时候，进行限流

是否集群 ：暂不需要集群

接下来我们以 QPS 为例来研究限流规则的配置。

4.6.1.1 简单配置

我们先做一个简单配置，设置阈值类型为 QPS ，单机阈值为 3 。即每秒请求量大于 3 的时候开始限流。 接下来，在流控规则页面就可以看到这个配置。

然后快速访问 /order/message1 接口，观察效果。此时发现，当 QPS > 3 的时候，服务就不能正常响

应，而是返回 Blocked b y Sentinel (flo w limiting) 结果。

4.6.1.2 配置流控模式

点击上面设置流控规则的 编辑 按钮，然后在编辑页面点击 高级选项 ，会看到有流控模式一栏

sentinel 共有三种流控模式，分别是：

直接（默认）：接口达到限流条件时，开启限流

关联：当关联的资源达到限流条件时，开启限流 [ 适合做应用让步 ]

链路：当从某个接口过来的资源达到限流条件时，开启限流

下面呢分别演示三种模式：

直接流控模式

直接流控模式是最简单的模式，当指定的接口达到限流条件时开启限流。上面案例使用的就是直接流控

模式。

关联流控模式

关联流控模式指的是，当指定接口关联的接口达到限流条件时，开启对指定接口开启限流。 第 1 步：配置限流规则 , 将流控模式设置为关联，关联资源设置为的 /order/message2 。

第 3 步：通过 postman