SOA架构下事务的实现方法和装置与流程

本申请涉及数据处理技术领域，尤其涉及一种SOA架构下事务的实现方法和装置。

背景技术：

SOA(Service-Oriented Architecture，面向服务的体系结构)是一种新的服务架构，它是一种粗粒度、松耦合的服务架构，服务之间通过接口进行通讯，不涉及底层编程接口和通讯模型。较之以往，SOA架构的系统能够更加从容地面对业务的急剧变化。

相关技术中，在SOA架构的系统中，通常采用分布式事务的实现方案，分布式事务的实现过程一般包括两个阶段，第一个阶段是准备阶段，第二个阶段是提交阶段。任意一个阶段中，只要有服务发生调用失败，那么就会导致全局所有服务的回滚，影响用户的使用体验。

技术实现要素：

有鉴于此，本申请提供一种SOA架构下事务的实现方法和装置。

具体地，本申请是通过如下技术方案实现的：

一种SOA架构下事务的实现方法，所述方法包括：

当调用方调用与全局事务相关的服务时，获取与所述服务对应的调用上下文，所述服务包括关键服务和非关键服务；

当非关键服务调用失败时，将该失败的非关键服务的调用上下文保存到补偿任务表中；

当关键服务均调用成功时，向所述调用方返回调用成功的消息；

按照预设的时间周期轮询所述补偿任务表，根据所述补偿任务表中保存的调用上下文重新调用所述失败的非关键服务。

一种SOA架构下事务的实现方法，所述方法包括：

当调用方调用与全局事务相关的服务时，获取与所述服务对应的调用上下文；

当服务调用失败时，将失败服务的调用上下文保存到补偿任务表中；

向所述调用方返回调用成功的消息；

按照预设的时间周期轮询所述补偿任务表，根据所述补偿任务表中保存的调用上下文重新调用失败服务。

一种SOA架构下事务的实现装置，所述装置包括：

第一获取单元，当调用方调用与全局事务相关的服务时，获取与所述服务对应的调用上下文，所述服务包括关键服务和非关键服务；

第一保存单元，当非关键服务调用失败时，将该失败的非关键服务的调用上下文保存到补偿任务表中；

第一返回单元，当关键服务均调用成功时，向所述调用方返回调用成功的消息；

第一调用单元，按照预设的时间周期轮询所述补偿任务表，根据所述补偿任务表中保存的调用上下文重新调用所述失败的非关键服务。

一种SOA架构下事务的实现装置，所述装置包括：

第二获取单元，当调用方调用与全局事务相关的服务时，获取与所述服务对应的调用上下文；

第二保存单元，当服务调用失败时，将失败服务的调用上下文保存到补偿任务表中；

第二返回单元，向所述调用方返回调用成功的消息；

第二调用单元，按照预设的时间周期轮询所述补偿任务表，根据所述补偿任务表中保存的调用上下文重新调用失败服务。

由以上描述可以看出，本申请可以在非关键服务调用失败时，将该失败的非关键服务的调用上下文保存到补偿任务表中，并在关键服务均调用成功时，向调用方返回调用成功的消息，并通过后续的重新调用操作确保失败的非关键服务能够成功调用，从而确保全局事务的实现，提升用户的使用体验。

附图说明

图1是本申请一示例性实施例示出的一种SOA架构下事务的实现方法的流程示意图。

图2是本申请一示例性实施例示出的一种将失败服务的调用上下文保存到补偿任务表中的流程示意图。

图3是本申请一示例性实施例示出的一种用于SOA架构下事务的实现装置一结构示意图。

图4是本申请一示例性实施例示出的一种SOA架构下事务的实现装置的框图。

图5是本申请一示例性实施例示出的另一种SOA架构下事务的实现装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

相关技术中，局部事事务通常是指仅调用一个服务的事务，而全局事务通常是指需要调用多个服务的事务，比如：全局事务可能需要调用多个数据库、也可能需要调用多个服务进程等。针对全局事务，通常采用分布式事务处理(Distributed Transaction Processing，DTP)的方式。

