CN104601696A - 服务处理方法、服务调用框架、装置和架构 - Google Patents

Abstract

本发明公开了一种服务处理方法、服务调用框架、装置和架构，该方法包括：接收第一子系统发送的服务调用请求，所述服务调用请求包括服务数据；保存任务信息以及所述服务数据，所述任务信息用于标识所述第一子系统请求的服务；根据所述任务信息确定所述第一子系统请求的服务的处理情况；在所述处理情况为未处理或处理失败时，根据所述服务数据向第二子系统调用所述第一子系统请求的服务。通过本发明，基于保存的任务信息确定服务未处理或处理失败的情况下根据服务数据调用第二子系统，能够有效地提高子系统之间交互的性能，并提高服务调用的成功率。

Description

服务处理方法、服务调用框架、装置和架构

技术领域

本发明实施例涉及计算机技术领域，并且更具体地，涉及一种服务处理方法，服务调用框架，装置和架构。

背景技术

目前，大型系统(如大型网站)是基于SOA(Service-OrientedArchitecture，面向服务的体系架构)来实现的。整个系统被细分成多个子系统，子系统之间通过服务调用框架进行交互，如通过分布式服务调用框架采用同步调用方式来实现子系统之间的交互，以此提高系统的效率。

当子系统之间进行交互时，例如，某个子系统通过服务调用框架调用其它子系统的服务(如业务处理)，如果出现如几个子系统的接口并发量很大或者接口处理的业务较复杂等情况时，由于在高并发时使得业务来不及处理或者业务复杂处理时间长，将会出现服务超时的现象，从而导致业务处理失败。

发明内容

本发明实施例提供一种服务处理方法，服务调用框架，子系统和架构，能够提高子系统之间交互的性能，并提高服务调用的成功率。

第一方面，提供了一种服务处理方法，该方法包括：接收第一子系统发送的服务调用请求，所述服务调用请求包括服务数据；保存任务信息以及所述服务数据，所述任务信息用于标识所述第一子系统请求的服务；根据所述任务信息确定所述第一子系统请求的服务的处理情况；在所述处理情况为未处理或处理失败时，根据所述服务数据向第二子系统调用所述第一子系统请求的服务。

第二方面，提供了一种服务处理方法，该方法包括：生成服务调用请求，所述服务调用请求包括服务数据；向服务调用框架发送所述服务调用请求，以便所述服务调用框架保存任务信息以及所述服务数据，其中，所述任务信息用于标识请求的服务且由所述服务调用框架用于确定所述服务的处理情况，所述服务数据由所述服务调用框架用于在所述处理情况为未处理或处理失败时，向下游子系统调用所述服务。

第三方面，提供了一种服务处理方法，该方法包括：当服务调用框架根据任务信息确定第一子系统请求的服务的处理情况为未处理或处理失败时，接收所述服务调用框架发送的服务数据；根据所述服务数据向所述服务调用框架提供所述第一子系统请求的服务；其中，所述任务信息用于标识所述第一子系统请求的服务且保存在所述服务调用框架中，所述服务数据包含在所述服务调用请求中并保存在所述服务调用框架中。

第四方面，提供了一种服务调用框架，该服务调用框架包括接收单元，存储单元，确定单元和调用单元，其中所述接收单元，用于接收第一子系统发送的服务调用请求，所述服务调用请求包括服务数据；所述存储单元，用于保存任务信息以及所述接收单元接收的所述服务数据，其中所述任务信息用于标识所述第一子系统请求的服务；所述确定单元，用于根据所述存储单元保存的所述任务信息确定所述第一子系统请求的服务的处理情况；所述调用单元，用于在所述确定单元确定的所述处理情况为未处理或处理失败时，根据所述服务数据向第二子系统调用所述第一子系统请求的服务。

第五方面，提供了一种用于请求调用服务的装置，该用于请求调用服务的装置包括生成单元和发送单元，其中生成单元用于生成服务调用请求，所述服务调用请求包括服务数据；发送单元用于向服务调用框架发送所述服务调用请求，以便所述服务调用框架保存任务信息以及所述服务数据，其中，所述任务信息用于标识所述装置请求的服务且由所述服务调用框架用于确定所述装置请求的服务的处理情况，所述服务数据由所述服务调用框架用于在所述处理情况为未处理或处理失败时，向下游子系统调用所述装置请求的服务。

第六方面，提供了一种用于处理服务的装置，该用于处理服务的装置包括接收单元和提供单元，其中接收单元，用于当服务调用框架根据任务信息确定上游子系统请求的服务的处理情况为未处理或处理失败时，接收所述服务调用框架发送的服务数据；提供单元，用于根据所述接收单元接收的服务数据向所述服务调用框架提供所述上游子系统请求的服务；其中，所述任务信息用于标识所述上游子系统请求的服务且保存在所述服务调用框架中，所述服务数据包含在所述服务调用请求中并保存在所述服务调用框架中。

