CN108038141A - 微服务架构http交互模式下保证数据一致性的方法 - Google Patents

Abstract

本发明涉及微服务开发技术领域，特别是指一种微服务架构HTTP交互模式下保证数据一致性的方法。本发明首先主业务服务分别调用所有从业务服务的预操作，然后在活动管理器中记录所有从业务服务；如果所有从业务服务预操作成功或者某个从业务服务预操作失败，那么继续事务，否则执行事务停止执行；如果所有从业务服务都预操作成功，则协作者调用所有从业务服务的确认操作，如果确认操作失败，那么回滚所有确认操作，并执行从服务业务的取消操作。最后如果有部分从业务服务预操作失败，那么调用所有从业务服务的取消操作，直到取消成功为止。本发明解决了传统二阶段提交协议性能较差、不适用于微服务架构的问题；可实现业务服务上的三个简单语义的操作并进行调用。

Description

微服务架构HTTP交互模式下保证数据一致性的方法

技术领域

本发明涉及微服务开发技术领域，特别是指一种微服务架构HTTP交互模式下保证数据一致性的方法。

背景技术

随着微服务架构的推广，越来越多的企业采用微服务架构来构建自己的业务平台。微服务架构为业务开发带来了诸多好处的同时，例如单一职责、独立开发部署、功能复用和***容错等等；也带来一些问题，例如开发门槛较高，运维更复杂，模块之间的依赖关系更复杂，从而导致数据一致性难以保证。目前微服务架构下一般采用二阶段提交协议的方式来保证数据的强一致性，二阶段提交协议是一个分布式事务模型，此模型主要使用二阶段提交来保证分布式事务的完整性。在这个模型里面，有三个角色：

1、AP：Application，应用程序，业务层。

2、RM：Resource Manager，资源管理器，关系型数据库或支持XA接口的组件。

3、TM：Transaction Manager，事务管理器，负责各个RM的提交和回滚。

二段提交协议分为两个阶段：

1、TM通知所有参与事务的各个RM，给每个RM发送prepare消息。RM接收到消息后进入准备阶段后，要么直接返回失败，要么创建并执行本地事务，写本地事务日志(redo和undo日志)，但是不提交；

2、TM收到RM准备阶段的失败消息或者获取RM返回消息超时，则直接给RM发送回滚(rollback)消息，否则发送提交(commit)消息。RM根据TM的指令执行提交或者回滚，执行完成后释放所有事务处理过程中使用的锁。

上述方法实现了数据的强一致性，但是存在以下弊端：

1、TM通过XA接口与各个RM之间进行数据交互，从第1阶段开始，业务所涉及的数据就被锁定，并且锁定跨越整个提交流程。在高并发和涉及业务模块较多的情况下对数据库的性能影响较大；

2、微服务架构大多是使用HTTP协议进行组件之间的通信的，HTTP对于XA协议这种语义较为复杂的协议比较难以实现，因此，上述方法在微服务开发领域基本不适用。

因此，需要设计一种适用于微服务架构HTTP交互模式的高性能的保证数据一致性的方法。

发明内容

本发明解决的技术问题在于提出一种微服务架构HTTP交互模式下保证数据一致性的方法。

本发明解决上述技术问题的技术方案是：

所述的方法包括以下步骤：

步骤1：主业务服务调用所有从业务服务的预操作；

步骤2：在活动管理器中记录所有从业务服务；

步骤3：如果所有从业务服务预操作成功或者某个从业务服务预操作失败，那么执行步骤4，否则执行事务停止执行；

步骤4：如果所有从业务服务都预操作成功，则协作者调用所有从业务服务的确认操作，如果确认操作失败，那么回滚所有确认操作，并执行从服务业务的取消操作；

步骤5：如果有部分从业务服务预操作失败，那么调用所有从业务服务的取消操作，如果取消操作失败，那么在从业务服务本地提供自动化的机制来执行取消操作，直到取消成功为止；即从业务服务本地执行可自动重试的程序执行取消操作，比如定时任务等。

所述主业务服务指的是整个业务活动的发起方，包括支付场景下的支付***；

所述从业务服务指的是整个业务活动的操作方；从业务服务必须实现预操作、确认和取消三个接口，供主业务服务调用。

所述活动管理器管理控制整个业务活动，包括记录维护全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时确认所有的确认操作，在业务活动取消时调用所有取消操作。

