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

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

背景技术：

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

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

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

技术实现要素：

本说明书一个或多个实施例描述了一种对跨域业务请求进行处理的方法和装置，以及一种对跨域业务的请求方法和装置，分别用于跨域业务中的两个系统，对跨域业务中可能出现的时序混乱进行规避，保障跨域业务发生的两个系统中，业务状态的一致性。

根据第一方面，提供了一种处理跨域业务请求的方法，所述跨域业务包括发生在第一系统和第二系统之间的业务，所述方法通过所述第一系统执行，包括：在第一时刻，获取来自所述第二系统的对跨域业务的处理请求，其中，所述处理请求中包含对所述跨域业务进行处理的处理时间条件；检测所述第一时刻是否满足所述处理时间条件；在所述第一时刻满足所述处理时间条件的情况下，对所述跨域业务进行处理，得到处理结果；在所述第一时刻不满足所述处理时间条件的情况下，确定对所述跨域业务的处理结果包括处理失败。

根据一个可能的实施例，所述检测所述第一时刻是否满足所述处理时间条件包括：根据所述处理时间条件确定允许处理所述处理请求的最晚时间；将所述第一时刻与所述最晚时间进行对比；在所述第一时刻早于所述最晚时间的情况下，确定所述第一时刻满足所述处理时间条件；否则，确定所述第一时刻不满足所述处理时间条件。

根据一种可能的设计，所述方法还包括：在第二时刻，接收到来自所述第二系统针对所述跨域业务的查询请求，所述查询请求于第三时刻从所述第二系统发出，所述第三时刻晚于通过所述处理时间条件限定的允许处理所述跨域业务的最晚时间；获取对所述跨域业务的查询结果，并向所述第二系统反馈所述查询结果。

进一步地，在一个实施例中，在所述第二时刻早于所述第一时刻的情况下，所述查询结果包括以下中的一项：未接收到相应的处理请求；处理失败；等待处理。

在另一个实施例中，在所述第二时刻晚于所述第一时刻的情况下，所述查询结果包括对所述跨域业务进行处理得到的处理结果。

根据第二方面，提供一种对跨域业务的请求方法，所述跨域业务包括发生在第一系统和第二系统之间的业务，所述方法通过所述第二系统执行，所述方法包括：向所述第一系统发送所述跨域业务的处理请求，所述处理请求包含对所述跨域业务进行处理的处理时间条件；基于所述处理时间条件，确定对所述跨域业务的查询起始时间，其中，所述查询起始时间不早于通过所述处理时间条件确定的、允许所述第一系统处理所述跨域业务的最晚时间；根据所述查询起始时间，向所述第一系统发送查询请求，以获取所述第一系统对所述跨域业务处理情况的查询结果。

根据一个实施方式，所述查询结果包括以下至少一项：

所述第一系统按照所述处理时间条件获取的对所述跨域业务的处理结果；

所述第一系统未接收到所述处理请求的结果。

在一个实施例中，所述根据所述查询起始时间，向所述第一系统发送查询请求包括：从所述查询起始时间开始，向所述第一系统循环发送查询请求，直至接收到对所述跨域业务的查询结果。

根据第三方面，提供一种处理跨域业务请求的装置，所述跨域业务包括发生在第一系统和第二系统之间的业务，所述装置设于所述第一系统，所述装置包括：获取单元，配置为在第一时刻，获取来自所述第二系统的对跨域业务的处理请求，其中，所述处理请求中包含对所述跨域业务进行处理的处理时间条件；检测单元，配置为检测所述第一时刻是否满足所述处理时间条件；处理单元，配置为：在所述第一时刻满足所述处理时间条件的情况下，对所述跨域业务进行处理，得到处理结果；在所述第一时刻不满足所述处理时间条件的情况下，确定所述跨域业务处理失败。

根据第四方面，提供一种用对跨域业务的查询装置，所述跨域业务包括发生在第一系统和第二系统之间的业务，所述装置设于所述第二系统，所述装置包括：发送单元，配置为向所述第一系统发送所述跨域业务的处理请求，所述处理请求包含对所述跨域业务进行处理的处理时间条件；确定单元，配置为基于所述处理时间条件，确定对所述跨域业务的查询起始时间，其中，所述查询起始时间不早于通过所述处理时间条件确定的、允许所述第一系统处理所述跨域业务的最晚时间；所述发送单元，还配置为根据所述查询起始时间，向所述第一系统发送查询请求，以获取所述第一系统对所述跨域业务处理情况的查询结果。

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

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

