对于传统集中式架构，A、B通常为本地事务，C为分布式事务。业务微服务改造后，转入、转出通常为不同的微服务，同一个微服务也通常运行于不同实例中。A可能变成一个分布式事务，也可能通过一些方法规避，在本地事务内完成。B和C很难规避，只能是分布式事务。
微服务最佳实践建议尽量规避分布式事务，但是在很多业务场景（比如上面的B、C转账场景），分布式事务是一个绕不开的技术问题。
分布式事务常用解决方案为了解决分布式系统一致性问题，前人在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和算法。其中，最常用的是两阶提交协议（2 Phase Commitment Protocol）。
两阶段提交方案
交易中间件与数据库通过 XA 接口规范，使用两阶段提交来完成一个全局事务， XA 规范的基础是两阶段提交协议。
第一阶段是表决阶段，所有参与者都将本事务能否成功的信息反馈发给协调者；第二阶段是执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或者回滚。
两阶段提交方案应用非常广泛，典型商用软件包括Oracle Tuxedo和IBM CICS。它的优点是对业务代码侵入较低，但缺点也很明显：
性能低下：由于 XA 协议自身的特点，它会造成事务资源长时间得不到释放，锁定周期长，而且在应用层上面无法干预，数据并发冲突高的场景性能很差。
单点问题：协调者在整个两阶段提交过程中扮演着举足轻重的作用，一旦协调者所在服务器宕机，就会影响整个数据库集群的正常运行。比如在第二阶段中，如果协调者因为故障不能正常发送事务提交或回滚通知，那么参与者们将一直处于阻塞状态。
同步阻塞：两阶段提交执行过程中，所有的参与者都需要听从协调者的统一调度，期间处于阻塞状态而不能从事其他操作，效率及其低下。
因此，两阶段提交方案在互联网业务中很少使用，无法满足高并发需求。
为了这个弥补这种方案带来性能低的问题，大家又想出了很多种方案来解决，通过在应用层做文章，即入侵业务的方式，比较典型的是TCC 方案和基于可靠消息的最终一致性方案。
TCC事务方案
TCC事务模型在电商、金融领域落地较多。TCC方案其实是两阶段提交的一种改进。其将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备工作，confirm部分完成业务的提交，cancel部分完成事务的回滚。基本原理如下图所示。
事务开始时，业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的try接口，完成一阶段准备。之后事务协调器会根据try接口返回情况，决定调用confirm接口或者cancel接口。如果接口调用失败，会进行重试。
TCC方案让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能，比如华为分布式事务中间件DTM性能极高，普通配置服务器可以支持全局事务1万+ TPS，分支事务3万+ TPS。 当然TCC方案也有不足之处，集中表现在以下两个方面：
业务侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。
实现难度较大。为了满足一致性的要求，要充分考虑幂等操作，允许重复执行，也要防止资源悬挂，做好并发访问控制和数据可见性控制等。
上述原因导致TCC方案大多被研发实力较强、有迫切需求的大公司所采用。微服务倡导服务的轻量化，而TCC方案中很多事务的处理逻辑需要应用自己编码实现，复杂且开发量大。
基于消息的最终一致性方案