第七方面，提供了一种服务处理架构，包括第一子系统，第二子系统和服务调用框架，其中所述第一子系统，用于向所述服务调用框架发送服务调用请求，所述服务调用请求包括服务数据；所述服务调用框架用于接收所述第一子系统发送的所述服务调用请求，保存任务信息以及所述服务数据，根据所述任务信息确定所述第一子系统请求的服务的处理情况，在所述处理情况为未处理或处理失败时，根据所述服务数据向所述第二子系统调用所述第一子系统请求的服务，其中所述任务信息用于标识所述第一子系统请求的服务；所述第二子系统用于提供所述第一子系统请求的服务。

在本发明实施例中，通过服务调用框架保存了与第一子系统请求的服务对应的任务信息和服务数据，基于保存的任务信息可以获知当前第一子系统请求的服务的处理情况，如果当前还未处理该第一子系统请求的服务或者该服务处理失败，则服务调用框架可以根据服务数据向第二子系统调用该服务。因此，在业务未处理或处理失败导致业务超时的情况时，不会导致子系统之间交互的中断，从而提高了子系统之间交互的性能。另外，在出现业务超时时，本发明的服务调用框架也可以采用异步调用方式，重新调用第二子系统提供的第一子系统所请求的服务，因而避免了业务操作的失败，提高服务调用的成功率。

附图说明

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

图1是本发明一个实施例的服务处理方法的示意性流程图。

图2是本发明一个实施例的服务器集群的示意图。

图3是本发明一个实施例的服务处理方法的示意性流程图。

图4是本发明一个实施例的服务处理方法的示意性流程图。

图5是本发明一个实施例的服务处理架构的示意图。

图6是本发明一个实施例的服务处理方法的过程的示意性流程图。

图7是本发明一个实施例的服务调用框架的示意性结构框图。

图8是本发明一个实施例的用于请求调用服务的装置的示意性结构框图。

图9是本发明一个实施例的用于处理服务的装置的示意性结构框图。

图10是本发明一个实施例的服务处理架构的示意性结构框图。

图11是本发明一个实施例的设备的示意框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都应属于本发明保护的范围。

图1是本发明一个实施例的服务处理方法的过程的示意性流程图。图1的方法可以由服务调用框架执行，包括：

步骤101，接收第一子系统发送的服务调用请求，该服务调用请求包括服务数据。

第一子系统通过服务调用框架调用第二子系统提供的服务。第一子系统还可以称为“上游子系统”，在本发明中即为用于请求调用服务的装置，相应地，第二子系统也可以称为“下游子系统”，在本发明中即为用于处理服务的装置。服务数据可以是业务数据报文，例如订购数据，支付数据，登录数据，搜索数据或音/视频数据等。服务类型还可以是除web服务外的其它服务。应理解，本发明对服务类型和内容不作限制。该服务调用请求还可以包括第二子系统的标识和服务标识(如业务标识)。

步骤102，保存任务信息以及服务数据，该任务信息用于标识第一子系统请求的服务。

任务信息可以唯一标识第一子系统请求的服务，例如任务信息可以是由服务调用框架生成的与该服务调用请求对应的标识，也可以是服务调用请求中的业务标识，更具体地，如订单号。应理解，本发明对于任务信息并不限定。

步骤103，根据任务信息确定第一子系统请求的服务的处理情况。

步骤104，在处理情况为未处理或处理失败时，根据服务数据向第二子系统调用第一子系统请求的服务。

在本发明实施例中，通过服务调用框架保存了与第一子系统请求的服务对应的任务信息和服务数据，基于保存的任务信息可以获知当前第一子系统请求的服务的处理情况，如果当前还未处理该第一子系统请求的服务或者该服务处理失败，则服务调用框架可以根据服务数据向第二子系统调用该服务，因此，在业务未处理或处理失败导致业务超时的情况时，不会导致子系统之间交互的中断，从而提高了子系统之间交互的性能。

另外，在高并发的情况下，即使出现服务超时现象，本发明的服务调用框架也可以采用异步调用方式，重新调用第二子系统提供的第一子系统所请求的服务，因而避免业务操作的失败，提高了服务调用的成功率。

