对跨域业务请求的处理方法及装置与流程

本说明书一个或多个实施例涉及计算机技术领域，尤其涉及通过计算机对跨域业务请求进行处理的方法和装置。

背景技术：

跨域业务，通常是发生在分开部署的两个服务化系统之间的业务。跨域业务发生的两个系统中，一个系统如果需要完成和另一个系统有关业务，往往只能需要通过另外一个系统提供的服务化接口请求来完成操作。跨域业务发生的两个系统例如可以是，不同域名下的两个系统、不同app(应用)、同一app下的两个子系统等等。举例而言，在面向服务的架构soa中，应用程序的不同功能单元(也可以称为服务)通过这些功能单元之间定义的接口和契约进行通信。由于接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言，这使得soa下，构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。此时，跨域业务发生的两个系统可以是soa下的两个不同功能单元(服务)。

跨域业务中，往往需要对时序进行控制。例如在金融系统中，跨域业务往往在发出处理请求后，对跨域业务的处理结果进行查询，以获取对跨域业务是否处理成功。由于网络延迟或者抖动等原因，如果查询请求先于处理请求到达对方系统，则可能使双方对跨域业务的记录结果不一致，从而造成资金差异，可能增加账务人员工作量，或产生重大资金风险。

因此，希望能有改进的方案，对跨域业务中可能出现的时序异常进行规避，从而保障跨域业务状态一致性。

技术实现要素：

本说明书一个或多个实施例描述了一种对跨域业务请求进行处理的方法和装置，用于对发生在两个系统中的接收方。通过在首次处理跨域业务的业务请求时，不管是处理请求还是查询请求，都对跨域业务的幂等标识进行记录，可以对跨域业务中可能出现的时序混乱进行规避，使得第一系统和第二系统对跨域业务的处理结果保持一致。

根据第一方面，提供了一种对跨域业务请求的处理方法，所述跨域业务包括在第一系统和第二系统之间进行的业务；所述方法通过所述第一系统执行，包括：在第一时刻，接收到查询请求，所述查询请求由所述第二系统在发出处理请求之后的预定时间间隔之后发出，用于查询所述处理请求中的跨域业务的处理状态，所述查询请求包括与所述处理请求一致的、与所述跨域业务对应的业务标识；从所述查询请求提取所述跨域业务的幂等标识，其中，所述幂等标识至少包括所述业务标识，所述幂等标识至少用于查询和/或记录所述跨域业务的处理状态；基于对所述幂等标识的查询，确定所述跨域业务的处理状态，其中，在未查询到所述幂等标识的情况下，记录所述幂等标识，并确定所述幂等标识对应的处理状态为预设状态；将所述幂等标识对应的处理状态作为查询结果发送给所述第二系统。

在一个实施例中，所述基于对幂等业务标识的查询，确定所述跨域业务的处理状态还包括：在查询到所述幂等标识的情况下，获取所述幂等标识对应的处理状态。

根据一种实施方式，所述方法还包括：在第二时刻，接收到所述处理请求所述处理请求包括所述业务标识；从所述处理请求中提取所述幂等标识；

按照所述幂等标识的幂等性对所述处理请求进行处理。

在一个实施例中，所述按照所述幂等标识的幂等性对所述处理请求进行处理包括：对所述幂等标识进行查询；响应于查询不到所述幂等标识，记录所述幂等标识，并对所述跨域业务进行处理，以将对所述跨域业务的处理结果记录为所述幂等标识对应的处理状态；或者，响应于查询到所述幂等标识，确定无需对所述跨域业务进行处理。

在一个实施例中，所述幂等标识和所述跨域业务的处理状态对应通过业务幂等表记录。

在一个实施例中，所述幂等标识还包括所述第二系统的系统标识、时间标识中的至少一项。

根据第二方面，提供一种对跨域业务请求的处理装置，所述跨域业务包括在第一系统和第二系统之间进行的业务；所述装置设于所述第一系统中，包括：获取单元，配置为在第一时刻，接收查询请求，所述查询请求由所述第二系统在发出处理请求之后的预定时间间隔之后发出，用于查询所述处理请求中的跨域业务的处理状态，所述查询请求包括与所述处理请求一致的、与所述跨域业务对应的业务标识；提取单元，配置为从所述查询请求提取所述跨域业务的幂等标识，其中，所述幂等标识至少包括所述业务标识，所述幂等标识至少用于查询和/或记录所述跨域业务的处理状态；确定单元，配置为基于对所述幂等标识的查询，确定所述跨域业务的处理状态，其中，在未查询到所述幂等标识的情况下，记录所述幂等标识，并确定所述幂等标识对应的处理状态为预设状态；发送单元，将所述幂等标识对应的处理状态作为查询结果发送给所述第二系统。

