网站建设自学长春关键词搜索排名

雪崩问题

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

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

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

解决问题的思路有哪些?

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

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

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

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

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

服务保护技术

Sentinel

入门

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

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

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

搭建Sentinel的控制台

1. 下载jar包

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

1. 运行

• 将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

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

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

微服务整合

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

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

1. 配置控制台:

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

1. 访问cart-service的任意端点

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

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

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

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

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

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

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

请求限流

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

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

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

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

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

1. 启动测试

1. 查看监控结果

可以看出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

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

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

1. FeignClient的Fallback有两种配置方式:

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

1. 自定义类，实现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);}};}
}

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

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

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

1. 在接口中使用自定义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);
}

• cart-sevice服务调用hm-api中的ItemClient方法,
• 如果远程调用失败或者失败, 就会执行Fallback逻辑
• 当服务出现问题时, 最大程度的保证用户体验

1. 给远程调用接口设置线程隔离

1. 使用Jemeter工具耗尽查询购物车的资源, 继续使用购物车服务

• 查询购物车时, 调用商品查询服务失败, 因为商品查询服务资源耗尽
• Fallback逻辑生效, 商品业务给购物车业务返回了默认数据, 而不是抛出异常, 用户体验更稳定

服务熔断

熔断是解决雪崩问题的重要手段。思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求; 而当服务恢复时，断路器会放行访问该服务的请求。

1. 作用: 服务熔断的作用就是进一步降低故障服务对网络资源的占用
2. 表现: 既然服务已经出现了问题, 就不要再重复请求了, 既占用资源, 又拖慢业务响应
3. 前提: 使用服务熔断的前提是配置好Fallback, 保证熔断了进入应急处理, 而不是频繁报错

点击控制台中簇点资源后的熔断按钮，即可配置熔断策略

1. 资源名: 给哪个接口设置熔断规则
2. 最大RT: 超过200ms被视为慢调用
3. 比例阈值: 超过一半触发熔断
4. 熔断时间: 熔断后20s内不再请求服务, 而是触发后备逻辑

测试一下:

1. 使用Jmeter工具持续发请求, 耗尽查询商品接口的资源, 商品服务出现故障,
2. 购物车服务请求商品服务时, 响应速度还是很快,
3. 因为慢服务触发熔断, 直接进入后备逻辑, 而不是一直请求商品服务, 浪费网络资源