可选地，作为一个实施例，在步骤102中，可以根据数据类型确定不同的存储空间，如将任务信息存储到第一存储空间(如DB(数据库，Database))，将报文存储到第二存储空间(如文件存储系统)，还可以设置第三存储空间来存储索引信息，以便快速定位存储的数据。具体地，可以通过分库分表的形式来进行存储(如通过服务器集群形式来实现)。例如，通过分库适配器路由到数据库，将任务信息保存到在数据库中存储的任务表中，通过分库适配器路由到文件存储系统，在文件存储系统中存储服务数据，并通过分库适配器路由到消息队列(消息队列可以包括发送者和消费者，分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行--它们可以不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息)，在消息队列中存储任务信息和服务数据的存储索引信息(如关键字key或标识)，例如，任务信息所在数据库所在任务表的ID(标识，Identification)。

通过上述存储方式，能够快速地定位到保存的数据，从而提高效率。

可选地，作为另一个实施例，可以利用定时触发系统来触发步骤103。

在一种可能的实现方式下，利用定时器触发读取任务信息，当扫描到读取的任务信息指示服务未处理或处理失败时，确定第一子系统请求的服务的处理情况为未处理或处理失败。具体地，在接收到上游子系统或保存任务信息时定时器开始计时，当定时器到时时，根据消息队列中存储的索引信息定位到数据库中存储的任务表，该任务表可能保存了一些任务信息以及相应的服务的处理情况(已处理或未处理或处理失败)，扫描任务表确定第一子系统请求的服务的处理情况，对为处理或处理失败的服务，服务调用框架可以调用第二子系统提供的服务。

在另一种可能的实现方式下，保存的与调用成功的服务(已处理的服务)相对应的任务信息已被删除，利用定时器触发读取任务信息，如果读取到与第一子系统请求的服务对应的任务信息时，则可以确定第一子系统请求的服务未处理或处理失败。

应理解，上述实现方式仅仅是示例性的，本发明对确定第一子系统请求的服务是否处理的方式不做限制。

还需要说明的是，服务调用框架可以设定定时器的周期，周期性地触发读取存储在数据库中的任务表，当然，服务调用框架也可以设定采用分布式定时触发系统，如针对第一子系统请求的服务具有一个预设时间阈值，在接收到第一子系统发送的服务调用请求或保存任务信息时开启定时器，当定时器达到预设时间阈值时，触发读取任务信息。

可选地，作为另一个实施例，在步骤104中，服务调用框架可以基于消息队列向第二子系统调用第一子系统请求的服务。例如，设置服务的优先级，在高并发的情况下，优先调用优先级高的服务。

可选地，作为另一个实施例，可以更新存储的任务信息，例如，在步骤104之后，当服务调用框架调用第二子系统提供的第一子系统请求的服务成功后，可以将存储的标识该第一子系统请求的服务的任务信息删除，也可以将该任务信息对应的服务处理情况修改为已处理。

可选地，作为另一个实施例，在步骤104之后，可以向第一子系统返回处理结果，处理结果表示服务调用成功或服务调用失败。

可选地，作为另一个实施例，可以针对第一子系统请求的服务统计调用次数，其中调用次数表示向第二子系统调用第一子系统的服务的次数，以便当调用次数超过了预设次数且服务调用失败时，对第一子系统的服务调用进行手动干预。当然，也可以针对第一子系统请求的服务统计调用时间，其中调用时间表示从接收到服务调用请求的时间点与当前时间点的差值，以便当调用时间超过了预设时间差值且服务调用失败时，对第一子系统的服务调用进行手动干预。例如，在高并发的情况下，手动改变某个服务的优先级，可以使得优先调用该服务。

应理解，也可以统计重新调用的次数(重试次数)，调用时间的起始时间点和终止时间点也并不限定，例如，可以将保存任务信息的时间点作为起始时间点或将上一次调用结束时作为终止的时间点，等等。

通过手动干预的方式来处理服务调用，可以提高业务操作的准确性，进一步提高服务调用的成功率。

可选地，作为另一个实施例，可以进行全局地统计，统计在一段时间内调用成功的服务的数目、服务类型或调用时间等，和/或统计在一段时间内调用失败的服务的已调用的次数、服务类型或已使用时间等。例如，服务调用框架建立运维端系统实时根据服务调用情况，统计包括但不限于已成功调用的服务的个数或类型或使用时间，或者统计调用失败的服务已调用的次数或已使用的时间。通过跟踪和查询服务调用情况并获取统计数据，方便后续运维管理并做出合适的策略。

根据本发明可选的实施例，在高并发的情况下，服务调用框架可以通过扩充服务器集群数量来提高访问和处理效率。如图2所示，在服务调用框架示意性地描绘了4个服务器集群，分别是集群21，集群22，集群23和集群24，2个子系统，其中一个子系统为Web)。子系统通过API(Application Programming Interface，应用程序编程接口)接口实现与服务调用框架的交互，从而实现服务调用。应理解，上述例子中服务器集群的数目和子系统的数目等仅仅是示例性的，而非要限制本发明的范围。