所述预操作是尝试执行业务，具体包括完成所有业务检查以及预留必须业务资源；

确认是确认执行业务，是真正执行业务操作的地方，确认阶段不做任何业务检查，只使用预操作阶段预留的业务资源；

取消是取消执行业务，具体是指释放预操作阶段预留的业务资源。

本发明的方法能产生如下的有益效果：

1、本发明的方法不需要长时间锁定数据库，甚至都不需要数据库服务随时在线，因此具有性能上的优势。

2、本发明的方法定义的接口语义与HTTP交互模式的操作语义较为接近，因此，比较适于在微服务领域使用。

附图说明

下面结合附图对本发明进一步说明：

图1为本发明的流程图；

图2为本发明的其中一种实现方式的序列图。

具体实施方式

见图1所示，本发明的基本步骤如下：

步骤1：主业务服务调用所有从业务服务的预操作；

步骤2：在活动管理器中记录所有从业务服务；

步骤3：如果所有从业务服务预操作成功或者某个从业务服务预操作失败，那么执行步骤4，否则执行事务停止执行；

步骤4：如果所有从业务服务都预操作成功，则协作者调用所有从业务服务的确认操作，如果确认操作失败，那么回滚所有确认操作，并执行从服务业务的取消操作；

步骤5：如果有部分从业务服务预操作失败，那么调用所有从业务服务的取消操作，如果取消操作失败，那么在从业务服务本地提供自动化的机制来执行取消操作，直到取消成功为止；即从业务服务本地执行可自动重试的程序执行取消操作，比如定时任务等。

下面以HTTP的处理流程为例，讲述其中一种实现方式的处理过程。如图2所示，分别在从业务1和从业务2中实现了三种接口try、confirm、cancel分别表示预操作、确认和取消。具体处理流程如下：

1.主业务服务调用从业务服务的try操作，并获取confirm/cancel接口和超时时间。

2.如果从业务都try成功，主业务服务执行本地业务，并将获取的confirm/cancel接口发送给活动管理器，活动管理器会顺序调用从业务1和从业务2的confirm接口并记录请求状态，如果请求成功，则通知主业务服务提交本地事务。如果confirm部分失败，则活动管理器会顺序调用从业务1和从业务2的cancel接口来取消try的操作。

3.如果从业务部分或全部try失败，则主业务直接回滚并结束，而try成功的从业务服务则通过定时任务来处理处于try完成但超时的数据，将这些数据做回滚处理保证主业务服务和从业务服务的数据一致。

Claims (5)

1.一种微服务架构HTTP交互模式下保证数据一致性的方法，其特征在于，所述的方法包括以下步骤：

步骤1：主业务服务调用所有从业务服务的预操作；

步骤2：在活动管理器中记录所有从业务服务；

步骤3：如果所有从业务服务预操作成功或者某个从业务服务预操作失败，那么执行步骤4，否则执行事务停止执行；

步骤4：如果所有从业务服务都预操作成功，则协作者调用所有从业务服务的确认操作，如果确认操作失败，那么回滚所有确认操作，并执行从服务业务的取消操作；

步骤5：如果有部分从业务服务预操作失败，那么调用所有从业务服务的取消操作，如果取消操作失败，那么在从业务服务本地提供自动化的机制来执行取消操作，直到取消成功为止；即从业务服务本地执行可自动重试的程序执行取消操作。

2.根据权利要求1所述的方法，其特征在于，

所述主业务服务指的是整个业务活动的发起方，包括支付场景下的支付***；

所述从业务服务是整个业务活动的操作方；从业务服务必须实现预操作、确认和取消三个接口，供主业务服务调用。

3.根据权利要求1所述的方法，其特征在于，所述活动管理器管理控制整个业务活动，包括记录维护全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时确认所有的确认操作，在业务活动取消时调用所有取消操作。

4.根据权利要求2所述的方法，其特征在于，所述活动管理器管理控制整个业务活动，包括记录维护全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时确认所有的确认操作，在业务活动取消时调用所有取消操作。

5.根据权利要求1至4任一项所述的方法，其特征在于，

所述预操作是尝试执行业务，具体包括完成所有业务检查以及预留必须业务资源；

确认是确认执行业务，是真正执行业务操作的地方，确认阶段不做任何业务检查，只使用预操作阶段预留的业务资源；

取消是取消执行业务，具体是指释放预操作阶段预留的业务资源。