根据第三方面，提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面的方法。

根据第四方面，提供了一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第一方面的方法。

本说明书实施例提供的对跨域业务请求的处理方法和装置，通过在第二系统向第一系统发送的处理请求和查询请求中包含相同的业务标识，并都能提取出至少包含业务标识的幂等标识。第一系统按照首先处理的处理请求或查询请求中的一个落地幂等标识，如果查询请求先于处理请求到达，可以将幂等标识对应的处理状态落地(记录)为预设状态(例如处理失败、未处理等)。如此，对于异步的业务请求(针对一个业务，先发送处理请求后发送查询请求，并以查询结果为准进行后续处理，其中的处理请求和查询请求为该业务的异步业务请求)，可以不受请求时序的影响，使得跨域业务发生的两个系统对跨域业务的处理状态记录保持一致。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1～图3示出本说明书披露的一个实施例的实施场景示意图；

图4示出根据一个实施例的处理跨域业务请求的方法流程图；

图5示出根据一个实施例的对跨域业务请求的处理装置的示意性框图。

具体实施方式

下面结合附图，对本说明书提供的方案进行描述。

本说明书实施例主要应用于在第一系统和第二系统之间发生跨域业务的过程。其中，第一系统和第二系统是两个具有相互独立功能的系统，例如第一系统是网上购物系统，第二系统是网上支付平台(如支付宝等)，跨域业务可以是通过网上支付平台为网上购物系统的订单进行支付等业务。为了更清楚地说明本说明书实施例的方案，首先介绍本说明书实施例的应用背景。

图1是用户通过第二系统发起与第一系统相关联的业务1的情况下，第二系统与第一系统之间的正常交互时序图。如图1所示，在正常情况下，第二系统首先在t时刻向第一系统发送业务1的处理请求。第一系统接收到业务1的处理请求，可以直接对业务1进行处理，也可以先存入缓存中，按照业务优先级排列顺序，在某一时刻处理业务1。第一系统在处理业务1时，可以先记录业务1，再对业务1进行处理，并记录处理结果。处理结果可以包括处理成功、处理失败等。在与时刻t具有预定时间间隔(如30秒)的时刻t，第二系统向第一系统发送关于业务1的查询请求。第一系统查询业务1的处理结果，并反馈至第二系统。其中，第一系统在处理业务1的过程中，可能根据处理情况修改数据库，例如，业务1为从第一系统为第二系统的订单进行支付的支付业务，第一系统可以在数据库中将用户对应的账户余额减去相关数值。此时，第二系统也可以根据第一系统返回的业务1的查询结果确定支付结果，并进行后续流程，例如，支付成功则生成待发货订单等。值得说明的是，如果第一系统未收到业务1的处理请求，还可以返回“未收到”的查询结果。如果第一系统异常、繁忙或者正在处理业务1，也可以返回相应的结果，此时，第二系统可以循环发送业务1的查询请求，直至收到与处理成功、处理失败、未收到等对应明确业务处理结果的信息。

另外，常规技术中，为了保证网络不稳定、延迟、重发等情况下，造成的第一系统可能多次收到同一个跨域业务的处理请求的状况，第一系统对各个跨域业务往往按照幂等标识的幂等性进行处理。即，对同一个跨域业务，不管收到多少次处理请求，只对其处理一次，且只具有一个处理结果。具体地，对于正常接收到的处理请求，可以先提取相应跨域业务的幂等标识，在记录跨域业务的幂等表中查询该幂等标识，若查到该幂等标识，说明相应跨域业务被处理(或受理)过，不再处理。当第一系统接收到针对跨域业务的查询请求时，也会先提取幂等标识，从业务幂等表查询跨域业务的处理状态。

