一种微服务架构中分布式事务的处理方法技术

本发明专利技术涉及一种微服务架构中分布式事务的处理方法，其包括：开启DB实例的单机事务；执行DB请求，更新DB；请求实时事务模块；对实时事务模块是否请求成功进行判断，如果未请求成功，则触发回滚，抛出异常或其他DB驱动的事务回滚触发事件；如果请求成功，则进行提交。本发明专利技术有效地利用了DB驱动模块的单机两阶段提交特性，创新地提出了一种利用服务调用的拓扑结构来实现分布式事务的方式，可以用作实时一致性的解决方案，也可以实现最终一致性事务。本发明专利技术只通过一次交互过程就可以实现事务保证，非常适合三个以内的分布式模块实现事务机制。本发明专利技术能够通过拓扑设计明确地表示分布式事务的处理级别，串联即是实时一致，并联即是最终一致。

Method for processing distributed transaction in micro service architecture

The invention relates to a processing method, a micro service architecture of distributed transaction includes open instances of DB single transaction; perform DB requests, update the DB request; real-time transaction module; the real-time transaction module to judge whether to request success, if not request success is triggering rollback transaction rollback exception thrown or other DB drive the trigger event; if the request is submitted successfully. The invention effectively utilizes single DB driver module two phase commit characteristics, proposes a topology based service call to realize the distributed transaction mode, can be used as a solution for real-time consistency, can also realize transactional consistency. The invention can realize transaction guarantee through only one interaction process, and is suitable for the distributed module within three or less to realize transaction mechanism. The invention can explicitly represent the processing level of the distributed transaction through the topological design, and the series connection is in real-time agreement, and the parallel connection is the final agreement.

【技术实现步骤摘要】
一种微服务架构中分布式事务的处理方法
本专利技术属于计算机领域，具体涉及一种微服务架构中分布式事务的处理方法。
技术介绍
微服务是近年来兴起的一项新的架构设计思想。相较SOA，微服务通过将功能进一步分布式组件化，具有良好的扩展性和可持续开发能力。微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务。微服务的目的是有效的拆分应用，实现敏捷开发和部署。如果说SOA可以通过设计避免分布式事务问题，由于服务拆分粒度更细，与SOA不同的是，微服务对于分布式事务的要求变得不可或缺。比如一个在线支付过程，SOA可能会拆分出一个封装了支付功能、自行维护库存的订单子系统，将更新商品数量、修改订单状态、记录支付费用等操作用单机事务完成。但是对于微服务架构来说，很可能由于扩展性的考虑，拆分成支付模块、订单模块、商品SKU管理模块。当支付成功的通知到来时，需要实时更新多个模块的DB数据。
技术实现思路
为了解决现有技术存在的上述问题，本专利技术提供了一种微服务架构中分布式事务的处理方法。本专利技术所采用的技术方案为：一种微服务架构中分布式事务的处理方法，其包括以下步骤：开启DB实例的单机事务；执行DB请求，更新DB；请求实时事务模块；对实时事务模块是否请求成功进行判断，如果未请求成功，则触发回滚，抛出异常或其他DB驱动的事务回滚触发事件；如果请求成功，则进行提交。进一步地，所述请求实时事务模块的步骤中，至多进行一个实时事务模块调用，如果有多个实时事务模块，则进行串联调用。进一步地，所述对实时事务模块是否请求成功进行判断的步骤中，如果请求成功，在进行提交之前，还包括插入最终一致性处理模块的步骤。进一步地，所述对实时事务模块是否请求成功进行判断的步骤中，如果请求成功，在进行提交之前，还包括插入最终一致性处理模块的步骤。进一步地，所述分布式事务的处理方法采用模块调用的拓扑结构来处理分布式事务。更进一步地，所述采用模块调用的拓扑结构来处理分布式事务核心设计规则包括：一个模块至多有一次修改类型的RPC调用，修改类型的RPC调用无需提供回滚接口。更进一步地，如果单流程有多次修改类型的RPC调用，同时又要保证整体的实时一致性，需将RPC调用串联。更进一步地，所述采用模块调用的拓扑结构来处理分布式事务核心设计规则还包括：RPC接口调用封装在DB事务处理逻辑内部，放在DB事务后面。更进一步地，所述RPC接口调用失败或返回失败后，抛出异常触发DB事务回滚。更进一步地，如果流程中的RPC调用接受最终一致，则能够插入队列，但是必须放在所有调用流程结束之后。由于采用以上技术方案，本专利技术的有益效果为：本专利技术有效地利用了DB驱动模块的单机两阶段提交特性，创新地提出了一种利用服务调用的拓扑结构来实现分布式事务的方式，可以用作实时一致性的解决方案。同时，该方案有很好的延展性，通过另一种拓扑结构，也可以实现最终一致性事务。本专利技术只通过一次交互过程就可以实现事务保证，非常适合三个以内的分布式模块实现事务机制。本专利技术能够通过拓扑设计明确地表示分布式事务的处理级别，串联即是实时一致，并联即是最终一致。附图说明为了更清楚地说明本专利技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本专利技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1是典型的服务调用拓扑结构示意图；图2是本专利技术微服务架构中分布式事务的处理方法的流程图；图3是各分布式事务模块的指令执行顺序示意图。具体实施方式为使本专利技术的目的、技术方案和优点更加清楚，下面将对本专利技术的技术方案进行详细的描述。显然，所描述的实施例仅仅是本专利技术一部分实施例，而不是全部的实施例。基于本专利技术中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施方式，都属于本专利技术所保护的范围。目前微服务架构作为一种新的设计方式在世界范围内已被广泛应用。但是其难点之一，便是分布式部署导致的事务问题。分布式事务处理涉及多个分布在不同地方的数据库，但对数据库的操作必须全部被提交或者回滚。只要任一数据库操作时失败，所有参与事务的数据库都需要回滚。分布式事务可以分为实时一致和最终一致。目前业界通用的实时一致性解决方案有基于两阶段提交或三阶段提交的方案。两阶段提交的实现比如Atomikos库(实现了JTA)、JOTM、LIXA。两阶段提交方案在实际中应用比较广。但是分布式场景与单机场景不同，处理时间翻倍，原本一次交互过程被划分为prepare和commit两次交互，性能差而且有缺点：协调者宕机情况下会导致参与者同步阻塞，需增加协调者热备且记录undo和redo日志。当协调者和参与者同时宕机时，问题无解。以分布式两阶段提交为例，收到一个事务请求后，协调者发起第一次协调请求prepare，要求全部参与者预执行对应的语句。当全部反馈成功时，协调者将发起commit请求，要求全部参与者提交事务。当两步都完成后，事务处理完成。当第一步有参与方反馈失败时，协调者发起rollback请求，要求全部参与者回滚事务。为了解决两阶段提交的问题，XA提出了三阶段提交方案。其中，XA是X/OpenDTP定义的事务管理器与数据库之间的接口规范(即接口函数)。三阶段提交通过增加一次canPrepare，并且增加超时来解决两阶段提交的阻塞问题，但是三阶段提交方案的交互性能更差。目前最终一致性的解决方案的主流实现方式是基于可重试的消息队列，消费者将定期重试直至所有参与方的系统最终实现数据一致。如图1所示，本专利技术提供了一种微服务架构中分布式事务的处理方法，其采用模块调用的拓扑结构来处理分布式事务，其具体包括以下步骤：1)开启DB(DataBase，数据库)实例的单机事务。2)执行DB请求，更新DB。3)请求实时事务模块。4)对步骤3)是否请求成功进行判断，如果未请求成功，则触发回滚，抛出异常或其他DB驱动的事务回滚触发事件；如果请求成功，则进行提交。上述步骤3)中，至多进行一个实时事务模块调用，如果有多个实时事务模块，则进行串联调用。上述步骤4)中，如果请求成功，在进行提交之前，还包括插入最终一致性处理模块的步骤。用拓扑方式解决分布式事务问题的核心设计规则为：(1)一个模块至多有一次修改类型的RPC(RemoteProcedureCallProtocol，远程过程调用协议)调用。修改类型的RPC调用无需提供回滚接口。(2)如果单流程有多次修改类型的RPC调用，同时又要保证整体的实时一致性，需将RPC调用串联。(3)RPC接口调用封装在DB事务处理逻辑内部，放在DB事务后面。(4)RPC接口调用失败或返回失败后，抛出异常触发DB事务回滚。(5)如果流程中的某些RPC调用可以接受最终一致(比如结算对账等后台模块)，可以插入队列。但是必须放在所有调用流程结束之后。下面举例本文档来自技高网...

