一种服务补偿方法及装置与流程

本申请涉及通信技术领域，尤其涉及一种服务补偿方法及装置。

背景技术：

在oltp(on-linetransactionprocessing，联机事务处理过程)系统领域，在大部分业务场景下都会面临事务一致性的问题。尤其是在大型互联网系统包含成百上千个分布式事务的情况下，如何高效地保证每个分布式事务的回滚、提交或者重试的实现模式是完全一致的，是个极其重要的问题。

技术实现要素：

有鉴于此，本申请提供一种服务补偿方法及装置，可以使得开发人员在实现分布式服务一致性的时候，只需要对服务参数和补偿策略的参数的具体取值进行设置即可，而无需关心各个服务的设计以及补偿的调度和管理，从而提高了效率。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种服务补偿方法，应用于客户端；所述方法包括：

根据接收到的服务配置指令，对预设服务定义表中预定义的服务参数进行配置以得到目标服务，以及对补偿策略的策略参数进行配置；

向服务端发送针对所述目标服务的请求指令，以使得所述服务端响应于所述请求指令，向所述客户端输出所述目标服务；

当所述服务端输出所述目标服务失败时，按照配置的补偿策略对所述目标服务进行补偿。

根据本申请的第二方面，提出了一种服务补偿方法，应用于服务端；所述方法包括：

接收客户端发送的针对目标服务的请求指令，所述目标服务由所述客户端根据接收到的服务配置指令对预设服务定义表中预定义的服务参数进行配置得到；

响应于所述请求指令，向所述客户端输出所述目标服务；

其中，当输出所述目标服务失败时，由所述客户端按照配置的补偿策略对所述目标服务进行补偿，所述补偿策略由所述客户端根据接收到的服务配置指令对预设服务定义表中预定义的补偿策略进行配置得到。

根据本申请的第三方面，提出了一种服务补偿装置，应用于客户端；所述装置包括：

配置单元，根据接收到的服务配置指令，对预设服务定义表中预定义的服务参数进行配置以得到目标服务，以及对补偿策略的策略参数进行配置；

发送单元，向服务端发送针对所述目标服务的请求指令，以使得所述服务端响应于所述请求指令，向所述客户端输出所述目标服务；

补偿单元，当所述服务端输出所述目标服务失败时，按照配置的补偿策略对所述目标服务进行补偿。

根据本申请的第四方面，提出了一种服务补偿装置，应用于服务端；所述装置包括：

接收单元，接收客户端发送的针对目标服务的请求指令，所述目标服务由所述客户端根据接收到的服务配置指令对预设服务定义表中预定义的服务参数进行配置得到；

输出单元，响应于所述请求指令，向所述客户端输出所述目标服务；

其中，当输出所述目标服务失败时，由所述客户端按照配置的补偿策略对所述目标服务进行补偿，所述补偿策略由所述客户端根据接收到的服务配置指令对预设服务定义表中预定义的补偿策略进行配置得到。

由以上技术方案可见，本申请通过预先配置服务定义表，用于对分布式服务进行定义。其中，服务定义表中包含对服务参数的定义和补偿策略的定义。那么，开发人员在通过客户端调用各个分布式服务时，只需要对服务参数和补偿策略的参数的具体取值进行设置即可，而无需关心各个服务的设计以及补偿的设计、调度和管理，从而提高了效率。同时，基于对补偿策略的定义和配置，可保证分布式服务的一致性。

附图说明

图1是本申请一示例性实施例示出的一种服务补偿方法的流程图。

图2是本申请一示例性实施例示出的另一种服务补偿方法的流程图。

图3是本申请一示例性实施例示出的一种服务补偿方法的交互图。

图4是本申请一示例性实施例示出的一种服务补偿系统的架构示意图。

图5是本申请一示例性实施例示出的客户端标记请求记录的流程图。

图6是本申请一示例性实施例示出的服务端记录处理状态的流程图。

图7是本申请一示例性实施例示出的客户端执行补偿操作的流程图。

图8是本申请一示例性实施例示出的一种基于客户端侧的电子设备的结构示意图。

图9是本申请一示例性实施例示出的一种服务补偿装置的框图。

图10是本申请一示例性实施例示出的一种基于服务端侧的电子设备的结构示意图。

图11是本申请一示例性实施例示出的另一种服务补偿装置的框图。

具体实施方式

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

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

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

请参见图1，图1是本申请一示例性实施例示出的一种服务补偿方法的流程图。如图1所示，该方法应用于客户端，可以包括以下步骤：

步骤102，根据接收到的服务配置指令，对预设服务定义表中预定义的服务参数进行配置以得到目标服务，以及对补偿策略的策略参数进行配置。