请参考图2，假设由于网络或硬件设备故障原因，第二系统t时刻发送的业务1的处理请求，在t时刻第一系统还未收到。而t时刻，第一系统又获取了第二系统向第一系统发送的业务1的查询请求。第一系统返回未收到或不存在等的查询结果。第二系统根据该查询结果按照业务1处理失败继续后续流程。例如，第二系统重新发送编号为业务2的支付请求等。之后，第一系统又收到了业务1的处理请求，并对业务1进行处理，例如将用户对应的账户余额减去相关数值等，记录处理结果。也就是说，第一系统按照对业务1的正常处理继续后续流程。在这种情况下，第一系统和第二系统对业务1的处理结果记录不再一致。实际应用中，往往通过在t时刻与t时刻之间设置较大时间间隔来尽量避免这种情况的发生。然而，一方面，在t时刻与t时刻之间设置较大时间间隔，影响业务交互的效率，另一方面，在不确定因素的影响下，很难找到一个较佳的时间间隔，确保第一系统不会在t时刻之后获取业务1的处理请求，并对业务1进行处理。

在上述背景下，图3示出了本说明书披露的一个实施例的实施场景示意图。在图3中，针对一个第二系统向第一系统请求的跨域业务，第二系统向第一系统发送处理请求后，经过预定时间间隔再向第一系统发送查询请求。具体地，第二系统向第一系统发送的处理请求和查询请求中都可以包括有与该跨域业务对应的业务标识。这个业务标识例如是前述支付业务中的订单号或流水号等。在第一系统接收到第二系统针对该跨域业务的查询请求时，可以先从查询请求提取跨域业务的幂等标识，并基于该幂等标识查询跨域业务的处理状态，以根据查询结果确定幂等标识对应的处理状态。其中：在查询到幂等标识的情况下，可以直接获取幂等标识对应的处理状态；在未查询到幂等标识的情况下，可以记录该幂等标识，并确定该幂等标识对应的处理状态为预设状态。其中，该预设状态可以包括但不限于以下中的一项：未收到、未处理、处理失败、空状态，等等。然后，第一系统将该幂等标识对应的处理状态作为查询结果发送给第二系统。其中，幂等标识至少可以包括上述业务标识。第一系统根据一个幂等标识，只受理一次该幂等标识对应的业务。换句话说，只要第一系统记录了该幂等标识，就不再受理同一个幂等标识对应的业务的处理请求。在一些实施例中，幂等标识还可以包括其他标识，例如时间标识(如2018年9月5日)、第二系统的系统标识(如系统身份标识：2号等)等等。

这样，在第一系统已经对跨域业务正常处理的情况下，向第二系统返回的是正常处理的处理状态。而在第一系统还未收到跨域业务处理请求的异常情况下，如图3所示，第一系统先收到业务1的查询请求时，由于第一系统并未收到业务1的处理请求，因此，在本地没有业务1的记录，也没有记录业务1的幂等标识。此时，一方面，第一系统可以落地(例如记录到数据库)一个业务1的幂等标识，以杜绝该跨域业务后续再次被处理的可能性，并将对应的处理状态记录为预设状态(如处理失败等)，另一方面，第一系统向第二系统返回业务1上述预设状态的查询结果。这样，第二系统可以按照业务1的上述预设状态进行后续流程，例如，订单支付失败，需重新发送新的支付请求或重新下单等。而之后，即使第一系统又接收到了关于业务1的处理请求，由于第一系统中已落地有业务1的幂等标识，并记录有对应的预设状态的结果，第一系统也不再对业务1进行处理。如此，可以保证在网络原因造成的业务请求送达时序不符合预期的情况下，第一系统和第二系统对业务1的处理状态或处理结果保持一致。

通过以上描述可知，本说明书实施例的处理跨域业务请求及对跨域业务的请求方法，尤其适用于具有独立功能的两个服务化系统之间的业务请求。两个服务化系统可以通过一定的协议和确定的接口进行通信。由于接口是独立于实现服务的硬件平台、操作系统和编程语言的，这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。举例而言，针对面向服务架构soa而言，第一系统和第二系统可以是同一个服务平台的两个功能单元，例如一个支付平台中的理财单元(如余额宝)和支付单元(如转账)等等，也可以是不同类别的服务平台下的功能单元，例如水电管理平台下的计算单元和银行资产管理平台下的支付单元等等。可以理解，由于第一系统和第二系统可以提供不同的服务，在一个系统向另一个系统发起跨域业务的处理请求之后，还需要再查询该跨域业务的处理情况，以保证两个系统间对跨域业务记录的业务状态的一致性。

