黑马商城day5-服务保护和分布式事务

1. 什么是雪崩

存在服务A被购物车服务调用，此时服务A由于一些问题响应速度变慢。购物车第一个请求还没有得到响应，第二个请求又向服务A发出，如此类推，将会有很多请求占用Tomcat连接，此时哪怕可以请求正常的服务B，但是由于连接被占用导致没有多余连接可以向服务B发送请求。

发生这种情况，购物车服务的响应也会变慢（因为需要等服务A响应），此时有其他服务项购物车服务发送请求，购物车响应很慢，导致其他服务响应跟着也变慢，于是可能会导致整个微服务网络一起响应变慢，发生崩溃。这就是级联失败问题，或者叫雪崩问题。

2.微服务保护

保证服务运行的健壮性，避免级联失败导致的雪崩问题，就属于微服务保护。这章我们就一起来学习一下微服务保护的常见方案以及对应的技术。

2.1.服务保护方案

微服务保护的方案有很多，比如：

• 请求限流

• 线程隔离

• 服务熔断

这些方案或多或少都会导致服务的体验上略有下降，比如请求限流，降低了并发上限；线程隔离，降低了可用资源数量；服务熔断，降低了服务的完整度，部分服务变的不可用或弱可用。因此这些方案都属于服务降级的方案。但通过这些方案，服务的健壮性得到了提升，

接下来，我们就逐一了解这些方案的原理。

解决雪崩问题的常见方案有哪些？

• 请求限流：限制流量在服务可以处理的范围，避免因突发流量而故障
• 线程隔离：控制业务可用的线程数量，将故障隔离在一定范围
• 服务熔断：将异常比例过高的接口断开，拒绝所有请求，直接走fallback
• 失败处理：定义fallback逻辑，让业务失败时不再抛出异常，而是返回默认数据或友好提示

2.2.Sentinel

微服务保护的技术有很多，但在目前国内使用较多的还是Sentinel，所以接下来我们学习Sentinel的使用。

2.2.1 介绍与安装

Sentinel是阿里巴巴开源的一款服务保护框架，目前已经加入SpringCloudAlibaba中。官方网站：

https://sentinelguard.io/zh-cn/

Sentinel 的使用可以分为两个部分:

• 核心库（Jar包）：不依赖任何框架/库，能够运行于 Java 8 及以上的版本的运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。在项目中引入依赖即可实现服务限流、隔离、熔断等功能。

• 控制台（Dashboard）：Dashboard 主要负责管理推送规则、监控、管理机器信息等。

将jar包放在任意非中文、不包含特殊字符的目录下，重命名为sentinel-dashboard.jar：然后运行如下命令启动控制台：

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

需要输入账号和密码，默认都是：sentinel

登录后，即可看到控制台，默认会监控sentinel-dashboard服务本身：

2.2.2.微服务整合

我们在cart-service模块中整合sentinel，连接sentinel-dashboard控制台，步骤如下： 1）引入sentinel依赖

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

2）配置控制台

修改application.yaml文件，添加下面内容：

spring:cloud: sentinel:transport:dashboard: localhost:8090

3）访问cart-service的任意端点

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

所谓簇点链路，就是单机调用链路，是一次请求进入服务后经过的每一个被Sentinel监控的资源。默认情况下，Sentinel会监控SpringMVC的每一个Endpoint（接口）。

因此，我们看到/carts这个接口路径就是其中一个簇点，我们可以对其进行限流、熔断、隔离等保护措施。

不过，需要注意的是，我们的SpringMVC接口是按照Restful风格设计，因此购物车的查询、删除、修改等接口全部都是/carts路径：

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

所以我们可以选择打开Sentinel的请求方式前缀，把请求方式+请求路径作为簇点资源名：

首先，在cart-service的application.yml中添加下面的配置：

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

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

2.3.请求限流

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

在弹出的菜单中这样填写：

这样就把查询购物车列表这个簇点资源的流量限制在了每秒6个，也就是最大QPS为6.

注意，使用jmeter要右键点击启动，而不是使用工具栏的绿色按钮，不然会直接发送所有请求。

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