通过本说明书实施例提供的处理跨域业务请求的方法和装置，以及对跨域业务的请求方法和装置，对于发生在第一系统和第二系统之间的跨域业务，在第二系统向第一系统发送对跨域业务的处理请求时，通过设置对跨域业务进行处理的处理时间条件，使得：第一系统在对跨域业务进行处理之前，先判断当前时间是否满足处理时间条件，并基于检测结果确定对处理请求的处理结果；第二系统在发出对跨域业务的处理请求之后，至少在处理时间条件限定的第一系统对跨域业务进行处理的最晚时间，向第一系统发送对跨域业务处理情况的查询请求。如此，可以对跨域业务中可能出现的时序混乱进行规避，从而可以提高跨域业务的有效性。

附图说明

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

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

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

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

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

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

具体实施方式

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

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

图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中，第二系统向第一系统发送业务1的处理请求时，可以在处理请求中包含对处理请求进行处理的处理时间条件。第一系统在获取该处理请求时，可以先检测处理时间条件是否满足。并根据检测结果确定处理请求是否有效，根据处理请求是否有效来获取对处理请求的处理结果。在一个实施例中，如果处理时间条件满足，则确定处理请求有效。处理请求有效，则处理结果为第一系统正常处理业务1得到的结果。在另一个实施例中，如果处理时间条件不满足，则确定处理请求无效。处理请求无效，则可以确定处理结果为处理失败。另一方面，第二系统可以按照上述处理时间条件向第一系统发送查询请求。亦即，在满足处理时间条件之外的时刻再发送查询请求。例如，第二系统在t时刻向第一系统发送了业务1的处理请求，处理请求包含的处理时间条件为t+h，即仅在t+h时刻内，第一系统可以确定业务1有效，而进行处理，否则，确定业务1无效。而第二系统在t+h时刻之后向第一系统发送查询请求。如此，可以保证第一系统不会在返回查询结果之后又对同一跨域业务的处理请求进行处理。

为了更明确本说明书实施例在上述场景下的有益效果，请参考图3。假设仍然出现图2所示的问题，查询请求先于处理请求到达第一系统。如图3所示，在t时刻，第二系统向第一系统发送业务1的处理请求，与图1、图2不同的是，在图3中发送的处理请求包含了对业务1进行处理的处理时间条件，例如是t+h时刻之前处理。假设第一系统在t+h时刻之前没有收到该处理请求。在t时刻，第二系统又向第一系统发送了业务1的查询请求，其中，t时刻不早于t+h时刻(t≥t+h)。第一系统向第二系统返回查询结果，例如是未接收到该处理请求。假设在t时刻之后的某个时刻t+s(t+s≥t+h)，第一系统接收到了该业务1的处理请求，且欲处理该业务。则第一系统先根据处理时间判断t+s时刻是否满足上述处理时间条件，即在t+h时刻之前处理该业务1。经过判断，t+s时刻晚于t+h时刻，则可以确定处理请求无效，从而获取对处理请求处理失败的处理结果。这样，在第一系统和第二系统中，对于业务1，处理结果保持一致。例如业务1为上述支付业务，则第一系统实际未进行支付，和第二系统得到的处理失败的结果一致。

如此，针对第二系统向第一系统发送跨域业务的处理请求时，通过在该处理请求中加入处理时间条件：一方面，第二系统根据该处理时间条件确定处理请求是否有效，对有效的处理请求，处理相关跨域业务得到处理结果，对超出处理时间条件限定的时间范围的处理请求确认无效，并获取对跨域业务处理失败的处理结果；另一方面，第一系统在处理请求发出后，根据处理时间条件确定查询起始时间，避免在处理请求有效的时间内发出查询请求，造成图2所示的情形。从而，可以对跨域业务中可能出现的时序混乱情况进行规避，提高跨域业务的有效性。

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

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

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

