CN110191141A - 服务调用信息处理方法、装置及计算机系统 - Google Patents

Abstract

本申请实施例公开了服务调用信息处理方法、装置及计算机系统，其中，所述系统包括：远程服务框架中间件，用于提供应用程序编程接口API；服务提供节点，用于在被调用并得到业务处理结果后，通过调用所述API将扩展信息输出给所述远程服务框架中间件；所述远程服务框架中间件还用于，将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。通过本申请实施例，能够通过比较低的改造成本、改造风险，来支持服务提供节点返回业务处理信息供服务调用节点进行业务逻辑判断。

Description

服务调用信息处理方法、装置及计算机系统

技术领域

本申请涉及服务调用技术领域，特别是涉及服务调用信息处理方法、装置及计算机系统。

背景技术

在网络销售系统中，随着用户数量和网站流量的增长，应用系统的数量和复杂程度也急剧增加。诸多前台系统都需要使用一些公共的业务逻辑，这也业务逻辑通常具有共性的东西，比如，获取用户信息或者查询商品详情等。如果将这些业务逻辑在各个系统内部都实现一遍，则大大增加了开发成本和后期维护成本。于是，远程服务框架这类的中间件产品就应运而生了。远程服务框架帮助各个系统将那些相似的业务逻辑抽离出来，单独部署，而前台系统在需要调用这些业务逻辑时，只需要通过远程服务框架远程调用即可，大大节约了前端系统的开发成本，也提高了系统的可维护性和可扩展性。

远程服务框架从分布式应用层面以及同一的发布/调用方式层面为业务系统提供支持，从而可以让他们很容易地开发分布式应用并提供和使用公共功能模块，而不用考虑分布式领域中的各种细节技术，例如，远程通讯、性能损耗、调用的透明化、同步/异步调用的实现等问题。

远程服务框架的实现有三种角色，服务提供者、服务使用者和注册中心。服务提供者在服务可用的前提下，将服务地址注册到注册中心，服务使用者启动时，会订阅注册中心的相关服务，获得服务地址，通过一定的负载均衡策略调用服务。

其中，服务是由服务提供者进行开发的，为了保证服务调用过程中出现各种情况时都能够正常运行，通常依赖于服务提供节点提供标准的、规范的服务定义。现有技术中，这种规范的定义通常是通过对服务出参进行对象封装的方式，使得其包含丰富的返回信息，由服务提供节点在业务处理逻辑中设置后，服务调用节点读取的方式进行相关处理结果信息的传递。例如，当系统A调用系统B提供的服务时，如果该服务是规范的，则在该服务被调用后，如果调用成功，则需要向系统A返回具体的调用结果，如果调用失败，则需要将失败的原因等信息返回给系统A，以使得系统A能够获知失败的原因，进而根据具体的失败原因来确定下一步的处理方式。

但是，由于具体的服务以及相关出参的封装等，都是由服务提供节点的开发人员来实现的，而系统中对于出参的定义方式等并没有强制性的约束，因此，不能不免不规范的服务定义的产生，以至于实际的业务处理逻辑链路经常出现断路等情况的发生。例如，订单创建系统在创建订单时，需要调用查询商品信息的服务，查询门店信息的服务，以及底层的库存处理的服务，等等，只有各服务都能够正常返回响应的情况下，才能够正常进行业务处理逻辑。但是，假设在库存处理服务中出现了库存不足的情况，以至于库存扣减失败，在库存处理服务未进行规范定义的情况下，返回的响应信息中可能只有“失败”这样一种调用结果异常的提示信息，而关于具体失败的原因等信息，则不会返回给服务调用节点，这就导致服务调用节点在调用失败的情况下信息丢失，导致服务调用节点不能精确判断当前服务方具体情况而无法做进一步的处理，等等。

为了解决上述问题，可以对服务提供节点所提供的服务的出参等进行强制性约束，但是，针对已经提供相关服务定义且在线上运行的服务而言，这种重新对出参进行定义的方式会造成对服务的二次改造，成本高，风险大，并且，存在各种过渡期业务兼容性问题。

因此，在服务提供节点的服务定义不规范的场景下，如何通过比较低的改造成本、改造风险，来支持服务提供节点返回业务处理信息供服务调用节点进行业务逻辑判断，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了服务调用信息处理方法、装置及计算机系统，能够通过比较低的改造成本、改造风险，来支持服务提供节点返回业务处理信息供服务调用节点进行业务逻辑判断。

