Spring Cloud 分布式事务管理

在微服务如火如荼的状况下，愈来愈多的项目开始尝试改形成微服务架构，微服务即带来了项目开发的方便性，又提升了运维难度以及网络不可靠的几率.

 

在说微服务的优缺点时，有对比才会更加明显，首先说一下单体式结构

 

单体式架构

在单体式架构中，系统一般采用分层架构模式（MVC），持久化层、表示层，业务逻辑层。架构主要存在如下问题：

1. 系统内部互相访问，耦合紧密致使难以维护；
2. 各业务领域须要采用相同的技术栈，难以快速应用新技术（例如使用SSH很难向SSM改造）；
3. 对系统的任何修改都必须整个系统一块儿从新部署/升级；
4. 在系统负载增长时，难以进行水平扩展；
5. 当系统中一处出现问题，会影响整个系统；

为了克服以上缺点，微服务架构应运而生。微服务，又叫微服务架构。微服务就是一些协同工做的小而自治的服务.

微服务架构

优势:

1. 技术异构性

在不一样的服务中，可使用不一样的技术来各自开发，只要保证服务间能相互协做便可

2. 弹性

当微服务中的某一个服务不可用时，不会影响整个系统，只会影响相关功能不可用

3. 扩展

易于扩展，使用小的多个服务，更加易于扩展新的功能

4. 简化部署

某个服务的更新部署，不须要从新部署整个应用

5. 可组合

经过组合多个服务，能够提供一些新的功能

6. 可替代

由于每一个微服务都比较小，从新实现某一个服务或者直接删除该服务都是可操做的

缺点:

1. 复杂度高

微服务间经过REST、RPC等形式交互，相对于单体模式，须要考虑被调用方故障、过载、消息丢失等各类异常状况，代码逻辑更加复杂。

对于微服务间的事务性操做，由于不一样的微服务采用了不一样的数据库，将没法利用数据库自己的事务机制保证一致性，须要引入二阶段提交等技术。

同时，在微服务间存在少部分共用功能但又没法提取成微服务时，各个微服务对于这部分功能一般须要重复开发，或至少要作代码复制，以免微服务间的耦合，增长了开发成本。

2. 运维复杂

在采用微服务架构时，系统由多个独立运行的微服务构成，须要一个设计良好的监控系统对各个微服务的运行状态进行监控。运维人员须要对系统有细致的了解才对够更好的运维系统。

3. 影响性能

相对于单体架构，微服务的间经过REST、RPC等形式进行交互，通讯的时延会受到较大的影响。

 

分布式事务的引入

正如上面所说

 

对于微服务间的事务性操做，由于不一样的微服务采用了不一样的数据库，将没法利用数据库自己的事务机制保证一致性，须要引入二阶段提交等技术。

在单体项目中，很容易作到事务控制，而在多个服务之间很难实现

假设服务调用以下：

A B C D 的事务均在各个服务控制，如何作到，统一协调，保证数据的一致性？

分布式事务解决方案

基于XA协议的两阶段提交

XA是一个分布式事务协议，由提出。XA中大体分为两部分：事务管理器和本地资源管理器。其中本地资源管理器每每由数据库实现，好比Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器做为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理以下：
第一阶段：

 

第二阶段:

总的来讲，XA协议比较简单，并且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。可是，XA也有致命的缺点，那就是性能不理想，特别是在交易下单链路，每每并发量很高，XA没法知足高并发场景。XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回致使主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得很是狭隘。

消息事务+最终一致性

所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操做成功成功而且对外发消息成功，要么二者都失败，开源的RocketMQ就支持这一特性.

该方案采用最终一致的，牺牲了一致性，换来了性能的大幅度提高。存在形成数据不一致的风险

TCC编程模式

所谓的TCC编程模式，也是两阶段提交的一个变种。TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操做。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，若是更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是经过代码人为实现了两阶段提交，不一样的业务场景所写的代码都不同，复杂度也不同，所以，这种模式并不能很好地被复用。