现在提起分布式事务中的“事务”，和传统的数据库事务中的“事务”严格意义上已经不是完全等同的了。
设计一个分布式事务框架前，首先要明确问题到定义。
分析具体应用场景，包括以下三个：A、服务内跨数据库的事务；B、跨内部服务的事务；C、跨外部服务的事务。
其中划分内部和外部的标准是：内部服务我们可以控制其实现，修改配置或代码；外部服务指的是第三方的，只能约定通信的方式和具体协议，具体代码实现在控制范围之外。
具体如下：
应用场景A：服务内跨数据库
如下图所示，在同一个服务方法内，访问两个或两个以上数据库。
我们知道，Java事务是通过Connection对象控制的。不同的数据库，是不同的数据库链接，通过不同的Connection对象实现。传统数据库事务无法实现事务控制，需要引入事务协调者的概念。这是场景A，这个场景中分布式体现在数据库的部署上。
应用场景B：跨内部服务
如下图所示，一个服务通过微服务框架或者RPC调用调用其他的服务，多个子服务需要同时成功或失败。每个子服务都有自己的持久化方式，不一定是数据库，体现事务的持久性。每个子服务部署在不同的服务容器中，不同的服务容器部署在不同的服务器节点上。这是场景B，这个场景中分布式体现在服务（或应用）的部署上。
这时候，事务的概念已经超出“数据库”的范畴了。
应用场景C：跨外部服务
这个场景是在应用场景B的基础上，进一步，服务的具体实现在我们控制范围之外。我们不能限制其实现语言，不能要求指定方法上加标注（注解）。甚至除了服务调用的网络通道外，我们不能期望服务间访问相同的Zookeeper作为事务协调器。这是场景C，这个场景中，我们只能在通信协议层面做约定，是最彻底的分布式场景。
小结
以上分析了分布式事务的三个应用场景，具体的技术方案也针对这三个场景做设计。
