SpringCloud —— Sentinel详解-开发者社区

一、前言

在前面的课程中，我们可以发现一个问题，就是即使是低耦合的微服务架构，在微服务和微服务之间依然是有耦合的，比如相互之间的远程调用，这就导致一个微服务出现异常（不一定是崩溃，也有可能是请求处理速度变慢，响应时间过长），另一个微服务也会受到影响，同时，在调用链上的其他微服务也有可能受到影响，所以这是一个安全问题，我们在这里会给出几种方式用于解决这个问题。

二、Sentinel

Sentinel是一个中间件，可以通过流量控制、线程隔离、服务熔断的方式来降低异常发生后的风险。

1.快速入门

首先要在官网下载Sentinel，然后解压，在无中文的目录中使用命令行打开，命令如下：

java -Dserver.port=8090 -Dcsp.sentinel.dashboard.server=localhost:8090 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar

从这里就可以看出，我们是直接在windows上启动的Sentinel，但是Sentinel的客户端是使用SpringBoot开发的，最终启动后会占用tomcat默认的8080端口，在同一台电脑中，我们的项目网关端口也是8080，所以端口会冲突。

解决办法有两个，第一是用上述配置，在启动时更改端口号为8090，第二是在虚拟机中的docker容器中启动，这样就只会占用宿主机的8080端口。

这里我们选用前一种，比较快捷直观，而且由于之前我把项目也部署到docker容器中了，所以即使将Sentinel放到docker中，也有可能会出现端口冲突的问题。

启动后通过访问8090端口可以看到Sentinel的页面：

向需要进行微服务保护的微服务导入依赖：

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

配置Sentinel：

spring: cloud: sentinel: transport: dashboard: localhost:8090 # sentinel的控制台地址 http-method-specify: true # 是否设置请求方式作为资源名称

在访问一次购物车页面后就可以看得到购物车微服务的服务名称了：

2.流量限制

首先要了解请求被处理的流程：先建立连接，然后再排队，最后被处理。

为什么要限制流量？

因为流量会影响请求的响应速度，导致用户使用时会很“卡”，如果流量不被限制，并且变得太大时，SpringBoot默认的Tomcat线程池中的工作线程会被占满，新的请求就只能去排队了，而等待队列如果也被占满了，将会导致新请求被拒绝，这样用户就会完全无法访问网页了。

那为什么会影响响应速度呢？

因为请求超过处理能力后，会自动排队，这就导致许多请求无法被及时处理，也就是：

正常：响应时长=请求被处理的时长

过多：响应时长=请求被处理的时长+排队等待的时长

我们这里为了模拟服务响应超时，我们修改代码，让请求处理时长增加，从而尽可能让更多线程去排队：

@ApiOperation("根据id批量查询商品") @GetMapping public List<ItemDTO> queryItemByIds(@RequestParam("ids") List<Long> ids){ //TODO 模拟业务延迟 ThreadUtil.sleep(500); return itemService.queryItemByIds(ids); }

同时我们将Tomcat的最大线程处理数降低，等待队列的线程数降低，同时将最大连接数降低。

tomcat: threads: max: 25 accept-count: 25 max-connections: 100

这里限制这三个参数就是为了限制请求的处理，也就是降低Tomcat处理请求的能力，让Tomcat线程池尽快饱和，从而模拟大用户量的场景。

接下来，正式开始流量限制，首先先设置流量限制，我们这里配置访问购物车的流量限制：

然后我们使用测试软件jmeter模拟大用户量的情况：

开始测试，我们可以看到，异常率接近百分之四十，这是因为我们限制的流量是每秒6个，而测试案例是每秒十个（1000/100），所以平均每秒会有4个请求被抛出异常429。

在测试过程中，我们自己也访问购物车来测试，发现延迟在522ms，这说明我们访问购物车的时间是没变的，所以流量限制的好处：通过限制请求处理量，来保障被处理请求的质量。

3.线程隔离

线程隔离是指：在线程池中分配指定量线程给某个微服务，如果这个微服务异常，只会影响被分配的几个线程，其他线程不被影响，从而让其他和本微服务无耦合的微服务（不远程调用异常微服务的其他微服务）正常运行。

购物车中有一个功能是增加商品数量，这个是通过远程调用实现的，和购物车查询无关，如果我们将购物车查询功能线程隔离，那按道理说，即使查询异常，也不会影响增加商品的功能。

接下来尝试模拟这个场景：

一样的设置步骤，对于查询购物车的GET请求，在流控中选择并发线程数，我们这里设置为5：

这里我们设置测试的配置：

开始测试后，我们尝试增加商品到购物车，我们会发现，购物车是查不出来了，但是我们增加商品数量是不被影响的。

4.Fallback

我们先前的购物车微服务会远程调用ItemClient，如果远程调用失败就会抛异常，从而影响购物车的功能，Fallback指的是回退，其实就是一个备用方案，如果ItemClient远程调用异常，那么这个时候就会自动进入回退流程，重新创建一个远程调用对象，这个新对象中会重写方法，但是这个方法里面就没有逻辑了，直接返回空，并且报错误日志，这样就可以正常返回了，只是返回的是空，对于用户来讲，这个就不会过多影响其他功能，而报错的日志又对开发人员的维护起到提示作用。

先模拟商品微服务大用户量，方便后续让远程调用异常，从而逼它走fallback策略：

@ApiOperation("根据id批量查询商品") @GetMapping public List<ItemDTO> queryItemByIds(@RequestParam("ids") List<Long> ids){ //TODO 模拟业务延迟 ThreadUtil.sleep(500); return itemService.queryItemByIds(ids); }

首先需要创建一个工厂类，用于生成降级代理对象（替代方案）。

@Slf4j public class ItemClientFallbackFactory implements FallbackFactory<ItemClient> { @Override public ItemClient create(Throwable cause) { return new ItemClient() { @Override public List<ItemDTO> queryItemByIds(Collection<Long> ids) { log.error("查询商品失败：",cause); return CollUtils.emptyList(); } @Override public void deductStock(List<OrderDetailDTO> items) { log.error("扣减商品库存失败：",cause); throw new RuntimeException(cause); } }; } }

然后我们需要将工厂写到配置类中，在远程调用异常的时候生效。

public class DefaultFeignConfig { /** * 配置日志级别 * * @return */ @Bean public Logger.Level feignLoggerLevel() { return Logger.Level.FULL; } @Bean public RequestInterceptor userInfoRequestInterceptor() { return new RequestInterceptor() { @Override public void apply(RequestTemplate requestTemplate) { Long userId = UserContext.getUser(); if (userId != null) { requestTemplate.header("user-info", userId.toString()); } } }; } @Bean public ItemClientFallbackFactory itemClientFallbackFactory(){ return new ItemClientFallbackFactory(); } }

最后将配置类中的工厂方法配置到远程调用接口中去：

@FeignClient(value = "item-service",fallbackFactory = ItemClientFallbackFactory.class) public interface ItemClient { @GetMapping("/items") List<ItemDTO> queryItemByIds(@RequestParam("ids") Collection<Long> ids); @PutMapping("/items/stock/deduct") void deductStock(@RequestBody List<OrderDetailDTO> items); }

这样，我们就可以看到这个远程调用的资源名了，这就意味着我们可以单独对远程调用进行线程隔离了（远程调用和微服务共享一个线程池，所以是有隔离的必要的），隔离后，这个远程调用服务异常就不会对购物车微服务本身产生影响了，同时由于远程调用服务异常，会执行fallback，于是会返回空响应，从而让购物车其他功能不受影响。

我们对购物车进行测试，发现不会出现异常了

同时将响应空值回去。