最终监控结果如下：可以看出GET:/carts这个接口的通过QPS稳定在6附近，而拒绝的QPS在4附近，符合我们的预期。

2.4.线程隔离

当商品服务出现阻塞或故障时，调用商品服务的购物车服务可能因此而被拖慢，甚至资源耗尽。所以必须限制购物车服务中查询商品这个业务的可用线程数，实现线程隔离。

2.4.1.OpenFeign整合Sentinel

修改cart-service模块的application.yml文件，开启Feign的sentinel功能

feign:sentinel:enabled: true # 开启feign对sentinel的支持

需要注意的是，默认情况下SpringBoot项目的tomcat最大线程数是200，允许的最大连接是8492，单机测试很难打满。

所以我们需要配置一下cart-service模块的application.yml文件，修改tomcat连接：

server:port: 8082tomcat:threads:max: 50 # 允许的最大线程数accept-count: 50 # 最大排队等待数量max-connections: 100 # 允许的最大连接

然后重启cart-service服务，可以看到查询商品的FeignClient自动变成了一个簇点资源：

2.4.2.配置线程隔离

接下来，点击查询商品的FeignClient对应的簇点资源后面的流控按钮：在弹出的表单中填写下面内容：注意，这里勾选的是并发线程数限制，也就是说这个查询功能最多使用5个线程，而不是5QPS。如果查询商品的接口每秒处理2个请求，则5个线程的实际QPS在10左右，而超出的请求自然会被拒绝。我们利用Jemeter测试，每秒发送100个请求最终测试结果如下：

进入查询购物车的请求每秒大概在100，而在查询商品时却只剩下每秒10左右，符合我们的预期。

此时如果我们通过页面访问购物车的其它接口，例如添加购物车、修改购物车商品数量，发现不受影响：响应时间非常短，这就证明线程隔离起到了作用，尽管查询购物车这个接口并发很高，但是它能使用的线程资源被限制了，因此不会影响到其它接口。

2.5 Fallback

超出的QPS上限的请求就只能抛出异常，从而导致购物车的查询失败。但从业务角度来说，即便没有查询到最新的商品信息，购物车也应该展示给用户，用户体验更好。也就是给查询失败设置一个降级处理逻辑。

触发限流或熔断后的请求不一定要直接报错，也可以返回一些默认数据或者友好提示，用户体验会更好。

给FeignClient编写失败后的降级逻辑有两种方式：

• 方式一：FallbackClass，无法对远程调用的异常做处理

• 方式二：FallbackFactory，可以对远程调用的异常做处理，我们一般选择这种方式。

这里我们演示方式二的失败降级处理。

步骤一：在hm-api模块中给ItemClient定义降级处理类，实现FallbackFactory：

@Slf4j
public class ItemClientFallback implements FallbackFactory<ItemClient> {@Overridepublic ItemClient create(Throwable cause) {return new ItemClient() {@Overridepublic List<ItemDTO> queryItemByIds(Collection<Long> ids) {log.error("远程调用ItemClient#queryItemByIds方法出现异常，参数：{}", ids, cause);// 查询购物车允许失败，查询失败，返回空集合return CollUtils.emptyList();}@Overridepublic void deductStock(List<OrderDetailDTO> items) {// 库存扣减业务需要触发事务回滚，查询失败，抛出异常throw new BizIllegalException(cause);}};}
}

步骤二：在hm-api模块中的com.hmall.api.config.DefaultFeignConfig类中将ItemClientFallback注册为一个Bean：步骤三：在hm-api模块中的ItemClient接口中使用ItemClientFallbackFactory：

重启后，再次测试，发现被限流的请求不再报错，走了降级逻辑：但是未被限流的请求延时依然很高：导致最终的平局响应时间较长。

观察控制台，同一个服务，有两种响应时间，能确定响应时间短的就是执行了Fallback逻辑。

执行Fallback为null，正常执行应该有数据：

2.6 服务熔断

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

Sentinel中的断路器不仅可以统计某个接口的慢请求比例，还可以统计异常请求比例。当这些比例超出阈值时，就会熔断该接口，即拦截访问该接口的一切请求，降级处理；当该接口恢复正常时，再放行对于该接口的请求。

断路器的工作状态切换有一个状态机来控制：

状态机包括三个状态：

• closed：关闭状态，断路器放行所有请求，并开始统计异常比例、慢请求比例。超过阈值则切换到open状态

• open：打开状态，服务调用被熔断，访问被熔断服务的请求会被拒绝，快速失败，直接走降级逻辑。Open状态持续一段时间后会进入half-open状态

• half-open：半开状态，放行一次请求，根据执行结果来判断接下来的操作。