本申请提供了如下方案：

一种服务调用信息处理系统，包括：

远程服务框架中间件，用于提供应用程序编程接口API；

服务提供节点，用于在被调用并得到业务处理结果后，通过调用所述API将扩展信息输出给所述远程服务框架中间件；

所述远程服务框架中间件还用于，将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。

一种服务调用信息处理方法，包括：

提供应用程序编程接口API，以用于服务提供节点在被调用并得到业务处理结果后，通过调用所述API输出扩展信息；

将所述业务处理结果与所述扩展信息进行整合，生成响应对象；

将所述响应对象回传给服务调用节点。

一种服务调用信息处理方法，包括：

在服务提供节点被调用后，确定业务处理结果信息；

通过调用远程服务框架中间件提供的API输出扩展信息，以用于将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。

一种服务调用信息处理装置，包括：

API提供单元，用于提供应用程序编程接口API，以用于服务提供节点在被调用并得到业务处理结果后，通过调用所述API输出扩展信息；

整合处理单元，用于将所述业务处理结果与所述扩展信息进行整合，生成响应对象；

响应对象回传单元，用于将所述响应对象回传给服务调用节点。

一种服务调用信息处理装置，包括：

处理结果信息确定单元，用于在服务提供节点被调用后，确定业务处理结果信息；

API调用单元，用于通过调用远程服务框架中间件提供的API输出扩展信息，以用于将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。

一种计算机系统，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供应用程序编程接口API，以用于服务提供节点在被调用并得到业务处理结果后，通过调用所述API输出扩展信息；

将所述业务处理结果与所述扩展信息进行整合，生成响应对象；

将所述响应对象回传给服务调用节点。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，远程服务框架中间件可以提供专门的API，这样，在服务提供者的服务被调用的过程中，即使服务存在不规范定义的情况下，也能够通过调用这种API的方式，将与具体服务调用结果相关的扩展信息输出一份给远程服务框架中间件，这样，该中间件在具体进行RPC响应时，就可以将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。可见，通过该方法，服务提供节点所提供的服务存在不规范定义的情况下，只需要在实现远程服务框架中间件的接口，即可实现扩展信息的传递，而无需进行出参的对象封装等处理，因此，能够以较低的改造成本，在低风险的情况下，来支持服务提供节点返回业务处理信息供服务调用节点进行业务逻辑判断。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的服务调用链路示意图；

图2是本申请实施例提供的系统的示意图；

图3是本申请实施例提供的第一方法的流程图；

图4是本申请实施例提供的第二方法的流程图；

图5是本申请实施例提供的第一装置的示意图；

图6是本申请实施例提供的第二装置的示意图；

图7是本申请实施例提供的计算机系统的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，可以对现有的远程服务框架中间件进行改进，使其能够支持调用结果上下文信息的扩展，这样，服务提供节点即使在其提供的服务存在不规范定义的情况下，也能够通过该功能的扩展，以较低的成本，实现向服务调用节点返回业务处理信息供服务调用节点进行业务逻辑判断。

具体的，远程服务框架中间件可以实现一个专门的接口，并将相应的API提供给服务提供节点，供服务提供节点进行调用。服务提供节点可以在其业务逻辑中实现该接口，这样，在被调用的过程中，产生业务处理结果之后，如果需要向服务调用节点提供一些扩展信息，则可以通过调用该API的方式，将这种扩展信息向远程服务框架中间件传递一份，该中间件可以将这种扩展信息组装到RPC响应体中，并回传给服务调用节点，使得服务调用节点能够从响应体中读取到具体的扩展信息。其中，所谓的扩展信息就可以是服务提供节点想要提供给服务调用节点的信息，在现有技术中，如果服务提供节点想要向服务调用节点提供一些信息，则需要在对服务出参进行对象封装才能够实现，而在本申请实施例中，服务提供节点只需要调用中间件提供的API，便可以实现将具体的信息提供给服务调用节点，而需要在服务出参中对这种信息进行相应的对象封装。这样，即使已经在线上运行的服务，也不需要进行很大的改造，只要能够实现对指定API的调用即可。例如，假设订单创建服务在创建订单时，需要调用库存处理服务进行库存的扣减等相关操作，而库存处理服务发现库存不足，于是需要返回服务调用失败的消息，同时还希望将失败的原因，也即库存余量不足这种信息返回给服务使用者，但是，在该服务的出参中并未对调用失败的原因这种对象进行封装。此时，在使用本申请实施例提供的方案的情况下，由于在出现服务调用失败的情况时，库存处理服务提供节点通常需要将具体失败的原因等信息添加到日志文件中，而本申请实施例中的远程服务框架中间件提供了针对这种情况进行处理的API，因此，库存处理服务提供节点就可以通过调用该API，将该调用失败的原因等信息向服务框架中间件传递一份。该API被调用后，可以执行对应的方法，首先，通过一个额外的参数，将具体需要传递的扩展信息传给服务框架中间件，之后，中间件将这种扩展信息组装到该库存处理服务提供节点即将返回的响应体中，这样，服务调用节点就可以通过接收该响应体获知服务提供节点所提供的扩展信息。