图3是本发明一个实施例的服务处理方法的过程的示意性流程图。图3的方法可以由第一子系统(上游子系统)执行，并与图1的方法相对应，因此将适当省略与图1的实施例重复的描述。

步骤301，生成服务调用请求，服务调用请求包括服务数据。

步骤302，向服务调用框架发送服务调用请求，以便服务调用框架保存任务信息以及服务数据。

其中，任务信息用于标识请求的服务且由服务调用框架用于确定服务的处理情况，服务数据由服务调用框架用于在处理情况为未处理或处理失败时，向下游子系统调用服务。

通过上述方案，服务调用框架保存了与第一子系统请求的服务对应的任务信息和服务数据，基于保存的任务信息，服务调用框架可以获知当前第一子系统请求的服务的处理情况，如果当前还未处理该第一子系统请求的服务或者该服务处理失败，则服务调用框架可以根据服务数据向第二子系统调用该服务。因此，提高了子系统之间交互的性能，并提高了第一子系统通过服务调用框架调用第二子系统提高的服务的成功率。

可选地，作为一个实施例，在图3的方法中还可以包括如下：

步骤303，接收服务调用框架返回的处理结果，处理结果表示服务调用成功或服务调用失败。

图4是本发明一个实施例的服务处理方法的过程的示意性流程图。图4的方法可以由第二子系统(下游子系统)执行，并与图1的方法相对应，因此将适当省略与图1的实施例重复的描述。

步骤401，当服务调用框架根据任务信息确定第一子系统请求的服务的处理情况为未处理或处理失败时，接收服务调用框架发送的服务数据，其中任务信息用于标识第一子系统请求的服务且保存在服务调用框架中。

步骤402，根据服务数据向服务调用框架提供第一子系统请求的服务，其中服务数据包含在服务调用请求中并保存在服务调用框架中。

通过上述方案，服务调用框架基于保存的任务信息确定当前还未处理第一子系统请求的服务或者该服务处理失败时，服务调用框架可以根据服务数据向第二子系统调用该服务。因此，提高了子系统之间交互的性能，并提高了第一子系统通过服务调用框架调用第二子系统提高的服务的成功率。

可选地，作为一个实施例，在步骤402中，可以通过消息队列向服务调用框架提供第一子系统请求的服务。具体的例子可以参考上述，此处不再赘述。

为了更清楚的描述本发明，下面给出服务处理架构的示意图，在服务处理架构中包括上游子系统、服务调用框架和下游子系统。

图5是本发明实施例的服务处理架构的示意框图。在图5中，描绘了两个上游子系统，分别是子系统51和子系统52，其中一个子系统为Web。上游子系统通过服务调用框架53与下游子系统(如下游业务子系统54)进行交互，上游子系统的调用服务的接口为API，服务调用框架53具有对外统一的接口服务。服务调用框架53包括分库适配器531，有3个存储空间(分别是数据库532，文件存储系统533和消息队列534)，分布式定时触发系统535，消息队列534的消费者536。其中分库适配器530用于路由到相应的存储空间，数据库532用于存储任务信息(任务信息可以记录在数据库532存储的任务表上)，文件存储系统533用于存储报文(如业务数据)，消息队列534用于存储索引信息(如所在库所在表的标识)，分布式定时触发系统535用于触发读取数据库531中的任务信息(或触发读取数据库532中任务表)，消费者536可以用于根据消息队列中存储的索引信息进行定位，读取文件存储系统中的报文，还可以用于更新数据库532存储的任务表，也可以用于处理调用服务并返回处理结果。服务调用框架53还可以包括Mysql数据库537(关系型数据库管理系统)和缓存系统538，可以用于在处理下游子系统的业务时的数据存储。服务调用框架53的工作流引擎根据业务处理情况对Mysql数据库537和缓存系统538的状态进行更新。服务调用框架53还可以包括MQ(消息队列，Message Queue)539，用于获取服务数据并调用下游子系统54提供的服务。应注意的是，图5的架构的布置和系统的选用(如存储空间选用文件存储系统和Mysql数据库等)，仅仅是为了描述方便，而非要限制本发明的保护范围。

下面结合图6描述本发明实施例。

图6是本发明一个实施例的服务处理方法的过程的示意性流程图。

步骤601，上游子系统向服务调用框架发送服务调用请求。

服务调用请求可以是业务处理请求，在该业务处理请求中携带业务数据，还可以携带业务标识和下游子系统的标识。

步骤602，服务调用框架保存数据。

服务调用框架保存接收到的业务数据。可选地，将业务标识作为任务信息保存起来，当然也可以生成一个标识来唯一标识该业务。可选地，服务调用框架通过分库分表的形式来存储数据，具体的例子可以参考上述，此处不再赘述。

步骤603，服务调用框架调用下游子系统处理上游子系统请求的业务。

