为什么需要分布式事务？

分布式事务不是在新架构下产生的新问题，即使在单体应用中同样存在着分布式事务问 题，典型的场景是单体应用执行方法中含有多个数据源。X/OPEN 对于这一问题，提出了 含有三种角色的 DTP(Distributed Transaction Processing)模型并形成了 XA 规范 来解决此问题。各厂商针对 XA 规范做了具体的实现，也就是大家常说的 XA 协议。在 Java 体系中基于 DTP 模型提出了 JTA 规范（参考 JSR 907）, 定义了分布式事务中 的事务管理器(TM)与资源管理器(RM)、应用程序(AP)等的 Java 接口。在 Java EE 时 代，应用服务器如 weblogic 充当了 TM 的角色，而传统关系数据库通过实现 XA 协议 充当了 RM 的角色。

随着互联网的高速发展，庞大的用户群体和快速的需求变化已经成为了传统架构的痛 点。在这种情况下，如何从系统架构的角度出发，构建出灵活、易扩展的系统来快速响应需 求的变化，同时，随着用户量的增加，如何保证系统的稳定性、高可用性、可伸缩性等等， 成为了系统架构面临的挑战。微服务基于此背景应运而生，微服务架构越来越来越成为一种 架构趋势，其本质是分布式去中心化。但微服务架构绝不是银弹，它不一定是一种能支撑未 来一二十年的架构，引入微服务架构时需要我们根据业务场景，系统复杂性和团队规模有步 骤的进行。微服务架构的引入使分布式数据一致性问题更为突出，由原来的单体应用拆分出 来几十甚至上百个微服务，如何保证服务间的一致性？当在一条较长的微服务调用链中，位 于中间位置的微服务节点出现异常，如何保证整个服务的数据一致性？

分布式一致性的引入，一定不可避免带来性能问题，如何更高效的解决分布式一致性问 题，一直是我们致力于解决此问题的关键出发点。在“一切都正常”的情况下，我们可以认 为我们并不需要分布式事务。但系统很难满足这种理想状态，系统可能因为一个非法的参数 校验无法将服务链路继续向下调用下去，系统可能出现令人反感的超时问题，我们不清楚被 调用的服务是否真正的执行了，被调用服务可能正在部署，网络抖动亦或者节点宕机导致接 口无法继续调用。这些问题普遍存在于我们的系统中，业务的本质体现在数据上，数据不一 致的直接后果是可能产生资损，更严重的是如果不一致的数据不能被及时发现，业务再次基 于此数据的进行相关逻辑操作，会进一步导致数据错上加错，最终很难溯源。