下面描述上述场景的具体执行过程。

图4示出根据一个实施例的对跨域业务请求的处理方法流程图。其中的跨域业务是发生在两个系统间的业务，例如发生在网络购物平台和网络支付平台之间的支付业务、发生在某个银行系统的前置子系统和账务子系统之间的存取款业务等等。这里，网络购物平台和网络支付平台就是两个系统，例如分别是图1～图3所示的第一系统和第二系统。其中，该方法的执行主体可以是图1～图3所示的第一系统等。该第一系统可以是任何具有计算、处理能力的系统、设备、装置、平台或服务器。值得说明的是，第一系统和第二系统只是为了区分两个不同系统，而不表示其他限定。也就是说，第一系统和第二系统的角色可以互换。

如图4示，该方法包括以下步骤：步骤41，在第一时刻，接收到查询请求，所述查询请求由第二系统在发出处理请求之后的预定时间间隔之后发出，用于查询所述处理请求中的跨域业务的处理状态，查询请求包括与处理请求一致的、与跨域业务对应的业务标识；步骤42，从查询请求提取跨域业务的幂等标识，其中，幂等标识至少包括上述业务标识，幂等标识至少用于查询和/或记录跨域业务的处理状态；步骤43，基于对幂等标识的查询，确定跨域业务的处理状态，其中，在未查询到幂等标识的情况下，记录幂等标识，并确定幂等标识对应的处理状态为预设状态；步骤44，将上述幂等标识对应的处理状态作为查询结果发送给第二系统。

值得说明的是，图4的流程尤其适应于这样的场景：针对一个第二系统向第一系统请求的跨域业务，第二系统向第一系统发送处理请求后，经过预定时间间隔再向第一系统发送查询请求，以查询第一系统对跨域业务的处理状态。

在本说明书实施例中，对于一个跨域业务，可以具有一个确定的业务标识。该业务标识和跨域业务相对应。例如，对于银行柜台的业务，在每个日期里，每个业务可以唯一对应一个排队号。该业务标识可以由数字、字符、符号、文字等中的至少一项组成，例如可以是流水号、订单号等等。而幂等标识是第一系统对跨域业务处理请求或查询请求的处理进行处理的依据。在业务标识与跨域业务唯一对应的情况下，幂等标识可以只包括业务标识。在业务标识在有限范围内与跨域业务唯一对应的情况下，幂等标识还可以包括该有限范围的限定因素。

其中，针对同一个跨域业务，第二系统向第一系统发送的处理请求和查询请求中可以包含相同的业务标识。对于第一系统而言，其可能先接收到处理请求，也可能先接收到查询请求。

正常情况下，第一系统先接收到处理请求。针对处理请求，第一系统接收之后，可能直接处理，也可能先放在缓存里，按照任务优先级按顺序处理。通常，第一系统获取该处理请求的时刻，可以认为是第一系统要处理该跨域业务的时刻。为了和发明内容部分一致，称该时刻为第二时刻。此时，第一系统可以先根据幂等标识在第一系统内查询该跨域业务是否有记录。在跨域业务被记录过的情况下，说明该跨域业务已经被受理过，第一系统可以不再处理该跨域业务，以免重复处理。在跨域业务未被记录过的情况下，说明该跨域业务未被受理过，第一系统可以先将幂等标识落地(即记录，如写入数据库)，然后按照处理请求对跨域业务进行处理，得到相应的处理结果。第一系统在处理完跨域业务，也可以将处理结果记录到对应的处理状态。例如处理结果中的处理成功、处理失败都可以记录为处理状态。在第三时刻，第二系统向第一系统发送查询请求。该第三时刻晚于上述第二时刻，其与第二时刻可以具有一定时间间隔，如30秒。

假设在第一时刻第一系统接收到该查询请求，而第一时刻和第二时刻的先后顺序不能预先确定。如此，在获取该查询请求时，第一系统可以执行图4中示出的流程。