可选地，根据业务处理请求携带的下游子系统的标识确定处理该业务的下游子系统，或者服务调用框架可以保留有子系统的标识与该子系统能够处理的业务，因此可以由服务调用框架确定出处理该业务的下游子系统来。

可选地，根据任务信息确定第一子系统请求的业务未处理或处理失败的情况下，执行步骤603。具体地，可以利用分布式定时触发系统来触发确定业务处理情况。例如，当定时器到时时，根据消息队列中存储的索引信息定位到数据库中存储的任务表，该任务表可能保存了一些任务信息以及相应的业务的处理情况，扫描任务表确定第一子系统请求的业务的处理情况，当该业务未处理或处理失败时，执行步骤603。其它例子还可以参考图1的实施例，此处适当省略重复的描述。

可选地，服务调用框架可以基于消息队列系统来调用，例如，在高并发的情况下，优先处理优先级高的业务，保证业务处理的有序完成。当统计的重试处理第一子系统的业务次数大于预设的次数时，可以手动地干预，如将第一子系统的业务的优先级设置的更高，这样，基于消息队列调用时就会优先处理第一子系统的业务，因而避免业务操作的频繁失败。

步骤604，服务调用框架向上游子系统返回处理结果。

当在步骤603调用成功时，向上游子系统返回业务处理成功的结果；当在步骤603业务调用失败时，向上游子系统返回业务处理失败的结果。

进一步地，服务调用框架可以保存有服务的相关信息，以便进行全局统计。例如，实时统计处理成功的业务(包括业务类型，请求该业务处理的上游子系统，处理时间或处理该业务的下游子系统等)，也可以实时统计某些处理失败的业务(已处理的次数，已处理的时间，业务类型，请求该业务处理的上游子系统或处理该业务的下游子系统等)。通过跟踪和查询服务调用情况并获取统计数据，方便后续运维管理并做出合适的策略。

通过上述方案，能够有效地提高子系统之间的交互性能，提高业务处理的成功率。另外，可以手动干预业务处理情况，进一步提高业务处理的成功率，还可以对业务处理的情况进行实时监控。

图7是本发明一个实施例的服务调用框架的示意性结构图。服务调用框架700包括接收单元71、存储单元72、确定单元73和调用单元74。

接收单元71，用于接收第一子系统发送的服务调用请求，服务调用请求包括服务数据。

存储单元72用于保存任务信息以及接收单元71接收的服务数据，其中所述任务信息用于标识第一子系统请求的服务；

确定单元73用于根据存储单元72保存的任务信息确定第一子系统请求的服务的处理情况。

调用单元74用于在确定单元73确定的处理情况为未处理或处理失败时，根据服务数据向第二子系统调用第一子系统请求的服务。

在本发明实施例中，通过服务调用框架保存了与第一子系统请求的服务对应的任务信息和服务数据，基于保存的任务信息可以获知当前第一子系统请求的服务的处理情况，如果当前还未处理该第一子系统请求的服务或者该服务处理失败，则服务调用框架可以根据服务数据向第二子系统调用该服务，从而提高了子系统之间交互的性能。

另外，在高并发的情况下，即使出现服务超时现象，本发明的服务调用框架可以采用异步调用方式，重新调用第二子系统提供的第一子系统所请求的服务，因而避免业务操作的失败，提高了服务调用的成功率。

服务调用框架700可实现上述实施例中涉及服务调用框架的操作，因此为避免重复，不再详细描述。

可选地，作为一个实施例，确定单元73可以包括触发读取子单元和扫描确定子单元。触发读取子单元用于利用定时器触发读取任务信息，扫描确定子单元用于当扫描到触发读取子单元读取的任务信息指示服务未处理或处理失败时，确定第一子系统请求的服务的处理情况为未处理或处理失败。进一步地，触发读取子单元还可以用于利用定时器周期性触发读取任务信息；或者还可以用于在接收到服务调用请求或保存任务信息时开启定时器，当定时器达到预设时间阈值时，触发读取任务信息。

确定单元73还可以用于：当服务调用成功后，将任务信息的状态修改为已处理，或者删除任务信息。

确定单元73还可以用于统计调用次数，其中调用次数表示向第二子系统调用第一子系统的服务的次数，以便当调用次数超过了预设次数且服务调用失败时，对第一子系统的服务调用进行手动干预；或者，确定单元73还可以用于：统计调用时间，其中调用时间表示从接收到服务调用请求的时间点与当前时间点的差值，以便当调用时间超过了预设时间差值且服务调用失败时，对第一子系统的服务调用进行手动干预。通过手动干预的方式来处理服务调用，可以提高业务操作的准确性，进一步提高服务调用的成功率。