如图4示，该方法可以包括以下步骤：步骤41，在第一时刻，获取来自第二系统的对跨域业务的处理请求，其中，处理请求中包含对跨域业务进行处理的处理时间条件；步骤42，检测第一时刻是否满足处理时间条件；步骤43，基于检测结果获取对跨域业务的处理结果，其中：在第一时刻满足处理时间条件的情况下，对跨域业务进行处理，得到处理结果；在第一时刻不满足处理时间条件的情况下，确定对跨域业务的处理结果包括处理失败。

首先，通过步骤41，在第一时刻，获取来自第二系统的对跨域业务的处理请求。可以理解，跨域业务的处理请求是由第二系统发送来的，该处理请求可能被立即处理，也可能被放入缓存的任务序列等待处理。因此，这里的第一时刻可以是第一系统接收到该跨域业务的处理请求的时刻，也可以是第一系统按照缓存中的任务顺序，执行到跨域业务的处理请求的时刻。

其中，上述跨域业务的处理请求中还可以包含对处理请求进行处理的处理时间条件。该处理时间条件可以用于限定处理请求的有效时限。处理时间条件的形式可以有多种。例如，在一个实施例中，该处理时间条件可以为30秒，表示从第二系统向第一系统发起处理请求的时刻(如上午9点20分10秒09:20:10)开始，仅仅在该时刻后的30秒内(如09:20:10至09:20:40)，允许第一系统正常处理该跨域业务。本领域技术人员容易理解，对于第二系统向第一系统发起处理请求的时刻，可以通过处理请求中的时间戳等获得，在此不再赘述。再例如，在另一个实施例中，该处理时间条件可以为截止时间(如09:20:40)，用于表示第一系统可以正常处理该跨域业务的最晚时间。实践中，处理时间条件还可以是通过各种其他方式表示的条件，在此不再一一例举。

接着，在步骤42，检测第一时刻是否满足处理时间条件。可以理解，由于处理时间条件可以用于确定处理请求的有效时限，所以可以通过第一时刻是否满足处理时间条件来确定处理请求是否有效。

在一个实施例中，检测第一时刻是否满足处理时间条件，可以通过判断第一时刻是否落入处理时间条件限定的时间范围内来进行。例如，在处理时间条件为在从第二系统发送处理请求起的30秒内，允许第一系统处理相应跨域业务的情况下，根据从第二系统发送处理请求的时刻，如09:20:10，以及处理时间条件，可以确定处理该跨域业务的时间范围为，09:20:10至09:20:40。此时，可以检测第一时刻是否落入该时间范围09:20:10至09:20:40。如果落入，则检测结果为第一时刻满足处理时间条件，否则，检测结果可以为不满足处理时间条件。

在另一个实施例中，检测第一时刻是否满足处理时间条件，可以通过判断第一时刻是否落入处理时间条件限定的最晚处理时间来进行。此时，可以先根据处理时间条件确定允许处理跨域业务的最晚时间(如09:20:40)，然后将第一时刻(如09:20:35)与该最晚时间进行对比，并且，在该第一时刻早于该最晚时间的情况下，确定该第一时刻满足处理时间条件，否则，确定该第一时刻不满足处理时间条件。

在其他实施例中，检测第一时刻是否满足处理时间条件还可以通过其他合理的方式进行，在此不再赘述。值得说明的是，在以上具体例子中，时刻以秒为最小单位进行计算，实践中，为了使处理时间条件更加精确，还可以通过毫秒、微秒等单位进行计算，本说明书实施例对此不作限定。

进一步地，根据以上检测结果可以确定处理请求是否有效。通常，在第一时刻满足处理时间条件的情况下，确定处理请求有效，在第一时刻不满足处理时间条件的情况下，确定处理请求无效。但根据处理时间条件的不同设置方式，也可能得到相反的结论。例如，如果处理时间条件为“晚于09:20:40，不再处理该跨域业务”，则在第一时刻满足处理时间条件“晚于09:20:40”的情况下，确定处理请求无效。

然后，在步骤43中，根据检测结果获取对跨域业务的处理结果。可以理解，如果上述处理请求有效，则第一系统可以对该处理请求所涉及的跨域业务正常处理，否则，不再处理该跨域业务。