首先，步骤41中，在第一时刻，接收到第二系统针对跨域业务的查询请求。可以理解，该查询请求是由第二系统在发出处理请求之后的预定时间间隔之后发出的，查询请求中包括有与处理请求一致的、与跨域业务对应的业务标识。由于业务标识与跨域业务是对应的关系，从而基于该业务标识，第一系统可以对相应跨域业务进行识别和处理。

然后，通过步骤42，从查询请求提取跨域业务的幂等标识。可以理解，幂等标识是第一系统为了保证对业务的处理请求进行处理的幂等性，而设置的标识。一个幂等标识可以唯一确定一个业务。使第一系统还可以根据该幂等标识查询和/或记录跨域业务的处理状态。

在一些情况下，业务标识是可以与具体业务唯一对应的。例如，对于所有相关系统中的业务，可以统一分配业务标识，第一系统只和一个第二系统交互的情况下，第二系统为每个业务按照请求顺序分配相应的流水号等。

在另一些情况下，业务标识可以和具体业务不唯一对应。例如多个购物平台中的每一个购物平台都可以通过某银行的银行卡进行支付，而每个平台的业务标识可以是该平台服务器生成的订单号。该银行的支付平台可以作为第一系统，每个购物平台作为一个第二系统，由于每个购物平台有不同的服务器，他们所生成的订单号可能一致，如都是000000050827(即表示在相应平台中所有用户中第50827人次的下单)。此时需要通过购物平台的平台标识，也就是第二系统的系统标识，和业务标识(订单号)一起唯一确定一个业务。

在另一些情况下，业务标识和业务可以在有限范围内唯一对应。例如，银行的排队系统，在每个日期内，如果一个排队号只能办一个业务，则排队号与业务唯一对应。如果把排队号作为业务标识，日期作为时间标识，则通过时间标识和业务标识可以唯一确定一个业务。在一个实施例中，时间标识还可以包括业务请求生成的时间戳等。

在更多情形下，还可以通过各种合理标识唯一确定一个跨域业务，在此不再赘述。总之，这些标识里至少包括上述业务标识。在第二系统向第一系统发送跨域业务的查询请求或处理请求时，可以包括这些能够唯一确定一个跨域业务的标识提取出来，作为幂等标识。如前所述，幂等标识至少可以包括业务标识。还可以包括但不限于以下至少一项：时间标识、第二系统的系统标识，等等。

接着，在步骤43，基于对幂等标识的查询，确定跨域业务的处理状态。可以理解，在跨域业务被处理的情况下，第一系统可以记录跨域业务的幂等标识和处理状态，因此，第一系统可以至少以幂等标识为索引，查询跨域业务的处理状态。

在一种情形下，第一系统查询到上述幂等标识，则表示第一系统已经落地(记录)该幂等标识，说明该跨域业务已经被受理，亦即第一系统至少已经开始对跨域业务进行处理。同时，也说明第一系统获取处理请求的第二时刻早于获取查询请求的第一时刻。此时，第一系统可以获取幂等标识对应的处理状态。在一个实施例中，该处理状态可以是处理成功。如果在第一时刻，第一系统已经对跨域业务处理成功，如从相应的用户账户成功扣款，则第一系统根据上述幂等标识可以获取处理成功的处理状态。在另一个实施例中，该处理状态还可以是处理失败。如果在第一时刻，第一系统对跨域业务已经处理完毕，但是没有成功，例如对于支付业务，对应用户的账户余额小于支付金额导致扣款失败，则第一系统根据上述幂等标识可以获取处理失败的处理状态。在又一个实施例中，该处理状态也可以是处理中。如果在第一时刻，第一系统已经对跨域业务进行处理，但是还没有处理完毕，幂等标识对应的处理状态为空或者为处理中，则第一系统可以根据上述幂等标识可以获取处理中的处理状态。

值得说明的是，处理成功、处理失败、处理中等表达方式可以有多种，本说明书实施例对此并不作限定。例如，处理成功的表达方式可以包括但不限于：已扣款、扣款成功、支付成功、已处理等等中的一项，处理失败的表达方式可以包括但不限于：未扣款、支付失败、出现错误等等中的一项，处理中的表达方式可以包括但不限于：等待处理、正在处理、处理中等等中的一项。