目前，分布式事务处理通常遵循XA规范，XA规范定义了分布式事务处理的两个阶段。第一个阶段是准备提交阶段，用以确认是否所有相关的服务都可以提交各自的事务分支。调用方可以通过全局事务管理器调用与全局事务相关的各服务，某个服务如果确认能够提交属于自己的事务分支，则可以向全局事务管理器返回准备提交成功的应答，但此时，该服务并没有真正提交其事务分支。如果某个服务确认无法提交属于自己的事务分支，则会进行回滚操作，并向全局事务管理器返回准备提交失败的应答。第二个阶段是正式提交阶段，全局事务管理器在接收到所有服务返回的准备提交成功的应答后，可以通知所有服务进行正式提交，以完成全局事务的提交，并向调用方返回全局事务调用成功的消息。如果接收到任一服务返回准备提交失败的应答，则会通知其他所有服务进行回滚操作，这样该全局事务被回滚，并向调用方返回调用失败的消息。

然而，在这样的实现方式中，全局事务的实现依赖所有相关服务的成功调用，只要有服务发生调用失败，那么就会导致全局所有服务的回滚，严重影响用户的使用体验。

针对上述问题，本申请提供一种SOA架构下事务的实现方法和装置。

请参考图1，图1是本申请一示例性实施例示出的一种SOA架构下事务的实现方法的流程示意图，所述SOA架构下事务的实现方法应用在服务端，可以包括以下步骤：

步骤101，当调用方调用与全局事务相关的服务时，获取与所述服务对应的调用上下文，所述服务包括关键服务和非关键服务。

在本实施例中，所述调用方通常为服务提供商开发的APP(Application，应用程序)，用户可以通过APP实现各种业务操作，比如：以具有支付功能的APP为例，用户可以通过APP发起转账请求，又比如：用户可以通过APP提供的充值入口为手机充话费等。

在本实施例中，服务端在接收到用户通过APP发起业务请求时，视为接收到针对事务的调用指令，服务端在接收到所述调用指令后，可以根据业务请求的类型确认本次发起的事务是全局事务还是局部事务。当本次发起的事务为需要调用多个服务的全局事务时，服务端可以通过XA接口函数通知各服务开始本地事务，使得APP可以对各服务进行调用。其中，所述服务可以包括：数据库系统、业务服务进程等，本申请对此不作特殊限制。

在本实施例中，所述服务可以分为关键服务和非关键服务，开发人员可以根据全局事务所属的具体应用场景将与该全局事务相关的所有服务分为关键服务和非关键服务两类。其中，关键服务通常是全局事务所属应用场景中对本地事务成功实现即时性要求较高的服务，非关键服务通常是全局事务所属应用场景中对本地事务成功实现即时性要求较低的服务。在不同的应用场景中，同一个服务的类型可能相同，也可能不同。

在本实施例中，服务端可以获取APP对各服务进行调用的调用上下文，然后缓存获取到的调用上下文，比如：缓存到内存中指定的位置。

在本实施例中，各服务在执行APP的调用后，会将调用结果返回给服务端，所述调用结果包括：调用成功和调用失败。服务端在接收到与全局事务相关的所有关键服务均返回的调用成功的消息时，可以执行步骤103。当服务端接收到某个非关键服务返回的调用失败的消息后，可以执行步骤102。

步骤102，当非关键服务调用失败时，将该失败的非关键服务的调用上下文保存到补偿任务表中。

在本实施例中，当与全局事务相关的一个或者多个非关键服务调用失败时，可以将该失败的非关键服务的调用上下文均保存到补偿任务表中。比如：从缓存中读取所述失败的非关键服务的调用上下文，并将所述调用上下文保存到所述补偿任务表中。其中，所述调用上下文包括有调用所述失败的非关键服务所需的参数，比如：转账金额、转账时间等。在本步骤中，服务端还可以删除缓存中缓存的调用成功服务的调用上下文，本申请在此不再一一赘述。