步骤104，向服务端发送针对所述目标服务的请求指令，以使得所述服务端响应于所述请求指令，向所述客户端输出所述目标服务。

步骤106，当所述服务端输出所述目标服务失败时，按照配置的补偿策略对所述目标服务进行补偿。

在本实施例中，通过预先配置服务定义表用于对分布式服务(服务定义表中包含对服务参数的定义和补偿策略的定义)，使得开发人员在通过客户端调用各个分布式服务时，只需要对服务参数和补偿策略的参数的具体取值进行设置即可，而无需关心各个服务的设计以及补偿策略的设计、调度和管理，从而提高了效率。同时，基于对补偿策略的定义和配置，当服务端输出目标服务失败时，可按照配置好的补偿策略对目标服务进行补偿(比如重试)，从而保证目标服务的一致性。

在本实施例中，所述服务参数可包括以下至少之一：服务名称、服务请求标识符、服务类型、请求参数、请求处理状态；所述策略参数可包括以下至少之一：重试次数、补偿方式、重试间隔；其中，所述补偿方式包括：重发、回滚、忽略。那么，开发人员在实现分布式服务一致性时，只需对上述参数的取值进行配置即可，并不需要设计与补偿策略相关的业务代码，从而可有效提高效率。

在本实施例中，针对目标服务(比如，可以是分布式服务)的类型(包括强一致性服务和弱一致性服务)，客户端与服务端之间可采用不同的调用方式。具体的，客户端可判断所述目标服务的类型，当所述目标服务属于强一致性服务时，采用远程过程调用的方式向所述服务端请求调用所述目标服务；当所述目标服务属于弱一致性服务时，可采用消息队列的方式向所述服务端请求调用所述目标服务。其中，对于强一致性服务，采用rpc(remoteprocedurecall，远程过程调用)的方式调用，可保证服务的实时性(即实时性较高)。而对于弱一致性服务，采用mq(messagequeue，消息队列)的方式调用，可提高吞吐量，从而提高调用服务的效率。

相应的，请参见图2，图2是本申请一示例性实施例示出的另一种服务补偿方法的流程图。如图2所示，该方法应用于服务端，可以包括以下步骤：

步骤202，接收客户端发送的针对目标服务的请求指令，所述目标服务由所述客户端根据接收到的服务配置指令对预设服务定义表中预定义的服务参数进行配置得到；

步骤204，响应于所述请求指令，向所述客户端输出所述目标服务；其中，当输出所述目标服务失败时，由所述客户端按照配置的补偿策略对所述目标服务进行补偿，所述补偿策略由所述客户端根据接收到的服务配置指令对预设服务定义表中预定义的补偿策略进行配置得到。

在本实施例中，通过预先配置服务定义表用于对分布式服务(服务定义表中包含对服务参数的定义和补偿策略的定义)，使得开发人员在通过客户端调用各个分布式服务时，只需要对服务参数和补偿策略的参数的具体取值进行设置即可，而无需关心各个服务的设计以及补偿策略的设计、调度和管理，从而提高了效率。同时，基于对补偿策略的定义和配置，当服务端输出目标服务失败时，可按照配置好的补偿策略对目标服务进行补偿(比如重试)，从而保证目标服务的一致性。

在本实施例中，各服务的补偿记录可存储于区别于所述客户端与所述服务端的第三方设备中，以由所述客户端与所述服务端主动向所述第三方设备中读取。通过将补偿记录存储于第三方设备中以由客户端与服务端主动读取，可节约客户端与服务端的存储空间。另外，所述预设服务定义表也可存储于该第三方设备中，以由客户端主动向该第三方设备读取。

为了便于理解，下面结合具体举例和附图，对本申请的技术方案进行详细说明。

请参见图3，图3是本申请一示例性实施例示出的一种服务补偿方法的交互图。如图3所示，该方法可以包括以下步骤：

步骤302，客户端生成请求指令。

步骤304，客户端配置补偿策略。

在本实施例中，可预先配置服务定义表以供开发人员对其包含的参数进行配置。其中，服务定义表中包含对服务参数的定义和对补偿策略的定义。基于对服务定义表的预配置，开发人员在通过客户端调用各个分布式服务时，只需要对服务参数和补偿策略的参数的具体取值进行设置即可，而无需关心各个服务的设计以及补偿策略的设计(例如，对实现补偿以保证一致性的业务代码的设计)、调度和管理，从而提高了效率。同时，基于对补偿策略的定义和配置，当服务端输出目标服务失败时，可按照配置好的补偿策略对目标服务进行补偿(比如重试)，从而保证目标服务的一致性。

举例而言，服务定义表可如表1所示：

表1