确定单元还可以用于统计在一段时间内调用成功的服务的数目、服务类型或调用时间；和/或统计在一段时间内调用失败的服务的已调用的次数、服务类型或已使用时间。通过跟踪和查询服务调用情况并获取统计数据，方便后续运维管理并做出合适的策略。

可选地，作为另一个实施例，服务调用框架700还可以包括分库适配器，存储单元72包括数据库，文件存储系统以及消息队列，其中分库适配器用于路由到数据库，数据库用于将任务信息保存到任务表中；分库适配器用于路由到文件存储系统，文件存储系统用于存储所述服务数据；以及分库适配器用于路由到消息队列，消息队列用于存储数据库存储的任务信息和文件存储系统存储的服务数据的存储索引信息。通过上述存储方式，能够快速地定位到保存的数据，从而提高效率。

可选地，作为另一个实施例，调用单元74还可以用于基于消息队列向第二子系统调用第一子系统请求的服务。

可选地，作为另一个实施例，服务调用框架700还包括发送单元75，发送单元75用于向第一子系统返回处理结果，处理结果表示服务调用成功或服务调用失败。

图8是本发明一个实施例的用于请求调用服务的装置(即上述第一子系统或上游子系统)的示意性结构图。第一子系统800包括生成单元81和发送单元82。

生成单元81用于生成服务调用请求，服务调用请求包括服务数据。

发送单元82用于向服务调用框架发送生成单元81生成的服务调用请求，以便服务调用框架保存任务信息以及服务数据。其中，任务信息用于标识请求的服务且由服务调用框架用于确定所请求的服务的处理情况，服务数据由所述服务调用框架用于在处理情况为未处理或处理失败时，向下游子系统调用装置请求的服务。

进一步地，第一子系统800还可以接收单元83，用于接收服务调用框架返回的处理结果，处理结果表示服务调用成功或服务调用失败。

第一子系统800可实现上述实施例中涉及第一子系统的操作，因此为避免重复，不再描述。

图9是本发明一个实施例的用于处理服务的装置(即上述第二子系统)的示意性结构图。第二子系统900包括接收单元91和提供单元92。

接收单元91，用于当服务调用框架根据任务信息确定第一子系统请求的服务的处理情况为未处理或处理失败时，接收服务调用框架发送的服务数据。

提供单元92，用于根据接收单元91接收的服务数据向服务调用框架提供第一子系统请求的服务。

其中，任务信息用于标识第一子系统请求的服务且保存在服务调用框架中，服务数据包含在服务调用请求中并保存在服务调用框架中。

进一步地，提供单元92可以具体用于基于消息队列向服务调用框架提供第一子系统请求的服务。

第二子系统900可实现上述实施例中涉及第二子系统的操作，因此为避免重复，不再描述。

图10是本发明一个实施例的服务处理架构的示意性结构图。服务处理架构1000包括第一子系统1001，第二子系统1002和服务调用框架1003。

第一子系统1001用于向服务调用框架1002发送服务调用请求，服务调用请求包括服务数据。

服务调用框架1003用于接收第一子系统1001发送的服务调用请求，保存任务信息以及服务数据，根据任务信息确定第一子系统1001请求的服务的处理情况，在处理情况为未处理或处理失败时，根据服务数据向第二子系统1002调用第一子系统1001请求的服务，其中任务信息用于标识第一子系统1001请求的服务。

第二子系统1002用于提供第一子系统1001请求的服务。

其中，图5所示的架构可以作为服务处理架构的一个例子。为避免重复，此处不再赘述。

上述本发明实施例揭示的方法可以应用图11所示的设备1100来实现。设备1100包括处理器1101，存储器1102和收发器1103。处理器1101控制设备1100的操作。存储器1102可以包括只读存储器和随机存取存储器，并向处理器1101提供指令和数据。存储器1102的一部分还可以包括非易失行随机存取存储器(NVRAM)。处理器1101，存储器1102，收发器1103通过总线系统1110耦合在一起，其中总线系统1110除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图中将各种总线都标为总线系统1110。

其中，处理器1101可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器1101中的硬件的集成逻辑电路或者软件形式的指令完成。处理器1101可以是通用处理器，包括CPU(中央处理器，Central Processing Unit)、NP(网络处理器，Network Processor)等；还可以是DSP(数字信号处理器，DigitalSignal Processing)、ASIC(专用集成电路，Application Specific IntegratedCircuit)、FPGA(现成可编程门阵列，Field Programmable Gate Array)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM(Read-Only Memory，只读存储器)、RAM(Random Access Memory，随机存取存储器)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (28)

1.一种服务处理方法，其特征在于，包括：

接收第一子系统发送的服务调用请求，所述服务调用请求包括服务数据；

保存任务信息以及所述服务数据，所述任务信息用于标识所述第一子系统请求的服务；