步骤103，当关键服务均调用成功时，向所述调用方返回调用成功的消息。

基于前述步骤101，当与全局事务相关的所有关键服务全部返回调用成功的消息时，服务端可以向调用方返回调用成功的消息，比如：向发起业务请求的APP返回业务执行成功的消息。其中，当与全局事务相关的所有服务中仅有一个关键服务时，在接收到该关键服务返回调用成功的消息时，可以向调用方返回调用成功的消息。当与全局事务相关的所有服务中有多个关键服务时，在接收到全部关键服务返回的调用成功的消息时，向调用方返回调用成功的消息。

步骤104，按照预设的时间周期轮询所述补偿任务表，根据所述补偿任务表中保存的调用上下文重新调用所述失败的非关键服务。

在本实施例中，服务端可以按照预设的时间周期轮询所述补偿任务表，根据所述补偿任务表中记录的调用上下文重新调用失败的非关键服务。其中，所述预设的时间周期可以由开发人员进行设置，比如：5秒一个时间周期等，本申请对此不作特殊限制。

在本实施例中，当重新调用失败的非关键服务成功时，可以删除所述补偿任务表中所述失败的非关键服务的调用上下文。当调用失败的非关键服务再次失败时，无需删除所述补偿任务表中所述失败的非关键服务的调用上下文。在到达下一个轮询的时间周期时，重新根据所述补偿任务表中保存的调用上下文调用该失败的非关键服务，直至所有失败的非关键服务全部调用成功。

由以上描述可以看出，本申请在实现全局事务时，当与全局事务相关的非关键服务调用失败时，可以将失败的非关键服务的调用上下文保存到补偿任务表中，并向调用方返回调用成功的消息，后续可以按照预设的时间周期轮询所述补偿任务表，根据所述补偿任务表中保存的调用上下文重新调用失败的非关键服务，直到失败的非关键服务调用成功。通过本申请的技术方案，当与全局事务相关的非关键服务调用失败时，无需进行全局的回滚操作，向调用方返回调用成功的消息，提升了用户的使用体验，本申请可以通过后续的重新调用操作确保失败的非关键服务能够成功调用，从而确保全局事务的实现。同时，采用本申请提供的技术方案，调用方无需关心各服务是否正常，发起调用即可，大大减少了调用失败所导致的后续处理流程，节省了终端的处理资源。对于服务提供方而言，当其他服务调用失败时，本服务无需进行回滚操作，也节省了相关设备的处理资源。

可选的，在本申请一个例子中，请参考图2，当非关键服务调用失败时，将失败的非关键服务的调用上下文保存到补偿任务表中，可以包括以下步骤：

步骤201，当服务调用失败时，判断失败服务是否为全局事务所属应用场景的非关键服务。当所有失败服务均为全局事务所属应用场景的非关键服务时，可以执行步骤202。

基于图1所示实施例中步骤101的调用结果，当与全局事务相关的某个服务返回调用失败的消息时，可以先判断失败服务是否为全局事务所属应用场景的非关键服务。

举例来说，假设某全局事务为转账事务，在转账场景中，与转账事务相关的所有服务中，存储账户余额的数据库系统是关键服务，用于通知转账成功的通知服务进程是非关键服务，用于将转账双方互加为好友的好友关系维护进程也是非关键服务。当用户发起一笔转账请求时，对于用户而言，转账成功的必要条件是账户余额的成功变动，因此，需要确保关键服务存储账户余额的数据库能够成功调用。而转账成功的通知消息如果有一些延迟，或后续再将对方添加为自己的好友，对用户而言都是可以接受的，因此，在转账场景中，所述通知服务进程和所述好友关系维护进程都是非关键服务。

