环境准备
我们准备好三个服务
订单服务Order-Module
库存服务Storage-Module
账户服务Account-Module
业务需求：下订单->减库存->扣余额->改(订单)状态
业务逻辑代码实现：
image.png
正常的测试
我们先发送一个下订单的接口
image.png
用户id为1，产品id也为1，下单的数量是10，金额是100
我们分别看一下数据库
订单表：状态1表示下单成功，0表示下单失败
image.png
账户表：
image.png
可以看到账户表里的余额减少了100
库存表：
image.png
库存表的库存也减少了10
日志也是正常打印的
image.png
这是正常的流程，接下来我们测试异常的情况
异常情况下的测试
我们先在代码里让账户服务睡20s，来制造超时
image.png
我们再发一下同样的接口
image.png
可以看到此时系统报错了
我们再分别查看一下数据库
账户表：
image.png
库存表：
image.png
库存表：
image.png
可以看到账户和库存的数量都减少了，但是新增的订单数据的状态是下单失败。
我们再看一下日志
image.png
原因是走到扣减金额这一步就报超时了，导致订单状态修改失败。
那么这样我们就要用到seata来解决这个问题了。
Seata回滚测试
我们要在service方法前面加上@GlobalTransactional全局事务注解
image.png
接下来我们重启再进行测试
可以看到接口还是超时的，但是我们可以发现数据库里的数据没有任何改变！
我们再看一下日志
image.png
可以看到虽然还是超时了，但这次使用了Seata的回滚方法，保证了数据的一致性。
