当前位置：首页 > news >正文

[Java]微服务之服务保护

news 2025/7/15 20:28:00

雪崩问题

微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩

雪崩问题产生的原因是什么?

微服务相互调用，服务提供者出现故障或阻塞。
服务调用者没有做好异常处理，导致自身故障。
调用链中的所有服务级联失败，导致整个集群故障

解决问题的思路有哪些?

尽量避免服务出现故障或阻塞
保证代码的健壮性
保证网络畅通
能应对较高的并发请求
服务调用者做好远程调用异常的后备方案，避免故障扩散

请求限流: 也叫流量整形, 限制访问微服务的请求的并发量，避免服务因流量激增出现故障。

线程隔离: 也叫做舱壁模式，模拟船舱隔板的防水原理。通过限定每个业务能使用的线程数量而将故障业务隔离，避免故障扩散。

服务熔断:由断路器统计请求的异常比例或慢调用比例，如果超出阈值则会熔断该业务，则拦截该接口的请求。

熔断期间，所有请求快速失败，全都走fallback逻辑。
fallback逻辑的作用就是兜底, 让业务失败时不抛出异常, 而是返回默认数据或友好的提示

服务保护技术

Sentinel

入门

Sentinel是阿里巴巴开源的一款微服务流量控制组件。

官网地址: https://sentinelquard.io/zh-cn/index.html
Sentinel 的使用可以分为两个部分:

核心库（Jar包）：不依赖任何框架/库，能够运行于 Java 8 及以上的版本的运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。在项目中引入依赖即可实现服务限流、隔离、熔断等功能。
控制台（Dashboard）：Dashboard 主要负责管理推送规则、监控、管理机器信息等。

搭建Sentinel的控制台

下载jar包

下载地址： Releases · alibaba/Sentinel · GitHub
也可以直接使用课前资料提供的jar包

运行

将jar包放在任意非中文、不包含特殊字符的目录下，重命名为sentinel-dashboard.jar

打开cmd窗口, 然后运行如下命令启动控制台：

// java -jar sentinel-dashboard.jar 启动jar包
// -Dserver.port=8090 配置启动端口, 默认8080端口冲突
// -Dcsp.sentinel.dashboard.server=localhost:8090 控制台服务地址也要改
// -Dproject.name=sentinel-dashboard 配置项目名称
// 以上是启动命令的解释
java -Dserver.port=8090 -Dcsp.sentinel.dashboard.server=localhost:8090 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard.jar

更多配置项: 启动配置项 · alibaba/Sentinel Wiki · GitHub

访问服务页面: http://localhost:8090，就可以看到sentinel的控制台了

需要输入账号和密码，默认都是：sentinel
登录后，即可看到控制台，默认会监控sentinel-dashboard服务本身：

微服务整合

目标: 在cart-service模块中整合sentinel，连接sentinel-dashboard控制台
引入sentinel依赖

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

配置控制台:

spring:cloud:sentinel:transport:dashboard: localhost:8090 # sentinel控制台地址

访问cart-service的任意端点

重启cart-service，然后访问查询购物车接口，
sentinel的客户端就会将服务访问的信息提交到sentinel-dashboard控制台。
并展示出统计信息：

点击簇点链路菜单，会看到下面的页面：

簇点链路，就是单机调用链路。是一次请求进入服务后经过的每一个被Sentinel监控的资源链。
默认Sentinel会监控SpringMVC的每一个Endpoint(http接口)。
限流、熔断等都是针对簇点链路中的资源设置的。
而资源名默认就是接口的请求路径
我们的SpringMVC接口是Restful风格，因此购物车的查询、删除、修改等接口全部都是/carts路径

默认情况下Sentinel会把路径作为簇点资源的名称，无法区分路径相同但请求方式不同的接口，查询、删除、修改等都被识别为一个簇点资源，这显然是不合适的。

所以要修改配置，把请求方式 + 请求路径作为簇点资源名
cart-service的application.yml中添加下面的配置：

spring:cloud:sentinel:transport:dashboard: localhost:8090http-method-specify: true # 开启请求方式前缀

重启服务，通过页面访问购物车的相关接口，可以看到sentinel控制台的簇点链路发生了变化：