  • 请求成功：则切换到closed状态

  • 请求失败：则切换到open状态

我们可以在控制台通过点击簇点后的熔断按钮来配置熔断策略：在弹出的表格中这样填写：

这种是按照慢调用比例来做熔断，上述配置的含义是：

• RT超过200毫秒的请求调用就是慢调用

• 统计最近1000ms内的最少5次请求，如果慢调用比例不低于0.5，则触发熔断

• 熔断持续时长20s

配置完成后，再次利用Jemeter测试，可以发现：

在一开始一段时间是允许访问的，后来触发熔断后，查询商品服务的接口通过QPS直接为0，所有请求都被熔断了。而查询购物车的本身并没有受到影响。

此时整个购物车查询服务的平均RT影响不大：

3. 分布式事务

下单业务，前端请求首先进入订单服务，创建订单并写入数据库。然后订单服务调用购物车服务和库存服务：

• 购物车服务负责清理购物车信息
• 库存服务负责扣减商品库存

整个业务中，各个本地事务是有关联的。因此每个微服务的本地事务，也可以称为分支事务。多个有关联的分支事务一起就组成了全局事务。我们必须保证整个全局事务同时成功或失败。

我们知道每一个分支事务就是传统的单体事务，都可以满足ACID（原子性，一致性，隔离性，持久性）特性，但全局事务跨越多个服务、多个数据库，是否还能满足呢？

由于购物车服务是被订单服务调用的，执行完毕服务后，连接就断了，购物车服务没办法知道库存服务发生失败。

在分布式系统中，如果一个业务需要多个服务合作完成，而且每一个服务都有事务，多个事务必须同时成功或失败，这样的事务就是分布式事务。其中的每个服务的事务就是一个分支事务。整个业务称为全局事务。

事务并未遵循ACID的原则，归其原因就是参与事务的多个子业务在不同的微服务，跨越了不同的数据库。虽然每个单独的业务都能在本地遵循ACID，但是它们互相之间没有感知，不知道有人失败了，无法保证最终结果的统一，也就无法遵循ACID的事务特性了。

这就是分布式事务问题，出现以下情况之一就可能产生分布式事务问题：

• 业务跨多个服务实现

• 业务跨多个数据源实现

3.1.认识Seata

解决分布式事务的方案有很多，但实现起来都比较复杂，因此我们一般会使用开源的框架来解决分布式事务问题。在众多的开源分布式事务框架中，功能最完善、使用最多的就是阿里巴巴在2019年开源的Seata了。

https://seata.apache.org/zh-cn/docs/overview/what-is-seata/

其实分布式事务产生的一个重要原因，就是参与事务的多个分支事务互相无感知，不知道彼此的执行状态。因此解决分布式事务的思想非常简单：

就是找一个统一的事务协调者，与多个分支事务通信，检测每个分支事务的执行状态，保证全局事务下的每一个分支事务同时成功或失败即可。大多数的分布式事务框架都是基于这个理论来实现的。

Seata也不例外，在Seata的事务管理中有三个重要的角色：

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。

• TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。

• RM (Resource Manager) - 资源管理器：管理分支事务，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata的工作架构如图所示：

我们要做的事：

1.TC是独立于其他服务的一个单独服务，所以我们要部署TC服务

2.引入Seata依赖，里面有TM和RM的功能。

3.2.部署TC服务

实现将TC服务部署在虚拟机中。

准备数据库表：Seata支持多种存储模式，但考虑到持久化的需要，我们一般选择基于数据库存储。执行课前资料提供的《seata-tc.sql》，导入数据库表：

1.将需要的文件复制到虚拟机root路径下。

seata路径下存放的是seata运行时的配置文件，比如application.yml

seata压缩包是seata的镜像。

2.先加载镜像：docker load seata-1.5.2.tar

然后创建seata容器并对seata配置文件进行挂载：

docker run --name seata \
-p 8099:8099 \
-p 7099:7099 \
-e SEATA_IP=192.168.150.101 \
-v ./seata:/seata-server/resources \
--privileged=true \
--network hm-net \
-d \
seataio/seata-server:1.5.2

要注意：这里nacos和mysql必须在同一容器网络下。

此时就可以在搜索栏输入路径打开seata控制台：http://192.168.64.127:7099/，默认用户名密码都为admin

3.3.微服务集成Seata

参与分布式事务的每一个微服务都需要集成Seata，我们以trade-service为例。

1.引入依赖

<!--统一配置管理--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId></dependency><!--读取bootstrap文件--><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-bootstrap</artifactId></dependency><!--seata--><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-seata</artifactId></dependency>

2.修改yml配置文件

由于这部分配置内容后续每个微服务模块都需要修改，所以将它抽取出来，使用nacos共享配置。

修改bootstrap.yaml配置文件，添加seata共享配置

spring:application:name: trade-service # 服务名称profiles:active: devcloud:nacos:server-addr: 192.168.64.128:8848 # nacos地址config:file-extension: yaml # 文件后缀名shared-configs: # 共享配置- dataId: shared-jdbc.yaml # 共享mybatis配置- dataId: shared-log.yaml # 共享日志配置- dataId: shared-swagger.yaml # 共享日志配置- dataId: shared-seata.yaml

修改application.yaml配置文件：

server:port: 8085
feign:okhttp:enabled: true # 开启OKHttp功能
hm:db:database: hm-tradeswagger:title: "黑马商城交易服务接口文档"package: com.hmall.trade.controllerdesc: 黑马商城交易服务接口文档

同理，在item和cart服务都做相同操作。

观察seata控制台，三个服务都添加进seata中

3.4.XA模式

3.4.1.XA模式及优缺点

XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的关系型数据库都对 XA 规范 提供了支持。Seata的XA模式如下：

RM一阶段的工作：

1. 注册分支事务到TC

2. 执行分支业务sql但不提交

3. 报告执行状态到TC

TC二阶段的工作：

1. TC检测各分支事务执行状态