【技术保护点】
一种微服务架构中分布式事务的处理方法，其特征在于，它包括以下步骤：开启DB实例的单机事务；执行DB请求，更新DB；请求实时事务模块；对实时事务模块是否请求成功进行判断，如果未请求成功，则触发回滚，抛出异常或其他DB驱动的事务回滚触发事件；如果请求成功，则进行提交。

【技术特征摘要】
1.一种微服务架构中分布式事务的处理方法，其特征在于，它包括以下步骤：开启DB实例的单机事务；执行DB请求，更新DB；请求实时事务模块；对实时事务模块是否请求成功进行判断，如果未请求成功，则触发回滚，抛出异常或其他DB驱动的事务回滚触发事件；如果请求成功，则进行提交。2.如权利要求1所述的一种微服务架构中分布式事务的处理方法，其特征在于，所述请求实时事务模块的步骤中，至多进行一个实时事务模块调用，如果有多个实时事务模块，则进行串联调用。3.如权利要求1所述的一种微服务架构中分布式事务的处理方法，其特征在于，所述对实时事务模块是否请求成功进行判断的步骤中，如果请求成功，在进行提交之前，还包括插入最终一致性处理模块的步骤。4.如权利要求2所述的一种微服务架构中分布式事务的处理方法，其特征在于，所述对实时事务模块是否请求成功进行判断的步骤中，如果请求成功，在进行提交之前，还包括插入最终一致性处理模块的步骤。5.如权利要求1或2或3或4所述的一种微服务架构中分布式事务的处理方法，其特征在于，所述分布式事...

【专利技术属性】
技术研发人员：秦光跃，
申请(专利权)人：西多多信息科技北京有限公司，
类型：发明
国别省市：北京,11