请求限流

在簇点链路后面点击流控按钮，即可对其做限流配置：

QPS: 每秒请求次数
单机阈值: 触发流量控制的数值

我们利用Jemeter做限流测试，每秒发出10个请求：

按照资料中Jmeter稳定, 安装并熟悉工具

把资料中的测试文本拖入Jemeter

启动测试

查看监控结果

可以看出GET:/carts这个接口的通过QPS稳定在6附近，而拒绝的QPS在4附近，符合我们的预期

线程隔离

限流可以降低服务器压力，尽量减少因并发流量引起的服务故障的概率，但并不能完全避免服务故障。

一旦某个服务出现故障，我们必须隔离对这个服务的调用，避免发生雪崩。

比如，查询购物车的时候需要查询商品，
为了避免因商品服务出现故障导致购物车其他服务受到影响，
我们可以把购物车业务中查询商品的业务隔离起来，限制可用的线程资源

这样，即便商品服务出现故障，最多导致查询购物车业务故障，
并且可用的线程资源也被限定在一定范围，不会导致整个购物车服务崩溃。
所以，我们要对查询商品的FeignClient接口做线程隔离。

设置线程隔离

5个并发线程, 如果单线程QPS为2, 则5线程QPS为10
也就是说这个查询功能最多使用5个线程, 如果查询商品的接口每秒处理2个请求，则5个线程的实际QPS在10左右，而超出的请求自然会被拒绝。

模拟商品查询慢服务, 配置购物车服务的tomcat的资源上限

@Api(tags = "商品管理相关接口")
@RestController
@RequestMapping("/items")
@RequiredArgsConstructor
public class ItemController {@ApiOperation("根据id批量查询商品")@GetMappingpublic List<ItemDTO> queryItemByIds(@RequestParam("ids") List<Long> ids){// 模拟业务延迟// 休眠500毫秒ThreadUtil.sleep(500);return itemService.queryItemByIds(ids);}}

server:port: 8082tomcat:threads:max: 25 # 最大线程数accept-count: 25 # 队列最大长度(线程满了在队列中等待)max-connections: 100 # 允许的最大连接数

查询购物车的接口处理速度比较慢, 其他增删改的接口速度是正常的

我们利用Jemeter，每秒发送100个请求, 让查询购物车接口的线程耗尽, 查看其他接口是否受影响

因为查询购物车业务的线程被耗尽, 导致查询购物车失败
但是因为做了线程隔离, 添加购物车等业务并没有被影响
如果不做线程隔离, 因为商品服务出现问题, 导致查询购物车接口处理非常慢
请求一直增加, 业务处理不完, 资源就无法释放,
最终导致tomcat资源被耗尽, 整个购物车所有的业务都无法访问了,
所以线程隔离的作用就是把可能的故障, 限制在一定范围内, 避免雪崩现象

Fallback

通过线程隔离, 可以对服务起到保护作用, 某一个业务出现问题不会影响其他业务, 但是被隔离的这个业务, 一旦出现问题, 还是会出现业务不可用的问题, 影响用户体验, 所以需要通过后备方案, 处理可能出问题的业务

针对远程调用进行线程隔离, 并设置Fallback

将FeignClient作为Sentinel的簇点资源(开启远程监控):

feign:okhttp:enabled: true # 开启OKHttp连接池支持sentinel:enabled: true # 开启sentinel

FeignClient的Fallback有两种配置方式:

方式一: FallbackClass，无法对远程调用的异常做处理
方式二: FallbackFactory，可以对远程调用的异常做处理，通常都会选择这种 (推荐)

自定义类，实现FallbackFactory，编写对某个FeignClient的fallback逻辑

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

可以记录一些错误日志, 设置调用失败返回的默认数据, 或者直接抛出异常, 由调用者进行处理

将刚刚定义的FallbackFactory注册为一个Bean

public class DefaultFeignConfig {@Beanpublic ItemClientFallbackFactory itemClientFallbackFactory(){return new ItemClientFallbackFactory();}
}

在接口中使用自定义FallbackFactory

@FeignClient(value = "item-service",configuration = DefaultFeignConfig.class, 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);
}