具体实现时，假设用户在使用客户端程序的过程中，在执行某项处理时，相关的业务链路如图1所示，其中，业务链路上包括多个应用，也即，服务提供节点所提供的服务在该例子中分别以不同的应用的形式存在。其中，应用A为链路的起点，其作为服务调用节点，分别调用了作为服务提供节点的应用B、C，之后，应用C又作为服务调用节点，调用了作为服务提供节点的应用D以及应用E。可见，服务调用节点与服务提供节点只是相对的概念，同一应用在同一业务链路中，可能既扮演服务提供节点的角色，又扮演服务调用节点的角色，尤其是业务链路上的一些中间结点。其中，应用E的处理逻辑中，主要是对某数据库进行查询，并给出相应的响应。但是，在处理过程中，该应用E查询该数据库时发生超时的现象，以至于调用失败。

此时，在本申请实施例中，该应用E可以通过调用中间件提供的API，将相关的扩展信息写入本地线程上下文中，这种扩展信息通常是非业务信息，另外写入该本地线程上下文的信息还可以包括该应用E在被调用后所执行的业务处理的业务处理结果。这样，远程服务框架中间件可以从该应用E的本地线程上下文中读取所述业务处理结果以及扩展信息，并将两者进行整合生成RPC响应对象。之后，该RPC响应对象将会被返回给服务调用节点，也即应用C。应用C在接收到RPC响应对象之后，针对响应对象中所包含的信息，根据该应用C在业务链路中所在位置的不同，可以执行不同的处理。其中，在该例子中，该应用C为业务链路的中间节点，中间件在将响应对象回传给应用C之后，还可以读取该响应对象中包含的信息，并写入该应用C的本地线程上下文中。另外，由于应用C位于业务链路的中间位置，这也就意味着，该应用C实际上也同时扮演着另一服务调用节点也即应用A的服务提供节点的角色，因此，也需要向所述应用A返回RPC响应对象，并且，该应用C在被所述应用A调用时，相关的业务处理结果信息也会写入到该应用C的本地线程上下文中，另外，如果该应用C也需要向其服务调用节点也即应用A提供一些扩展信息，则同样可以通过调用中间件提供的API的方式，将扩展信息写入该应用C的本地线程上下文中。这样，应用C的本地线程上下文中包含的信息就可以包括：应用E的业务处理结果信息以及扩展信息，应用C的业务处理结果信息以及扩展信息。这样，远程服务框架中间件在为应用C生成RPC响应对象时，同样可以同该应用C的本地线程上下文中读取出上述信息，并整合成一个响应对象，返回给应用C的服务调用节点，也即应用A。

应用A在收到中间件提供的响应对象之后，如果该应用A也是业务链路的中间节点，则可以重复与应用C相同的处理，也即，在应用A的本地线程上下文中可以记录应用E的业务处理结果及扩展信息，应用C的业务处理结果及扩展信息(当然，应用C也可以不提供扩展信息)，应用A的业务处理结果以及扩展信息，同样的，应用A对应的扩展信息也可以根据实际情况确定是否存在，以此类推。而在图1所示的例子中，由于应用A为业务链路的起点，也即，其响应信息通常用于直接提供给客户端，供用户查看，因此，此时可以直接从响应对象中获取整个业务链路上各应用的业务处理结果，以及对应的扩展信息，并且可以转译为自然语言表达的文案，该文案便可以用于展示给用户，从而实现对用户的精准提示。也就是说，由于响应对象中包含了业务链路上各应用的业务处理结果，以及对应的扩展信息，其中，具体的扩展信息就可以包括具体的应用被调用时对应的详情信息，例如，包括调用失败情况下对应的失败原因等信息，因此，即使服务提供节点在存在不规范定义的情况下，用户也可以更方便直接的获知具体的调用情况，而无需再逐步查看日志的方式来进行定位。