再举个例子，假设某全局事务为好友添加事务，在添加好友的场景中，好友关系维护进程是关键服务，用于通知好友添加成功的通知服务进程是非关键服务。当用户发起一个好友添加请求时，对于用户而言，添加成功的必要条件是已将对方成功添加到自己的好友列表中，因此，需要确保关键服务好友关系维护进行能够成功调用。而好友添加成功的通知如果有一些延迟，对用户而言是可以接受的，因此在添加好友的场景中，所述通知服务进程是非关键服务。

在本实施例中，依据开发人员的设置，可以保存各应用场景的非关键服务。当与全局事务相关的某个服务调用失败时，可以先确定所述全局事务所属的应用场景，比如：可以根据所述全局事务携带的场景标识确定其所属的应用场景，也可以根据所述全局事务携带的业务参数确定其所属的应用场景，本申请对此不作特殊限制。在确定所述全局事务所属的应用场景后，可以查找保存的所述应用场景的非关键服务，当确定所有失败服务均为非关键服务时，可以执行步骤202。当所有失败服务中有一个或多个不是非关键服务，即存在一个或多个失败服务是关键服务时，可以向调用方返回调用失败的消息，同时还可以通知已调用成功的其他服务进行回滚操作。

在本实施例中，依据开发人员的设置，也可以保存各应用场景的关键服务。当与全局事务相关的某个服务调用失败时，可以查找保存的关键服务，当失败服务中存在一个或者多个失败服务是关键服务时，可以向调用方返回调用失败的消息，同时还可以通知已调用成功的其他服务进行回滚操作。当确定所有失败服务均不是关键服务，即所有失败服务都是非关键服务时，可以执行步骤202。

步骤202，当所有失败服务均为所述全局事务所属应用场景的非关键服务时，将失败服务的调用上下文保存到补偿任务表中。

基于前述步骤201的判断结果，当确定所有失败服务均为所述全局事务所属应用场景的非关键服务时，说明失败服务本地事务成功调用的即时性在所述应用场景中要求较低，可以将失败服务的调用上下文保存到补偿任务表中，以等待后续重新调用。

由以上描述可以看出，本申请在实现失败服务重新调用的补偿操作时，对失败服务进行类型区分，从而确保对即时性要求较高的服务调用成功后才会向调用方返回调用成功的消息，确保用户的使用体验。

下面结合具体的例子来描述本申请的实现过程。

假设，用户A通过支付宝客户端发起一笔转账请求，请求向用户B转账人民币200元整。服务端在接收到该转账请求后，开启一个全局事务，支付宝客户端可以通过XA接口函数调用与转账事务相关的服务。

又假设，与该转账事务相关的服务包括：用于存储用户余额的数据库系统、消息通知进程、好友关系维护进程。其中，所述消息通知进程用于在转账成功后分别通知用户A和用户B。所述好友关系维护进程用于将用户A和用户B相互加为好友。所述用于存储用户余额的数据库系统是转账场景的关键服务，所述消息通知进行和所述好友关系维护进程是非关键服务。

在这个例子中，服务端在支付宝客户端调用上述三个服务时，分别获取各服务对应的调用上下文，并将所述调用上下文缓存到内存中。假设，用于存储用户余额的数据库系统返回调用成功的消息，即已成功将用户A账号的余额减少200元人民币，并将用户B账号的余额增加200元人民币。消息通知进程返回调用失败的消息，即无法向用户A和用户B发送转账成功的消息。好友关系维护进程返回调用成功的消息，即已成功将用户B添加为用户A的好友，并成功将用户A添加为用户B的好友。

针对失败服务：消息通知进程，服务端确定该失败服务是非关键服务，进而可以将内存中缓存的该失败服务的调用上下文存储到补偿任务表中，并删除内存中缓存的所述数据库系统的调用上下文和好友关系维护进程的调用上下文。其中，所述消息通知进程的调用上下文通常包括有：转账时间、转账金额、账号类型、用户A和用户B的账号标识等。此外，服务端还可以向支付宝客户端返回调用成功的消息，支付宝客户端进而可以显示转账成功的页面给用户。