根据所述任务信息确定所述第一子系统请求的服务的处理情况；

在所述处理情况为未处理或处理失败时，根据所述服务数据向第二子系统调用所述第一子系统请求的服务。

2.根据权利要求1所述的方法，其特征在于，所述根据所述任务信息确定所述第一子系统请求的服务的处理情况，包括：

利用定时器触发读取所述任务信息，当扫描到读取的所述任务信息指示服务未处理或处理失败时，确定所述第一子系统请求的服务的处理情况为未处理或处理失败；或者

利用定时器触发读取所述任务信息，当读取到所述任务信息时，确定所述第一子系统请求的服务未处理或处理失败。

3.根据权利要求2所述的方法，其特征在于，所述利用定时器触发读取所述任务信息，包括：

利用所述定时器周期性触发读取所述任务信息；或者

在接收到所述服务调用请求或保存所述任务信息时开启所述定时器，当所述定时器达到预设时间阈值时，触发读取所述任务信息。

4.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

当服务调用成功后，将所述任务信息对应的服务处理情况修改为已处理，或者删除所述任务信息。

5.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

统计调用次数，其中所述调用次数表示向所述第二子系统调用所述第一子系统的服务的次数，以便当所述调用次数超过了预设次数且服务调用失败时，对所述第一子系统的服务调用进行手动干预。

6.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

统计调用时间，其中所述调用时间表示从接收到所述服务调用请求的时间点与当前时间点的差值，以便当所述调用时间超过了预设时间差值且服务调用失败时，对所述第一子系统的服务调用进行手动干预。

7.根据权利要求1-3任一项所述的方法，其特征在于，所述保存与所述服务调用请求对应的任务信息以及所述服务调用请求中的服务数据，包括：

通过分库适配器路由到数据库，将所述任务信息保存到在所述数据库中存储的任务表中，通过所述分库适配器路由到文件存储系统，在所述文件存储系统中存储所述服务数据，并通过所述分库适配器路由到消息队列，在所述消息队列中存储所述任务信息和所述服务数据的存储索引信息。

8.根据权利要求1-3任一项所述的方法，其特征在于，所述向第二子系统调用所述第一子系统请求的服务，包括：

基于消息队列向第二子系统调用所述第一子系统请求的服务。

9.根据权利要求1-3任一项所述的方法，其特征在于，所述方法还包括：

向所述第一子系统返回处理结果，所述处理结果表示服务调用成功或服务调用失败。

10.根据权利要求1-3所述的方法，其特征在于，所述方法还包括：

统计在一段时间内调用成功的服务的数目、服务类型或调用时间，和/或统计在一段时间内调用失败的服务的已调用的次数、服务类型或已使用时间。

11.一种服务处理方法，其特征在于，包括：

生成服务调用请求，所述服务调用请求包括服务数据；

向服务调用框架发送所述服务调用请求，以便所述服务调用框架保存任务信息以及所述服务数据；

其中，所述任务信息用于标识请求的服务且由所述服务调用框架用于确定所述服务的处理情况，所述服务数据由所述服务调用框架用于在所述处理情况为未处理或处理失败时，向下游子系统调用所述服务。

12.根据权利要求11所述的方法，其特征在于，所述方法还包括：

接收所述服务调用框架返回的处理结果，所述处理结果表示服务调用成功或服务调用失败。

13.一种服务处理方法，其特征在于，包括：

当服务调用框架根据任务信息确定第一子系统请求的服务的处理情况为未处理或处理失败时，接收所述服务调用框架发送的服务数据；

根据所述服务数据向所述服务调用框架提供所述第一子系统请求的服务；

其中，所述任务信息用于标识所述第一子系统请求的服务且保存在所述服务调用框架中，所述服务数据包含在所述服务调用请求中并保存在所述服务调用框架中。

14.根据权利要求13所述的方法，其特征在于，所述向所述服务调用框架提供所述第一子系统请求的服务，包括：

通过消息队列向所述服务调用框架提供所述第一子系统请求的服务。

15.一种服务调用框架，其特征在于，包括接收单元，存储单元，确定单元和调用单元，其中

所述接收单元，用于接收第一子系统发送的服务调用请求，所述服务调用请求包括服务数据；

所述存储单元，用于保存任务信息以及所述接收单元接收的所述服务数据，其中所述任务信息用于标识所述第一子系统请求的服务；

所述确定单元，用于根据所述存储单元保存的所述任务信息确定所述第一子系统请求的服务的处理情况；

所述调用单元，用于在所述确定单元确定的所述处理情况为未处理或处理失败时，根据所述服务数据向第二子系统调用所述第一子系统请求的服务。

16.根据权利要求15所述的服务调用框架，其特征在于，所述确定单元包括触发读取子单元和扫描确定子单元，其中：