其中，关于具体的扩展信息，为了便于进行后续的转译工作，还可以对其格式等进行定义。例如，在一种具体实现方式下，可以将这种扩展信息划分为三个字段，分别为，系统用例信息，活动，状态。其中，所谓的系统用例信息具体可以标识出具体的服务节点在被调用时，调用入口所在的位置信息，以此可以定位具体是哪个服务。活动则是指具体该服务节点所执行的活动，例如，查询某数据库等，状态则是指活动的状态，例如，查询数据库超时，等等。这样，通过上述信息，便可以直观的标识出具体调用过程中的详情信息，并且在进行向自然语言文案的转译时，可以更简单的通过预先设定的模板等形式，实现简单有效的转译，保证转译后文案的通顺程度。

具体确定上述扩展信息的方式可以有多种，例如，假设需要获取上述三个字段的信息，则关于所述系统用例信息，由于在服务节点被调用时，会在业务入口出买入具体的系统用例，因此，API被调用后执行的其中一部分处理，就可以是读取到该系统用例的标识。另外，服务节点在被调用并获得处理结果之后，通常都会打日志，也即，将具体的调用详情等信息，包括调用失败的原因等，写入到系统日志中，因此，API被调用后执行的另一部分处理可以是，根据写入系统日志的信息额外输出一个参数，根据该参数确定所述活动以及对应的状态信息。然后，就可以将三段信息写入到当前服务提供节点的本地线程上下文中。

下面在前文所介绍的解决的方案的基础上，对本申请实施例提供的具体实施方式进行详细介绍。

实施例一

首先，参见图2，本申请实施例一首先提供了一种服务调用信息处理系统，该系统具体可以包括：

远程服务框架中间件201，用于提供应用程序编程接口API；

服务提供节点202，用于在被调用并得到业务处理结果后，通过调用所述API将扩展信息输出给所述远程服务框架中间件；

所述远程服务框架中间件201还用于，将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。

具体实现时，所述服务提供节点具体可以用于，通过调用所述API将所述扩展信息写入所述服务提供节点的本地线程上下文中，所述本地线程上下文中还记录有所述业务处理结果；此时，所述远程服务框架中间件具体用于，从所述本地线程上下文读取所述扩展信息以及所述业务处理结果，并将所述业务处理结果与所述扩展信息进行整合，生成响应对象。

其中，具体将所述扩展信息写入本地线程上下文的实现可以是通过API提供的功能来实现的，具体的，服务提供节点可以产生具体的扩展信息，然后，API在被调用后，就可以将这种扩展信息写入当前服务提供节点的本地线程上下文中。具体实现时，所述扩展信息可以包括两部分，一部分是当前服务提供节点在被调用时的入口位置信息，另一部分可以是的当前服务节点在被调用时所执行的活动，以及活动的状态信息。其中，关于所述入口位置信息，由于在服务提供节点在被调用时，具体的入口位置信息可以通过UC值等方式写入链路调用上下文中，并随之在业务链路传递至链路上每个相关的业务系统，因此，各个节点上的业务系统都可以通过本地线程上下文获知具体的链调用路上下文信息，因此，该API在被调用时，可以从当前服务提供节点的本地线程上下文中获知用于代表所述入口位置信息的UC值。而关于第二部分信息，由于服务提供节点在被调用的过程中，或者执行具体的处理结束后，通常会向日志系统中记录相关的信息，因此，该API在被调用之后，服务提供节点就可以通过一个预置的参数，将这种写入日志的信息输出一份给API，由API写入到该服务提供节点的本地线程上下文中。其中，具体在得到写入日志的信息后，还可以首先进行处理，具体的，可以根据所述服务提供节点传入的日志信息，确定所述服务提供节点在被调用时所执行的活动信息，以及所述活动的状态信息，然后，根据所述入口位置信息、活动信息以及状态信息，生成所述扩展信息，并写入所述本地线程上下文。当然，在具体实现时，还可以通过其他方式来传递所述扩展信息，这里不再一一详述。

在将扩展信息写入到服务提供节点的本地线程上下文之后，远程服务框架中间件就可以在回复RPC请求的响应消息时，将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。