一方面，在处理请求有效的情况下，对跨域业务正常处理出现的处理结果可能包括：处理成功或处理失败。举例而言，当跨域业务为支付业务时，第一系统需要将数据库中各个对应的账户余额增加或减少相应数值。如果对数据库操作正常，则处理结果可以为处理成功，但是如果出现诸如数据库无法访问、用户对应的账户余额减少相应数值会成为负值之类的情况时，则处理结果可能为处理失败。

另一方面，在处理请求无效的情况下，第一系统对跨域业务可以不作处理。此时，可以确定对跨域业务的处理结果包括处理失败。值得说明的是，处理失败的表达方式可以有多种，例如扣款失败、请求过期等等。

如此，第一系统可以在获取跨域业务的处理请求时，先根据处理请求中包含的处理时间条件，判断处理请求是否有效，并根据处理请求是否有效来获取跨域业务的处理结果，避免了网络或硬件设备原因造成的处理请求接收滞后，无限期处理的情况。

根据一种实施方式，该处理跨域业务请求的方法还可以包括以下步骤：

在第二时刻，接收到来自第二系统针对跨域业务的查询请求，查询请求于第三时刻从第二系统发出，第三时刻晚于通过处理时间条件限定的允许处理跨域业务的最晚时间；获取对跨域业务处理情况的查询结果，并向第二系统反馈查询结果。

可以理解，第二系统在向第一系统发出对跨域业务的处理请求后，经过一定时间间隔后的第三时刻，还可以向第一系统发出对跨域业务的查询请求，以确定跨域业务的处理情况，并根据跨域业务的处理情况进行后续数据处理。其中，为了保证第一系统在处理请求的有效时限内开始处理跨域业务都能得到相应的处理结果以供查询，第三时刻可以是不在有效时限内的一个时刻。例如，第三时刻可以晚于通过处理时间条件限定的允许处理跨域业务的最晚时间。

在第二时刻，第一系统接收到第二系统发送来的查询请求，此时，第一系统可以查询上述跨域业务。具体地：

一方面，如果第二时刻早于第一时刻，就是说第一系统还没有处理该跨域业务，也不会记录有跨域业务的处理结果，则第一系统可以向第二系统返回诸如请求超时、未接收到相关业务请求、未处理或等待处理、处理失败之类的信息作为查询结果；

另一方面，在第二时刻晚于第一时刻的情况下，如果处理请求有效，并且第一系统已经对跨域业务进行处理并获取了处理结果，该处理结果可能是处理成功或者处理失败，则第一系统可以将对处理请求的处理结果作为查询结果返回第二系统。如果处理请求有效，但第一系统仍正在处理该跨域业务，则第一系统可以返回诸如处理中之类的查询结果。如果处理请求无效，则第一系统还可以向第二系统返回处理失败之类的查询结果。

其中，在一些实现中，如果查询结果是确定的处理结果，如处理成功、处理失败、未接收到等时，第二系统可以终止查询，如果查询结果是处理中等时，第二系统可以继续向第一系统发送查询请求，直至查询到确定的处理结果。

通过第二系统在处理请求的有效时限之后发送查询请求，可以进一步避免查询到确定处理结果后又收到处理请求，对跨域业务进行处理，造成的数据混乱现象。

图5示出根据一个实施例的对跨域业务的请求方法流程图。其中的跨域业务是发生在两个系统间的业务，例如发生在网络购物平台和网络支付平台之间的支付业务、发生在某个银行系统的前置子系统和账务子系统之间的存取款业务等等。这里，网络购物平台和网络支付平台就是两个系统，例如分别是图1～图3所示的第一系统和第二系统。该方法的执行主体可以是图1～图3所示的第二系统等。该第二系统可以是任何具有计算、处理能力的系统、设备、装置、平台或服务器。需要明确的是，该对跨域业务的查询的流程适用于第二系统向第一系统发出对某个跨域业务的处理请求之后，经过预定的时间间隔(如30秒)，再去向第一系统查询该跨域业务的处理状态的过程。

如图5示，该方法包括以下步骤：步骤51，向第一系统发送跨域业务的处理请求，处理请求包含对跨域业务进行处理的处理时间条件；步骤52，基于上述处理时间条件，确定对跨域业务的查询起始时间，其中，查询起始时间不早于通过处理时间条件确定的、允许第一系统处理跨域业务的最晚时间；步骤53，根据查询起始时间，向第一系统发送查询请求，以获取第一系统对跨域业务处理情况的查询结果。

