浪潮inBuilder低代码平台的分布式微服务架构事务一致性解决方案

技术背景

在分布式系统中，随着应用的微服务化拆分，业务数据的存储模式由单机数据库架构向分布式数据库架构转变，各个微服务之间通过远程REST或RPC请求完成业务操作，产生了跨服务的分布式事务问题，需要解决一个服务调用中多个事务的数据一致性。
根据CAP原则，分布式系统只能同时满足（强）一致性（Constistency）、可用性（Avaliablility）和分区容错性（Partition tolerance）中的两项，而一个稳定可用的分布式业务系统，必须同时满足A与P两者，需要牺牲数据强一致性C，转而追求数据的最终一致性，满足BASE理论的三大特性：基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventual Consistency）。

业界主流技术方案对比

1) XA事务模式：

XA是由Tuxedo首先提出，属于X/Open组织的分布式事务协议，XA事务在数据库层面提供了对强一致、中心化的原子提交协议——两阶段提交协议（2PC）的支持，可实现分布式事务中数据的强一致性，但牺牲了系统的可用性，降低了系统的吞吐量。
2) 可靠消息队列事务模式：
可靠消息队列事务模式，是当本地事务发起方执行完成本地事务后，发出一条消息，通过消息中间件、事务日志表、重试等机制来保障事务参与方（消息消费者）一定能够接收消息并成功处理事务的分布式事务解决方案，此方案牺牲了事务数据的隔离性，保证了系统的可用性，是一种最终一致性事务解决方案。
3) TCC（Try-Confirm-Cancel）事务模式：
TCC事务模式在应用层面提供了对两阶段提交协议的支持，将业务操作拆分为Try（预留资源）-Confirm（确认提交资源）-Cancel（回滚资源）三个方法满足分布式事务的两阶段提交行为，需要一个中心化的事务协调器驱动各个事务参与者提交/回滚，在TCC事务模式中，若所有事务参与者Try操作均成功，则由事务协调器通知所有事务参与者执行Confirm操作，反之，由事务协调器通知所有参与者执行Cancel操作，TCC可以通过Try操作实现业务层面的事务数据隔离，是一种最终一致性事务解决方案。
4) Saga事务模式：
Saga事务模式是一种基于数据补偿来代替回滚的分布式事务解决方案，要求分布式事务中的所有业务操作都实现一个补偿操作，当某一个事务参与者失败时，由事务协调者通知已执行的事务参与者执行补偿操作，Saga模式无法保障事务数据的隔离性，是一种最终一致性的柔性事务解决方案。
5) TCC-AT事务模式：
TCC-AT（Automatic Transactiona）是一种基于“自动回滚”的思想来实现无侵入式分布式事务的分布式事务解决方案，它通过对特定关系型数据库语句进行SQL解析，得到事务执行对应的反向回滚SQL并记录日志，当事务参与者发生异常时，根据反向SQL日志实现业务数据的回滚，此方案存在仅适用于关系型数据库，需适配多种数据库类型的，存在全局锁，无法支持存储过程等无法反向解析的SQL语法等问题。
综上，对几种分布式事务方案对比，得出以下结论：

浪潮inBuilder低代码平台分布式一致性技术方案

在浪潮inBuilder低代码平台的技术选型设计过程中，在参考上述业界分布式事务解决方案基础上，结合企业级复杂应用系统的数据关系复杂性高、业务规则密集、应用规模庞大等实际应用场景需求，基于TCC模式提出了一种新的综合技术方案，在满足最终一致性、普适性、性能及事务数据隔离需求的同时，对于简单场景也提供一种基于自动化模式的解决方案，最大程度降低开发成本，提升分布式事务开发效率，做到了鱼与熊掌兼得。其具备以下特性：

1) 良好的普适性
支持SQL/NoSQL多种事务资源
支持长/短事务多种场景
同一分布式事务支持自动模式与手工模式混合使用
2) 低开发成本
无侵入式开发
提供自动事务模式
支持自动锁定
与低代码平台内置集成
3) 高可靠性
支持资源预留和锁，实现业务隔离性
支持自动回滚
支持自动防悬挂
支持自动重试机制
兼容空回滚/空提交
支持框架级幂等控制
4) 高性能
支持多隔离级别设置
分布式日志
内存、数据库两阶段增量提交
5) 高效运维
提供事务运维管理工具
提供事务状态监控
提供事务调用链路查看

若想了解更多关于inBuilder低代码平台的更多相关内容，可点击inBuilder社区版网址下载安装inBuilder低代码平台社区版