后续，服务端可以每秒钟轮询所述补偿任务表，根据消息通知进程的调用上下文重新调用消息通知进程，如果调用成功，即已成功向用户A和用户B发送转账成功的消息，则可以删除所述补偿任务表中消息通知进程的调用上下文。在另一个例子中，如果第一次重新调用消息通知进程仍然失败，则可以在下个时间周期根据所述调用上下文再次重新调用消息通知进程，直到消息通知进程成功调用为止。

由以上描述可以看出，通过本申请提供的全局事务实现方案，当关键服务调用成功时，即可向用户返回调用成功的消息，提升用户的使用体验，同时，后续可以通过重新调用操作确保失败的非关键服务能够成功调用，从而确保全局事务的最终实现。

可选的，在本申请另一个实施例中，针对与全局事务相关的服务，也可以不进行关键服务与非关键服务的区分。即，当与全局事务相关的服务调用失败时，就可以将失败服务的调用上下文保存到补充任务表中，并向调用方返回调用成功的消息，后续通过轮询所述补偿任务表，以确保失败服务最终能够成功调用。在重新调用失败服务成功后，还可以删除补偿任务表中失败服务的调用上下文，具体可以参考前述图1所示的实施例，本申请在此不再一一赘述。

与前述SOA架构下事务的实现方法的实施例相对应，本申请还提供了SOA架构下事务的实现装置的实施例。

本申请SOA架构下事务的实现装置的实施例可以应用在服务端上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在服务端的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本申请SOA架构下事务的实现装置所在服务端的一种硬件结构图，除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的服务端通常根据该服务端的实际功能，还可以包括其他硬件，对此不再赘述。

图4是本申请一示例性实施例示出的一种SOA架构下事务的实现装置的框图。

请参考图4，所述SOA架构下事务的实现装置300可以应用在前述图3所示的服务端中，包括有：第一获取单元301、第一保存单元302、第一返回单元303、第一调用单元304、失败回滚单元305、上下文缓存单元306以及第一删除单元307。

其中，所述第一获取单元301，当调用方调用与全局事务相关的服务时，获取与所述服务对应的调用上下文，所述服务包括关键服务和非关键服务；

所述第一保存单元302，当非关键服务调用失败时，将该失败的非关键服务的调用上下文保存到补偿任务表中；

所述第一返回单元303，当关键服务均调用成功时，向所述调用方返回调用成功的消息；

所述第一调用单元304，按照预设的时间周期轮询所述补偿任务表，根据所述补偿任务表中保存的调用上下文重新调用所述失败的非关键服务。

所述失败回滚单元305，在出现关键服务调用失败时，向所述调用方返回调用失败的消息，并通知已调用成功的服务进行回滚操作。

所述上下文缓存单元306，在获取与所述服务对应的调用上下文之后，缓存所述调用上下文；

所述第一保存单元302，将缓存的该失败的非关键服务的调用上下文保存到补偿任务表中。

所述第一删除单元307，在重新调用所述失败的非关键服务成功时，删除所述补偿任务表中该失败的非关键服务的调用上下文。

图5是本申请一示例性实施例示出的另一种SOA架构下事务的实现装置的框图。

请参考图5，所述SOA架构下事务的实现装置400可以应用在前述图3所示的服务端中，包括有：第二获取单元401、第二保存单元402、第二返回单元403、第二调用单元404以及第二删除单元405。

其中，所述第二获取单元401，当调用方调用与全局事务相关的服务时，获取与所述服务对应的调用上下文；

所述第二保存单元402，当服务调用失败时，将失败服务的调用上下文保存到补偿任务表中；

所述第二返回单元403，向所述调用方返回调用成功的消息；

所述第二调用单元404，按照预设的时间周期轮询所述补偿任务表，根据所述补偿任务表中保存的调用上下文重新调用失败服务。

所述第二删除单元405，在重新调用所述失败服务成功时，删除所述补偿任务表中该失败服务的调用上下文。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。