所述触发读取子单元，用于利用定时器触发读取所述任务信息；

所述扫描确定子单元，用于当扫描到所述触发读取子单元读取的所述任务信息指示服务未处理或处理失败时，确定所述第一子系统请求的服务的处理情况为未处理或处理失败。

17.根据权利要求16所述的服务调用框架，其特征在于，所述触发读取子单元

还用于利用所述定时器周期性触发读取所述任务信息；或者

还用于在接收到所述服务调用请求或保存所述任务信息时开启所述定时器，当所述定时器达到预设时间阈值时，触发读取所述任务信息。

18.根据权利要求15-17任一项所述的服务调用框架，其特征在于，所述确定单元还用于：当服务调用成功后，将所述任务信息的状态修改为已处理，或者删除所述任务信息。

19.根据权利要求15-17任一项所述的服务调用框架，其特征在于，所述确定单元还用于：统计调用次数，其中所述调用次数表示向所述第二子系统调用所述第一子系统的服务的次数，以便当所述调用次数超过了预设次数且服务调用失败时，对所述第一子系统的服务调用进行手动干预；或者

所述确定单元还用于：统计调用时间，其中所述调用时间表示从接收到所述服务调用请求的时间点与当前时间点的差值，以便当所述调用时间超过了预设时间差值且服务调用失败时，对所述第一子系统的服务调用进行手动干预。

20.根据权利要求15-17任一项所述的服务调用框架，其特征在于，所述服务调用框架还包括分库适配器，所述存储单元包括数据库，文件存储系统以及消息队列，其中

所述分库适配器用于路由到所述数据库，所述数据库用于将所述任务信息保存到任务表中；

所述分库适配器用于路由到所述文件存储系统，所述文件存储系统用于存储所述服务数据；以及

所述分库适配器用于路由到所述消息队列，所述消息队列用于存储所述数据库存储的所述任务信息和所述文件存储系统存储的所述服务数据的存储索引信息。

21.根据权利要求15-17任一项所述的服务调用框架，其特征在于，所述调用单元还用于：

基于消息队列向第二子系统调用所述第一子系统请求的服务。

22.根据权利要求15-17任一项所述的服务调用框架，其特征在于，所述服务调用框架还包括发送单元，

所述发送单元用于向所述第一子系统返回处理结果，所述处理结果表示服务调用成功或服务调用失败。

23.根据权利要求15-17任一项所述的服务调用框架，其特征在于，所述确定单元还用于：

统计在一段时间内调用成功的服务的数目、服务类型或调用时间；和/或

统计在一段时间内调用失败的服务的已调用的次数、服务类型或已使用时间。

24.一种用于请求调用服务的装置，其特征在于，包括：

生成单元，用于生成服务调用请求，所述服务调用请求包括服务数据；

发送单元，用于向服务调用框架发送所述服务调用请求，以便所述服务调用框架保存任务信息以及所述服务数据；

其中，所述任务信息用于标识所述装置请求的服务且由所述服务调用框架用于确定所述装置请求的服务的处理情况，所述服务数据由所述服务调用框架用于在所述处理情况为未处理或处理失败时，向下游子系统调用所述装置请求的服务。

25.根据权利要求24所述的装置，其特征在于，所述装置还包括：

接收单元，用于接收所述服务调用框架返回的处理结果，所述处理结果表示服务调用成功或服务调用失败。

26.一种用于处理服务的装置，其特征在于，包括：

接收单元，用于当服务调用框架根据任务信息确定上游子系统请求的服务的处理情况为未处理或处理失败时，接收所述服务调用框架发送的服务数据；

提供单元，用于根据所述接收单元接收的服务数据向所述服务调用框架提供所述上游子系统请求的服务；

其中，所述任务信息用于标识所述上游子系统请求的服务且保存在所述服务调用框架中，所述服务数据包含在所述服务调用请求中并保存在所述服务调用框架中。

27.根据权利要求26所述的装置，其特征在于，所述提供单元具体用于：

基于消息队列向所述服务调用框架提供所述上游子系统请求的服务。

28.一种服务处理架构，其特征在于，包括第一子系统，第二子系统和服务调用框架，其中

所述第一子系统，用于向所述服务调用框架发送服务调用请求，所述服务调用请求包括服务数据；

所述服务调用框架用于接收所述第一子系统发送的所述服务调用请求，保存任务信息以及所述服务数据，根据所述任务信息确定所述第一子系统请求的服务的处理情况，在所述处理情况为未处理或处理失败时，根据所述服务数据向所述第二子系统调用所述第一子系统请求的服务，其中所述任务信息用于标识所述第一子系统请求的服务；

所述第二子系统用于提供所述第一子系统请求的服务。