微服务架构分布式事务处理方案（一）

一、 传统的分布式事务和微服务架构分布式事务比较，分析

　　传统应用使用本地事务和分布式事务保证数据一致性，但是在微服务架构中数据都是服务私有的，需要通过服务提供的API来访问，所以分布式事务不再适用微服务架构。那么微服务架构又该如何保证数据一致性呢？本文就来谈谈这个话题。

1.　传统分布式事务

　　传统使用本地事务和分布式事务保证一致性

---

• 　　传统单机应用一般都会使用一个关系型数据库， 好处是应用可以使用ACID。为保证一致性我们只需要：开始一个事务，改变（插入，删除，更新）很多行，然后提交事务（如果有异常时回滚事务）。更进一步，借助开发平台中的数据访问技术和框架（如 Spring），我们需要做的事情更少， 只需要关注数据本身的改变。

• 　　随着组织规模不断扩大，业务量不断增长，单机应用和数据库已经不足以支持庞大的业务量和数据量，这个时候需要对应用和数据库进行拆分，这就出现了一个应用需要同时访问两个或两个以上的数据库情况。开始我们用分布式事务来保证一致性，也就是我们常说的两阶段提交协议（2PC）。

  
  　　

• 分布式事务解决方案的利弊
  优点：严格的ACID
  缺点：效率非常低（微服务架构下已不太适用）
  　　1.全局事务方式下，全局事务管理器（TM）通过XA接口使用二阶段提交协议（ 2PC ）与资源层（如数据库）进行交互。使用全局事务，数据被Lock的时间跨整个事务，直到全局事务结束。
  　　2.2PC 是反可伸缩模式，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样，当业务规模越来越大的情况下，2PC 的局限性就越来越明显，系统可伸缩性会变得很差。
  　　3. 与本地事务相比，XA 协议的系统开销相当大，因而应当慎重考虑是否确实需要分布式事务。而且只有支持 XA 协议的资源才能参与分布式事务。
  　　本地事务和分布式事务现在已经非常成熟，相关介绍很丰富，此处不再讨论。我们下面来谈谈为什么分布式事务不适用于微服务架构。

2. 微服务架构事务

1. 　　首先，对于微服务架构来说，数据访问变得更加复杂，这是因为数据都是微服务私有的，唯一可访问的方式就是通过 API。这种打包数据访问方式使得微服务之间松耦合，并且彼此之间独立，更容易进行性能扩展。

　　其次，不同的微服务经常使用不同的数据库。应用会产生各种不同类型的数据，关系型数据库并不一定是最佳选择。

　　例如，某个产生和查询字符串的应用采用 Elasticsearch 的字符搜索引擎；某个产生社交图片数据的应用可以采用图数据库，例如Neo4j。

　　基于微服务的应用一般都使用 SQL 和 NoSQL 结合的模式。但是这些非关系型数据大多数并不支持 2PC。

　　可见在微服务架构中已经不能选择分布式事务了。那么，微服务架构事务怎么处理呢？ 众所周知，事务处理方案基于CAP理论。

3. 最终一致性原则

　　依据 CAP 理论，必须在可用性（availability）和一致性（consistency）之间做出选择。如果选择提供一致性需要付出在满足一致性之前阻塞其他并发访问的代价。这可能持续一个不确定的时间，尤其是在系统已经表现出高延迟时或者网络故障导致失去连接时。所以，在服务和数据库之间维护数据一致性是非常根本的需求，微服务架构中应选择满足最终一致性。