其中，分布式服务定义id(disttransid)用于表示服务请求标识符，消息名称(messagename)用于表示服务名称，消息类型(msgtype)和消息子类型(messagesubtype)用于表示服务类型，返回状态(returncode)用于表示请求处理状态；返回状态响应类型(resultactiontype)用于表示补偿方式，包括重发、回滚、忽略等。基于表1所示的服务定义表，开发人员只需要对上述字段的字段值进行赋值即可，便可完成对目标服务和针对目标服务的补偿策略的制定。

而针对服务定义表的存储，可将服务定义表存储于区别于客户端和服务端的第三方设备中。如图4所示，客户端41与服务端42进行交互，而服务定义表可存储于数据库43中，以由客户端41与服务端42主动向数据库43读取。

步骤306，客户端向服务端发送请求指令，以调用目标服务。

在本实施例中，客户端(作为服务消费端)向服务端(作为服务提供端)发送针对目标服务的请求指令，以使得服务端响应于该请求指令，向客户端输出(提供)目标服务。

步骤308，客户端存储请求记录。

在本实施例中，请求记录可存储于消息记录表中，以记录具体的每次服务调用过程。下面结合图5进行说明。如图5所示，该过程可以包括以下步骤：

在步骤502中，判断目标服务是否需自动补偿，若是，则转入步骤504，否则结束。

在步骤504中，获取请求指令的标识符。

在步骤506中，判断消息记录表中是否存在相同标识符的请求记录，若存在，则转入结束，否则转入步骤508。

在步骤508中，将该请求指令标记为已发送状态。

举例而言，消息记录表可如表2所示：

表2

其中，消息处理编号(disttransmsgid)用于表示服务名称，业务信息编号用于表示(businessmsgid)用于表示请求指令的标识符(该标识符唯一)；补偿方式包括重发、回滚、忽略等。例如，当判断出消息记录表中不存在相同标识符的请求记录时，将字段“消息处理状态(msgprocessstatus)”标记为已发送。需要说明的是，消息记录表可存储于客户端中，也可存储于上述数据库43中。

步骤310，服务端处理请求指令。

步骤312，服务端记录处理状态。

在本实施例中，处理状态可记录于消费记录表中，以记录针对每次接收到请求指令的处理状态。下面结合图6进行说明。如图6所示，该过程可以包括以下步骤：

在步骤602中，判断目标服务是否需自动补偿，若是，则转入步骤604，否则结束。

在步骤604中，获取接收到的请求指令的标识符。

在步骤606中，判断消费记录表中是否存在相同标识符的请求记录，若存在，则转入结束，否则转入步骤608。

在步骤608中，判断请求指令是否为不可重复的指令或者状态为“处理中”，若是，则转入结束，否则转入步骤610。

在步骤610中，将该请求指令标记为处理中状态。

在步骤612中，处理请求指令。

在步骤614中，更新请求指令为处理完成状态。

举例而言，消费记录表可如表3所示：

表3

其中，消息处理状态包括处理中与处理完成。需要说明的是，消费记录表可存储于服务端端中，也可存储于上述数据库43中。

步骤314，当服务端输出目标服务失败时，按照配置的补偿策略对目标服务进行补偿。

步骤316，当服务端经补偿操作处理请求指令完成后，将处理状态更新为已完成。

步骤318，服务端向客户端返回处理状态。

步骤320，客户端将消息记录表中对应于该请求指令的处理状态更新为已完成。

在本实施例中，当客户端调用目标服务失败时(即服务端输出目标服务失败)，可按照步骤304配置的补偿策略对目标服务进行补偿，从而实现目标服务的一致性。

以补偿策略中的补偿方式为重试为例，如图7所示，补偿过程可以包括以下步骤：

步骤702，客户端遍历消息记录表中状态为已发送的请求指令。

步骤704，判断当前时刻是否到达重试间隔，若达到，则转入步骤706，否则转入步骤702。

步骤706，重新向服务端发送请求指令。

例如，假定补偿策略(补偿方式被配置为重试)中配置的重试次数为10次，重试间隔(可理解为重试的周期)为6s；那么，当请求指令的状态为已发送时，客户端按照周期为6s重新向服务端发送请求指令，直到发送请求指令(同一请求指令)的次数达到10次。

又如，当开发人员需要在放款操作后增加扣手续费的逻辑时，可按照如表1的服务定义表，在业务逻辑层面确定分布式事务的消息或请求名称、消息或请求的标识符、参数体、回滚消息或请求名称、回滚参数体、补偿方式等参数，即可完成一个分布式事务的一致性开发，而无需编写骨架性代码。例如，可以进行如表4所示的配置：

表4