具体实现时，所述远程服务框架中间件在将所述响应对象回传给所述服务调用节点后，还可以确定所述服务调用节点在业务链路上的位置信息，如果是中间节点，则将所述响应对象中包含的信息写入该服务调用节点的本地线程上下文中；在所述服务调用节点生成业务处理结果后，从该服务调用节点的本地线程上下文中读取该服务调用节点生成的业务处理结果信息，以及所述服务提供节点的业务处理结果以及扩展信息，并组装成响应对象，回传给该服务调用节点的上游服务调用节点。

其中，由于所述服务调用节点为业务链路上的中间节点，因此，该服务调用节点同时也会作为服务提供节点存在，因此，也会生成所述业务处理结果，此时，如果需要向所述上游服务节点提供扩展信息，则同样可以通过调用所述API的方式，将该扩展信息写入到该服务调用节点的本地线程上下文中，以便所述远程服务框架中间件将该服务调用节点产生的业务处理结果，扩展结果，以及所述服务提供节点的业务处理结果以及扩展信息进行组装生成响应对象。

如果所述服务调用节点为业务链路上的起始节点，则所述程服务框架中间件在将所述响应对象回传给所述服务调用节点后，还可以将所述响应对象中包含的各节点产生的业务处理结果以及所述扩展信息进行转译，生成文案信息。

具体实现时，所述服务提供节点具体可以用于，在被调用并得到业务处理结果后，如果业务处理结果存在异常，则调用所述API将扩展信息提供给所述远程服务框架中间件，所述扩展信息包括所述异常对应的原因信息。当然，在实际应用中，即使服务提供节点的业务处理结果不存在异常，也可以通过这种方式将一些想要向服务调用者提供的信息通过这种方式实现信息的提供。

总之，通过本申请实施例，远程服务框架中间件可以提供专门的API，这样，在服务提供者的服务被调用的过程中，即使服务存在不规范定义的情况下，也能够通过调用这种API的方式，将与具体服务调用结果相关的扩展信息输出一份给远程服务框架中间件，这样，该中间件在具体进行RPC响应时，就可以将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。可见，通过该方法，服务提供节点所提供的服务存在不规范定义的情况下，只需要在实现远程服务框架中间件的接口，即可实现扩展信息的传递，而无需进行出参的对象封装等处理，因此，能够以较低的改造成本，在低风险的情况下，来支持服务提供节点返回业务处理信息供服务调用节点进行业务逻辑判断。

实施例二

该实施例二是与实施例一相对应的，从远程服务框架中间件的角度，提供了一种服务调用信息处理方法，参见图3，该方法具体可以包括：

S301：提供应用程序编程接口API，以用于服务提供节点在被调用并得到业务处理结果后，通过调用所述API输出扩展信息；

S302：将所述业务处理结果与所述扩展信息进行整合，生成响应对象；

S303：将所述响应对象回传给服务调用节点

其中，所述API被调用后，可以将所述扩展信息写入所述服务提供节点的本地线程上下文中，所述本地线程上下文中还记录有所述业务处理结果；此时，具体在将所述业务处理结果与所述扩展信息进行整合时，可以从所述本地线程上下文读取所述扩展信息以及所述业务处理结果，并将所述业务处理结果与所述扩展信息进行整合，生成响应对象。

另外，在具体实现时，在将响应对象返回后，还可以确定所述服务调用节点在业务链路上的位置信息；如果是中间节点，则将所述响应对象中包含的信息写入该服务调用节点的本地线程上下文中；在所述服务调用节点生成业务处理结果后，从该服务调用节点的本地线程上下文中读取该服务调用节点生成的业务处理结果信息，以及所述服务提供节点的业务处理结果以及扩展信息，并组装成响应对象，回传给该服务调用节点的上游服务调用节点。

如果所述服务调用节点为业务链路上的起始节点，则可以将所述响应对象中包含的各节点产生的业务处理结果以及所述扩展信息进行转译，生成文案信息。

实施例三

该实施例三也是与实施例一相对应的，从服务提供节点的角度，提供了一种服务调用信息处理方法，参见图4，该方法具体可以包括：

S401：在服务提供节点被调用后，确定业务处理结果信息；

S402：通过调用远程服务框架中间件提供的API输出扩展信息，以用于将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。

