微服务架构下分布式事务解决方案 | 第一章 ： 分布式事务
- 微服务的发展
微服务倡导将复杂的单体应用拆分为若干个功能简单，松耦合的服务。这样可以降低开发难度、增强扩展性、便于敏捷开发，当前被越来越多的开发者推崇。很多互联网行业巨头、开源社区等都开始了微服务的讨论和实践。当前微服务的开发框架也非常多，比较著名的有Dubbo、SpringCloud、thrift 、grpc等。
- 微服务落地存在的问题
目前存在的主要困难有如下几方面：
- 单体应用拆分为分布式系统后，进程之间的通讯机制和故障处理措施变得更加复杂。
- 系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操纵多个数据库来实现，服务间的调用导致分布式事务问题变得非常突出。
- 微服务数量众多，其测试，部署，监控等都变得更加困难。
随着RPC框架的成熟，第一个问题已经逐步得到解决。例如Dubbo支持多种通讯协议，Spring Cloud下的Ribbon，Feign等很好的支持Restful调用。对于第三个问题，随着docker、devops技术的发展以及各公有云paas平台自动化运维工具的推出，微服务的测试、部署与运维会变得越来越容易。而对于第二个问题，现在还没有通用方案很好的解决微服务产生的事务问题。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。
- 分布式事务
- 数据库事务
数据库的事务介绍参见博客：事务及事务的隔离级别 - 分布式事务
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 - 分布式理论
CAP理论：
C: 一致性(Consistency)，在分布式系统中的所有数据备份，在同一时刻是否同样的值。
A: 可用性(Availability)，在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。
P: 分区容错性(Partition Tolerance)，以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
三者不可同时满足，而服务化中，更多的是提升A以及P，在这个过程中不可避免的会降低对C的要求。 -
分布式事务的解决方案
- 基于XA协议的两阶段提交方案
- TCC方案
- 基于消息的最终一致性方案