其中，在一些实施例中，如果上述处理状态为处理中，第二系统还可以继续向第一系统发送同样的查询请求，即，所发送的查询请求包含相同的业务标识，直至确定对上述跨域业务的处理状态为处理成功或处理失败。

在另一种情形下，第一系统未查询到上述幂等标识，则表示第一系统还未落地该幂等标识，说明该跨域业务还没有被受理过，亦即第一系统至少还没有开始对跨域业务进行处理。此时，第一系统可能还没有接收到对跨域业务的处理请求，也可能接收到跨域业务的处理请求，但还没开始处理。相应地，根据幂等标识获取的处理状态也可以是未接收到或未处理。在这种情况下，第一系统可以落地查询请求中的幂等标识，以表明该跨域业务此时被受理。第一系统可以记录该跨域业务的幂等标识，并将其处理状态确定为预设状态。这里的预设状态是预先设定的一个状态，其可以包括但不限于处理失败、未处理、空状态等等中的一项。这样，即使后续第一系统会再获取该跨域业务的处理请求，也会因为第一系统已经受理过该跨域业务，而不再重复受理。如此，可以有效避免第一系统重复受理该跨域业务，造成第一系统和第二系统记录不同的处理状态，或者第一系统和第二系统按照不同的处理状态进行后续流程处理。

可以理解，除了以上列出的处理成功、处理失败、处理中等处理状态，上述处理状态还可以是其他可能出现的各种状态，例如系统故障、处理异常等等，在此不再一一例举。

然后，在步骤44，将幂等标识对应的处理状态作为查询结果发送给第二系统。在本说明书实施例中，第一系统可以将在步骤43中确定的处理状态作为查询结果，反馈给第二系统。在一些实现中，由于第二系统可以继续向第一系统发送同样的查询请求，第一系统还可以对每次查询都反馈相应的处理状态。而每次反馈的查询结果不一定是一致的，例如，前4次反馈的是处理中，第5次反馈的是处理成功。第二系统在接收到该处理成功的反馈之后可以不再发送查询请求。

根据一种实施方式，第一系统对幂等标识和相应跨域业务的处理状态可以通过业务幂等表记录。该业务幂等表可以以幂等标识为索引，记录相应跨域业务的处理状态。

在幂等标识包括多个标识的情况下，第一系统在对幂等标识查询时，还可以先根据其中一个标识(例如第二系统的系统标识)确定一个较小的查找范围，再在该标识对应的范围内查找对应的业务标识。如此，可以减少查询过程的数据处理量。

根据一个可能的设计，第一系统在第二时刻接收到针对上述跨域业务的处理请求后，可以首先从处理请求中提取幂等标识，并按照幂等标识的幂等性对处理请求进行处理。具体地，根据处理请求的幂等性要求，第一系统可以对幂等标识先进行查询。在一种情形下，第二时刻早于第一时刻，则第一系统可能没有记录相应幂等标识，也查询不到相应幂等标识(该跨域业务未被受理过)。此时，第一系统可以记录该幂等标识，以表明对该跨域业务的受理，并接着对跨域业务进行处理，以将对跨域业务的处理结果记录为幂等标识对应的处理状态。在另一种情形下，第二时刻晚于第一时刻，此时，第一系统根据查询请求已经记录了该幂等标识，查询时就会查询到相应幂等标识。此时，第一系统可以确定无需对上述跨域业务进行处理(其处理状态已经确定为上述预设状态)。值得说明的是，这里虽然用了“第二时刻早于第一时刻”以及“第二时刻晚于第一时刻”这样的表述，但是并不代表第一系统对第一时刻和第二时刻做了对比，这里只是为了便于描述和理解。容易理解，第二时刻早于第一时刻，对应着查询不到相应的幂等标识，即查询请求到达第一系统时，相应跨域业务还未被受理的情况。

在一些实现中，第一系统也可以是分布式系统，对处理请求和查询请求的处理可以由不同的计算设备去完成。例如第一系统可以至少包括处理服务器、查询服务器和存储服务器。处理服务器完成对处理请求的处理，查询服务器完成对查询请求的处理，处理服务器和查询服务器都和存储服务器连接。处理服务器或查询服务器都从存储服务器查询幂等标识，处理服务器或查询服务器记录幂等标识也是在存储服务器记录。可选地，处理服务器也可以通过向查询服务器发送查询请求来查询存储服务器的幂等标识。