   1. 如果都成功，通知所有RM提交事务

   2. 如果有失败，通知所有RM回滚事务

RM二阶段的工作：

• 接收TC指令，提交或回滚事务

优缺点：

XA模式的优点是什么？

• 事务的强一致性，满足ACID原则

• 常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点是什么？

• 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差

• 依赖关系型数据库实现事务

3.4.2.实现XA模式

1.修改application.yaml（每个参与事务的微服务），开启XA模式

seata:data-source-proxy-mode: XA

2.给发起全局事务的入口方法添加@GlobalTransacional注解。

重新运行服务，进行测试。日志显示成功回滚，数据库中购物车信息也并未消失，回滚成功。

3.5.AT模式

3.5.1 AT模式

Seata主推的是AT模式，AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。基本流程：

阶段一RM的工作：

• 注册分支事务

• 记录undo-log（数据快照）

• 执行业务sql并提交

• 报告事务状态

阶段二提交时RM的工作：

• 删除undo-log即可

阶段二回滚时RM的工作：

• 根据undo-log恢复数据到更新前

3.5.2.AT与XA的区别

简述AT模式与XA模式最大的区别是什么？

• XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。

• XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。

• XA模式强一致；AT模式最终一致

• AT模式在数据恢复到更新前，会出现一小段数据不一致的情况。假如需要回滚，此时事务已经结束资源也被释放，此时其他资源就可以进来访问，虽然过几毫秒数据就会被恢复。

可见，AT模式使用起来更加简单，无业务侵入，性能更好。因此企业90%的分布式事务都可以用AT模式来解决。

3.5.3.实现AT模式

AT模式的关键：可以基于快照恢复数据。

1.添加undo_log表到微服务对应数据库中。然后修改yml文件为AT模式。

2.开始测试，执行回滚。