首先，在步骤51，向第一系统发送跨域业务的处理请求，处理请求包含对跨域业务进行处理的处理时间条件。在本说明书实施例中，第二系统向第一系统发出跨域业务的处理请求时，可以在处理请求中包含处理时间条件，用于第一系统确定处理请求的有效时限。例如，第一系统可以根据该处理时间条件确定出对跨域业务进行处理的有效时限或最晚时间等。

第二系统在向第一系统发送跨域业务的处理请求时，可以先获取跨域业务，根据预设的处理时间条件生成规则(如当前时间增加30秒作为最晚处理时间等)，或者人为指定的处理时间，确定处理时间条件，并将跨域业务和处理时间条件生成跨域业务的处理请求。该处理请求可以是通过网络设备间通过确定的通信协议约定格式的各种请求消息，例如http请求、android-http异步请求等等，本说明书实施例对此不作限定。

接着，在步骤52，基于上述处理时间条件，确定对跨域业务的查询起始时间。可以理解，查询起始时间就是开始查询的时间。也就是说，对跨域业务的查询可以是一次，也可以是多次，而查询起始时间可以是第一次发起查询请求的时间。可以理解，为了确保第一系统不会在接收到第二系统发送的查询请求之后，再开始处理相应的跨域业务，第二系统可以先确定发起查询请求的查询起始时间不早于允许第一系统处理跨域业务的最晚时间。

然后，在步骤53，根据查询起始时间，向第一系统发送查询请求，以获取第一系统对跨域业务处理情况的查询结果。其中，该查询结果可以用于跨域业务的进展状况。例如，在第一系统未接收到相应跨域业务的处理请求的情况下，查询结果可能是未接收到处理请求。在第一系统接收到相应跨域业务的处理请求的情况下，查询结果可以是第一系统按照处理时间条件获取的对跨域业务的处理结果。此时，该处理结果可能是处理成功，也可能是处理失败。举例而言，如果第一系统在获取了相应跨域业务的处理请求，并通过判断，该获取时刻不符合处理时间条件，则该处理请求无效，第一系统可以将对相应跨域业务的处理结果确定为处理失败。如果通过判断，该获取时刻符合处理时间条件，则该处理请求有效，第一系统对该跨域业务进行处理。在第一系统对该跨域业务进行处理的过程中，如果顺利完成，则处理结果可以为处理成功，否则(如数据库操作失败等)，处理结果可以为处理失败。

在一个实施例中，查询请求到达第一系统时，第一系统还可能正在处理相应的跨域业务，此时，查询结果还可以是诸如“正在处理”、“数据异常”、“服务器忙”等等之类的结果。

根据一种实施方式，第二系统仅发送一次查询请求。在接收到任意查询结果后可以停止查询。如果接收到第一系统正在处理相应的跨域业务的查询结果，还可以向第一系统发送终止业务的请求。

根据另一种实施方式，第二系统可以多次发送查询请求。例如，可以从查询起始时间开始，向第一系统循环发送查询请求，直至接收到对跨域业务的预定查询结果。该预定查询结果例如可以是处理成功、处理失败、未接收到之类的查询结果。这样，在接收到诸如“正在处理”这样的查询结果的情况下，可以由第一系统继续处理跨域业务，直至处理完毕。

可以理解，本说明书实施例中“处理成功”、“处理失败”、“正在处理”之类的查询结果或处理结果仅仅是结果状态的一种表达方式，实践中也可以使用其他表达方式，本说明书实施例对此不作限定。

需要指出，图4示出的实施例和图5示出的实施例，分别适应于跨域业务发生的第一系统和第二系统。第二系统和第一系统分别作为请求和处理跨域业务的一端，在配合完成跨域业务的过程，有一些信息的交互，因此一些概念、流程是可以相互适应或补充的。

值得说明的是，第一系统对跨域业务进行处理的处理模块和用于处理查询请求的查询模块，可以是设置在一起，也可以分开设置。例如，处理模块可以将处理结果写入数据库，查询系统只针对数据库进行查询，等等。