在一个实施例中，步骤43中，在根据查询请求查询不到相应幂等标识的情况下，所确定的预设状态还可以是区别于第一系统对跨域业务正常处理得到的处理状态，以使第二系统能够按照反馈的查询结果进行区别于第一系统对跨域业务正常处理时的后续流程。例如，重新生成新的业务标识再次发送新的跨域业务的处理请求等。

回顾以上过程，通过在第二系统向第一系统发送的处理请求和查询请求中所包含的相同的幂等标识，第一系统在接收到查询请求后，先对幂等标识进行查询，如果未查询到该幂等标识，则落地(记录)该幂等标识，以表明受理该跨域业务，并确定幂等标识对应的处理状态为预设状态(如处理失败)，之后，第一系统可以将该幂等标识对应的处理状态作为查询结果发送给第二系统。如此，对于异步的业务请求，可以不受网络或设备造成的时序混乱的影响，使得跨域业务发生的两个系统对跨域业务的处理状态记录保持一致。进一步地，可以提高跨域业务的有效性。

根据另一方面的实施例，还提供一种对跨域业务请求的处理装置。该装置的应用场景包括：针对一个第二系统向第一系统请求的跨域业务，第二系统向第一系统发送处理请求后，经过预定时间间隔再向第一系统发送查询请求，以查询第一系统对跨域业务的处理状态。图5示出根据一个实施例的对跨域业务请求的处理装置的示意性框图。装置500可以设于上述的第一系统中。

如图5所示，装置500包括：获取单元51，配置为在第一时刻，接收查询请求，该查询请求由第二系统在发出处理请求之后的预定时间间隔之后发出，用于查询处理请求中的跨域业务的处理状态，查询请求包括与处理请求一致的、与跨域业务对应的业务标识；提取单元52，配置为从查询请求提取跨域业务的幂等标识，其中，幂等标识至少包括业务标识，幂等标识至少用于查询和/或记录跨域业务的处理状态；确定单元53，配置为基于对幂等标识的查询，确定跨域业务的处理状态，其中，在未查询到幂等标识的情况下，记录幂等标识，并确定幂等标识对应的处理状态为预设状态；发送单元54，将幂等标识对应的处理状态作为查询结果发送给第二系统。

根据一方面的实施例，确定单元53还可以配置为：

在查询到上述幂等标识的情况下，获取上述幂等标识对应的处理状态。

在一个可能的设计中，装置500还包括业务处理单元(未示出)，配置为：

在第二时刻，接收到针对上述跨域业务的处理请求，该处理请求包括上述幂等标识；从处理请求中提取幂等标识；按照幂等标识的幂等性对处理请求进行处理。

具体地，业务处理单元可以对该幂等标识进行查询；

一方面，在第二时刻早于第一时刻的情况下，查询不到该幂等标识，业务处理单元可以记录幂等标识，并对该跨域业务进行处理，以将对该跨域业务的处理结果记录为上述幂等标识对应的处理状态；

另一方面，在第二时刻晚于第一时刻的情况下，查询到该幂等标识，业务处理单元可以确定无需对上述跨域业务进行处理。

在一个实施例中，幂等标识和对应跨域业务的处理状态通过业务幂等表记录，业务幂等表可以用于以幂等标识为索引记录与相应跨域业务的处理状态。

在一个实施例中，上述业务标识还可以包括但不限于：第二系统的系统标识、时间标识中的至少一项。

值得说明的是，图5所示的装置500是与图4示出的方法实施例相对应的装置实施例，图4示出的方法实施例中的相应描述同样适用于装置500，在此不再赘述。

通过以上装置，对于第二系统发送来的包含相同的业务标识，并可以提取到相同幂等标识的处理请求和查询请求，可以按照首先处理的请求落地幂等标识，如果查询请求先于处理请求到达，可以将幂等标识对应的处理状态落地(记录)为处理失败。如此，对于异步的业务请求，可以不受网络或设备造成的时序混乱的影响，使得跨域业务发生的两个系统对跨域业务的处理状态记录保持一致，从而提高跨域业务的有效性。

根据另一方面的实施例，还提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行结合图4所描述的方法。

根据再一方面的实施例，还提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现结合图4所述的方法。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。