讨论问题：微服务要不要引入分布式事务？

1、分布式事务的场景分析

如下图：

这里我们分别白话了解一下几个关键字 TM RM TC

• TC：就是我们部署的分布式事务中间件（seata、dtm等）
• RM：RPC层，直接请求db的服务（Resource Manager 资源管理器）
• TM：API层，聚合RPC服务暴露的restful接口服务 (Transaction Manager 表示事务管理器，协调事务和管理资源)

2、分析利与弊

好处：

• 抽象了TC这个中间服务，独立部署了与业务无关的组件进行事务控制

缺点：

• 引入这个分布式事务中间服务被API、RPC所有的微服务全部耦合
• 用不好具体的事务模式（AT TCC Saga XA）就会降低执行效率
• 对开发人员的门槛提高

3、如何优化分布式事务

3.1 什么是CAP理论

CAP即：

• Consistency（一致性）
• Availability（可用性）
• Partition tolerance（分区容忍性）

这三个性质对应了分布式系统的三个指标：
而CAP理论说的就是：一个分布式系统，不可能同时做到这三点。如下图：

3.2 方式一：避免使用分布式事务

如下图：

1）同步阻塞

保CP强一致性
库存扣减不做完不返回结果，库存扣减失败直接返回异常
损失用户体验，请求时间可能会过长

2）异步调用

保AP 最终一致性

订单出库成功：订单完成，业务结束

订单出库失败：

• 因为技术问题出库失败，重试补偿
• 因为业务问题出库失败（库存不存）：撤销订单-短信通知、补偿用户

对异步调用一定要做好资源检验与锁定，避免产生业务问题

3）粗粒度设计

将需要分布式事务的业务设计在一个微服务内

3.3 方式二：使用分布式事务

原则：不超过3层的分布式事务微服务的链条

分布式一致性问题会死者调用的层级增加（A-B-C-D-E）难度激增，因此不建议超过3层调用层级
如果出现可以考虑服务聚合缩短调用链（A-(BC)-(DE))

参考

不要在项目中使用分布式事务中间件