回顾以上过程，对于发生在第一系统和第二系统之间的跨域业务，通过在发送处理请求时设置处理时间条件：一方面，接收处理请求的一方在获取处理请求时，先根据处理时间条件检测处理请求是否有效，并根据处理请求是否有效获取处理结果；另一方面，发送处理请求的一方可以根据处理时间条件确定开始发送查询请求的查询起始时间，以免在处理请求仍有效的情况下向另一方进行跨域业务的结果查询，造成两方结果不一致。如此，可以规避跨域业务中可能出现的时序混乱现象，从而使第一系统和第二系统中，跨域业务的业务状态记录一致。进一步地，提高了跨域业务的有效性。

根据另一方面的实施例，还提供一种处理跨域业务请求的装置。跨域业务包括发生在第一系统和第二系统之间的业务。图6示出根据一个实施例的处理跨域业务请求的装置的示意性框图。该装置600可以适应于图1～图3所示的第一系统中。

如图6所示，处理跨域业务请求的装置600包括：获取单元61，配置为在第一时刻，获取来自第二系统的对跨域业务的处理请求，其中，处理请求中包含对处理请求进行处理的处理时间条件，处理时间条件用于确定处理请求的有效时限；检测单元62，配置为检测第一时刻是否满足处理时间条件；处理单元63，配置为根据检测结果，获取对跨域业务的处理结果，其中，在第一时刻满足处理时间条件的情况下，对跨域业务进行处理，得到处理结果；在第一时刻不满足处理时间条件的情况下，确定跨域业务处理失败。

根据一个实施方式，检测单元62进一步还可以配置为：根据处理时间条件确定允许处理跨域业务的最晚时间；将第一时刻与最晚时间进行对比；在第一时刻早于最晚时间的情况下，确定第一时刻满足处理时间条件；否则，确定第一时刻不满足所述处理时间条件。

根据一个可能的设计，装置600还包括查询单元(未示出)。该查询单元可以配置为：在第二时刻，接收到来自第二系统针对跨域业务的查询请求，查询请求于第三时刻从第二系统发出，第三时刻晚于通过处理时间条件限定的允许处理跨域业务的最晚时间；获取对跨域业务的查询结果，并向第二系统反馈查询结果。

根据一种实现方式，在第二时刻早于第一时刻的情况下，查询单元获取的查询结果可以包括以下中的一项：未接收到相应的处理请求；处理失败；等待处理

根据另一种实现方式，在第二时刻晚于第一时刻的情况下，如果处理请求有效，并且处理单元63已经对跨域业务进行处理并获取了处理结果，该处理结果可能是处理成功或者处理失败。如果处理请求有效，但处理单元63仍正在处理该跨域业务，则第一系统可以返回诸如处理中之类的查询结果。如果处理请求无效，则查询单元还可能得到处理单元63确定的处理失败之类的处理结果作为查询结果。

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

根据又一方面的实施例，本说明书还提供一种对跨域业务的查询装置。跨域业务包括发生在第一系统和第二系统之间的业务。图7示出根据一个实施例的对跨域业务的查询装置的示意性框图。该装置700可以适应于图1～图3所示的第二系统中。

如图7所示，对跨域业务的查询装置700包括：发送单元71，配置为向第一系统发送跨域业务的处理请求，处理请求包含对跨域业务进行处理的处理时间条件；确定单元72，配置为基于上述处理时间条件，确定对跨域业务的查询起始时间，其中，查询起始时间不早于通过处理时间条件确定的、允许第一系统处理跨域业务的最晚时间；发送单元71，还配置为根据查询起始时间，向第一系统发送查询请求，以获取第一系统对跨域业务的查询结果。

在一个实施例中，上述查询结果可以包括第一系统按照处理时间条件获取的对跨域业务的处理结果。

在另一个实施例中，上述查询结果可以包括第一系统未接收到跨域业务的处理请求的结果。

根据一种可能的设计，发送单元71还可以配置为：从查询起始时间开始，向第一系统循环发送查询请求，直至接收到对跨域业务的预定查询结果。

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

通过以上装置600和700，分别设于图1～图3示出的两个系统中，基于处理时间条件的设置，为跨域业务限定处理时限。从而，使得跨域业务不会在处理时限之外被处理，对跨域业务的查询不会在处理时限之内发出。从而对业务时限进行有序管理，使发生跨域业务的两个系统保持一致，提高跨域业务处理的有效性。

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

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

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

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