由于上述实施例二、三是与实施例一相对应的，因此，相关的具体实现可以参见实施例一以及前文相关的介绍，这里不再赘述。

与实施例二相对应，本申请实施例还提供了一种服务调用信息处理装置，参见图5，该装置可以包括：

API提供单元501，用于提供应用程序编程接口API，以用于服务提供节点在被调用并得到业务处理结果后，通过调用所述API输出扩展信息；

整合处理单元502，用于将所述业务处理结果与所述扩展信息进行整合，生成响应对象；

响应对象回传单元503，用于将所述响应对象回传给服务调用节点。

具体实现时，所述API被调用后，将所述扩展信息写入所述服务提供节点的本地线程上下文中，所述本地线程上下文中还记录有所述业务处理结果；

所述整合处理单元具体可以用于：

从所述本地线程上下文读取所述扩展信息以及所述业务处理结果，并将所述业务处理结果与所述扩展信息进行整合，生成响应对象。

在实际应用中，该装置还可以包括：

位置信息确定单元，用于确定所述服务调用节点在业务链路上的位置信息；

本地线程写入单元，用于如果是中间节点，则将所述响应对象中包含的信息写入该服务调用节点的本地线程上下文中；

本地读取单元，用于在所述服务调用节点生成业务处理结果后，从该服务调用节点的本地线程上下文中读取该服务调用节点生成的业务处理结果信息，以及所述服务提供节点的业务处理结果以及扩展信息，并组装成响应对象，回传给该服务调用节点的上游服务调用节点。

文案生成单元，用于如果所述服务调用节点为业务链路上的起始节点，则将所述响应对象中包含的各节点产生的业务处理结果以及所述扩展信息进行转译，生成文案信息。

与实施例三相对应，本申请实施例还提供了一种服务调用信息处理装置，参见图6，该装置可以包括：

处理结果信息确定单元601，用于在服务提供节点被调用后，确定业务处理结果信息；

API调用单元602，用于通过调用远程服务框架中间件提供的API输出扩展信息，以用于将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。

另外，本申请实施例还提供了一种计算机系统，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供应用程序编程接口API，以用于服务提供节点在被调用并得到业务处理结果后，通过调用所述API输出扩展信息；

将所述业务处理结果与所述扩展信息进行整合，生成响应对象；

将所述响应对象回传给服务调用节点。

其中，图7示例性的展示出了计算机系统的架构，具体可以包括处理器710，视频显示适配器711，磁盘驱动器712，输入/输出接口713，网络接口714，以及存储器720。上述处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720之间可以通过通信总线730进行通信连接。

其中，处理器710可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器720可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器720可以存储用于控制计算机系统700运行的操作系统721，用于控制计算机系统700的低级别操作的基本输入输出系统(BIOS)。另外，还可以存储网页浏览器723，数据存储管理系统724，以及服务调用信息处理系统725等等。上述服务调用信息处理系统725就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器720中，并由处理器710来调用执行。

输入/输出接口713用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口714用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线730包括一通路，在设备的各个组件(例如处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，与存储器720)之间传输信息。

另外，该计算机系统700还可以从虚拟资源对象领取条件信息数据库741中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器710、视频显示适配器711、磁盘驱动器712、输入/输出接口713、网络接口714，存储器720，总线730等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的服务调用信息处理方法、装置及计算机系统，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (15)

1.一种服务调用信息处理系统，其特征在于，包括：

远程服务框架中间件，用于提供应用程序编程接口API；

服务提供节点，用于在被调用并得到业务处理结果后，通过调用所述API将扩展信息输出给所述远程服务框架中间件；

所述远程服务框架中间件还用于，将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。

2.根据权利要求1所述的系统，其特征在于，

所述服务提供节点具体用于，通过调用所述API将所述扩展信息写入所述服务提供节点的本地线程上下文中，所述本地线程上下文中还记录有所述业务处理结果；

所述远程服务框架中间件具体用于，从所述本地线程上下文读取所述扩展信息以及所述业务处理结果，并将所述业务处理结果与所述扩展信息进行整合，生成响应对象。

3.根据权利要求2所述的系统，其特征在于，

所述服务提供节点具体用于，通过预置的参数将写入日志的信息传递给所述API；

所述API具体用于：获得所述服务提供节点被调用时的入口位置信息；根据所述服务提供节点传入的日志信息，确定所述服务提供节点在被调用时所执行的活动信息，以及所述活动的状态信息，根据所述入口位置信息、活动信息以及状态信息，生成所述扩展信息，并写入所述本地线程上下文。