基于上述配置，当客户端请求调用扣款服务时，若发生ret001，ret002，ret003中任一错误，则每隔3分钟自动尝试调用扣款服务，直到返回0或者success(表示成功)，或者直到尝试的次数超过指定次数。

需要说明的是，在本申请的服务补偿方案中，客户端可判断目标服务的类型，当目标服务属于强一致性服务时，采用远程过程调用的方式向服务端请求调用所述目标服务；当目标服务属于弱一致性服务时，可采用消息队列的方式向服务端请求调用目标服务。其中，对于强一致性服务，采用rpc(remoteprocedurecall，远程过程调用)的方式调用，可保证服务的实时性(即实时性较高)。而对于弱一致性服务，采用mq(messagequeue，消息队列)的方式调用，可提高吞吐量，从而提高调用服务的效率。

图8示出了根据本申请的一示例性实施例的基于客户端侧电子设备的示意结构图。请参考图8，在硬件层面，该电子设备包括处理器802、内部总线804、网络接口808、内存808以及非易失性存储器810，当然还可能包括其他业务所需要的硬件。处理器802从非易失性存储器810中读取对应的计算机程序到内存808中然后运行，在逻辑层面上形成服务补偿装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图9，在软件实施方式中，该服务补偿装置可以包括：

配置单元91，根据接收到的服务配置指令，对预设服务定义表中预定义的服务参数进行配置以得到目标服务，以及对补偿策略的策略参数进行配置；

发送单元92，向服务端发送针对所述目标服务的请求指令，以使得所述服务端响应于所述请求指令，向所述客户端输出所述目标服务；

补偿单元93，当所述服务端输出所述目标服务失败时，按照配置的补偿策略对所述目标服务进行补偿。

可选的，

还包括：判断单元94，判断所述目标服务的类型；

所述发送单元92具体用于：当所述目标服务属于强一致性服务时，采用远程过程调用的方式向所述服务端请求调用所述目标服务；当所述目标服务属于弱一致性服务时，采用消息队列的方式向所述服务端请求调用所述目标服务。

可选的，所述服务参数包括以下至少之一：服务名称、服务请求标识符、服务类型、请求参数、请求处理状态；所述策略参数包括以下至少之一：重试次数、补偿方式、重试间隔；其中，所述补偿方式包括：重发、回滚、忽略。

图10示出了根据本申请的一示例性实施例的基于服务端端侧电子设备的示意结构图。请参考图10，在硬件层面，该电子设备包括处理器1002、内部总线1004、网络接口10010、内存10010以及非易失性存储器1010，当然还可能包括其他业务所需要的硬件。处理器1002从非易失性存储器1010中读取对应的计算机程序到内存10010中然后运行，在逻辑层面上形成服务补偿装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图11，在软件实施方式中，该服务补偿装置可以包括：

接收单元1101，接收客户端发送的针对目标服务的请求指令，所述目标服务由所述客户端根据接收到的服务配置指令对预设服务定义表中预定义的服务参数进行配置得到；

输出单元1102，响应于所述请求指令，向所述客户端输出所述目标服务；

其中，当输出所述目标服务失败时，由所述客户端按照配置的补偿策略对所述目标服务进行补偿，所述补偿策略由所述客户端根据接收到的服务配置指令对预设服务定义表中预定义的补偿策略进行配置得到。

可选的，各服务的补偿记录存储于区别于所述客户端与所述服务端的第三方设备中，以由所述客户端与所述服务端主动向所述第三方设备中读取。

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

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

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器，上述指令可由服务补偿装置的处理器执行以完成上述方法，该方法可以包括：

根据接收到的服务配置指令，对预设服务定义表中预定义的服务参数进行配置以得到目标服务，以及对补偿策略的策略参数进行配置；

向服务端发送针对所述目标服务的请求指令，以使得所述服务端响应于所述请求指令，向所述客户端输出所述目标服务；

当所述服务端输出所述目标服务失败时，按照配置的补偿策略对所述目标服务进行补偿。

可选的，还包括：判断所述目标服务的类型；

所述向服务端发送针对所述目标服务的请求指令，包括：当所述目标服务属于强一致性服务时，采用远程过程调用的方式向所述服务端请求调用所述目标服务；当所述目标服务属于弱一致性服务时，采用消息队列的方式向所述服务端请求调用所述目标服务。

可选的，所述服务参数包括以下至少之一：服务名称、服务请求标识符、服务类型、请求参数、请求处理状态；所述策略参数包括以下至少之一：重试次数、补偿方式、重试间隔；其中，所述补偿方式包括：重发、回滚、忽略。

其中，所述非临时性计算机可读存储介质可以是rom、随机存取存储器(ram)、cd-rom、磁带、软盘和光数据存储设备等，本申请并不对此进行限制。

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