4.根据权利要求1所述的系统，其特征在于，

所述远程服务框架中间件在将所述响应对象回传给所述服务调用节点后，还用于：

确定所述服务调用节点在业务链路上的位置信息，如果是中间节点，则将所述响应对象中包含的信息写入该服务调用节点的本地线程上下文中；在所述服务调用节点生成业务处理结果后，从该服务调用节点的本地线程上下文中读取该服务调用节点生成的业务处理结果信息，以及所述服务提供节点的业务处理结果以及扩展信息，并组装成响应对象，回传给该服务调用节点的上游服务调用节点。

5.根据权利要求4所述的系统，其特征在于，

所述服务调用节点还用于，在生成所述业务处理结果时，如果需要向所述上游服务节点提供扩展信息，则通过调用所述API的方式，将该扩展信息写入到该服务调用节点的本地线程上下文中，以便所述远程服务框架中间件将该服务调用节点产生的业务处理结果，扩展结果，以及所述服务提供节点的业务处理结果以及扩展信息进行组装生成响应对象。

6.根据权利要求4所述的系统，其特征在于，

如果所述服务调用节点为业务链路上的起始节点，则所述程服务框架中间件在将所述响应对象回传给所述服务调用节点后，还用于：

将所述响应对象中包含的各节点产生的业务处理结果以及所述扩展信息进行转译，生成文案信息。

7.根据权利要求1至6任一项所述的系统，其特征在于，

所述服务提供节点具体用于，在被调用并得到业务处理结果后，如果业务处理结果存在异常，则调用所述API将扩展信息提供给所述远程服务框架中间件，所述扩展信息包括所述异常对应的原因信息。

8.一种服务调用信息处理方法，其特征在于，包括：

提供应用程序编程接口API，以用于服务提供节点在被调用并得到业务处理结果后，通过调用所述API输出扩展信息；

将所述业务处理结果与所述扩展信息进行整合，生成响应对象；

将所述响应对象回传给服务调用节点。

9.根据权利要求8所述的方法，其特征在于，

所述API被调用后，将所述扩展信息写入所述服务提供节点的本地线程上下文中，所述本地线程上下文中还记录有所述业务处理结果；

所述将所述业务处理结果与所述扩展信息进行整合，生成响应对象，包括：

从所述本地线程上下文读取所述扩展信息以及所述业务处理结果，并将所述业务处理结果与所述扩展信息进行整合，生成响应对象。

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

确定所述服务调用节点在业务链路上的位置信息；

如果是中间节点，则将所述响应对象中包含的信息写入该服务调用节点的本地线程上下文中；

在所述服务调用节点生成业务处理结果后，从该服务调用节点的本地线程上下文中读取该服务调用节点生成的业务处理结果信息，以及所述服务提供节点的业务处理结果以及扩展信息，并组装成响应对象，回传给该服务调用节点的上游服务调用节点。

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

如果所述服务调用节点为业务链路上的起始节点，则将所述响应对象中包含的各节点产生的业务处理结果以及所述扩展信息进行转译，生成文案信息。

12.一种服务调用信息处理方法，其特征在于，包括：

在服务提供节点被调用后，确定业务处理结果信息；

通过调用远程服务框架中间件提供的API输出扩展信息，以用于将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。

13.一种服务调用信息处理装置，其特征在于，包括：

API提供单元，用于提供应用程序编程接口API，以用于服务提供节点在被调用并得到业务处理结果后，通过调用所述API输出扩展信息；

整合处理单元，用于将所述业务处理结果与所述扩展信息进行整合，生成响应对象；

响应对象回传单元，用于将所述响应对象回传给服务调用节点。

14.一种服务调用信息处理装置，其特征在于，包括：

处理结果信息确定单元，用于在服务提供节点被调用后，确定业务处理结果信息；

API调用单元，用于通过调用远程服务框架中间件提供的API输出扩展信息，以用于将所述业务处理结果与所述扩展信息进行整合，生成响应对象，并回传给服务调用节点。

15.一种计算机系统，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

提供应用程序编程接口API，以用于服务提供节点在被调用并得到业务处理结果后，通过调用所述API输出扩展信息；

将所述业务处理结果与所述扩展信息进行整合，生成响应对象；

将所述响应对象回传给服务调用节点。