一种基于重定向的信息传输方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种基于重定向的信息传输方法及装置。

背景技术：

随着信息技术的发展，网络服务商(如：网站)可以为用户提供丰富的业务服务。

对于网络服务商而言，其后台通常设置有服务系统，在服务系统中包含大量的服务器，这些服务器往往采用面向服务架构(Service-Oriented Architecture，SOA)的方式，划分成不同的服务器集群。不同服务器集群具有不同的功能，用以提供不同的业务服务。

现有技术中，用户通过网络操作而获取到的业务服务，通常需要服务系统中具有不同功能的服务器共同实现。也就是说，需要调用或访问服务系统内不同的服务器。为了实现对服务系统内不同的服务功能的调用和访问，通常采用重定向技术，例如：当用户在某商品网站中，对某商品进行下单后，那么，客户端会与服务系统内具有下单功能的下单服务器建立连接，将下单请求发送至该下单服务器中，并在成功下单后，重定向至具有支付功能的服务器，将支付请求发送至支付服务器中，从而，对于在客户端中的表现形式就是当前的页面自动跳转至相应的支付页面。

但是，采用现有技术中的重定向，在客户端调用不同功能时，需要与不同服务器之间进行连接，不仅增加了网络资源的消耗，也增加了业务服务的延时。

技术实现要素：

本申请实施例提供一种基于重定向的信息传输方法及装置，用以解决客户端重定向时获取业务服务的效率较低的问题。

本申请实施例提供的一种基于重定向的信息传输方法，包括：

接收客户端发送的业务请求，并将所述业务请求的第一子业务请求转发至具有第一业务功能的第一服务器，以便所述第一服务器根据所述第一子业务请求，利用所述第一业务功能生成业务标识信息；

接收所述第一服务器反馈的业务标识信息，根据所述业务标识信息生成第二子业务请求；

在服务器侧，根据定向指示信息，将所述第二子业务请求发送至具有第二业务功能的第二服务器，以使得所述第二服务器根据所述第二子业务请求并生成业务信息；

服务器侧接收所述第二服务器反馈的业务信息，将该业务信息转发给客户端。

本申请实施例还提供的一种基于重定向的信息传输方法，包括：

第一服务器根据对客户端发送的业务请求的第一子业务请求的处理结果，生成第二子业务请求，并根据定向指示信息将所述第二子业务请求发送给具有第二业务功能的第二服务器，以使得所述第二服务器根据所述第二子业务请求生成业务信息；

所述第一服务器接收所述第二服务器反馈的业务信息，将该业务信息转发给客户端。

本申请实施例提供的一种基于重定向的信息传输装置，包括：

业务请求模块，用于接收客户端发送的业务请求，并将所述业务请求的第一子业务请求转发至具有第一业务功能的第一服务器，以便所述第一服务器根据所述第一子业务请求，利用所述第一业务功能生成业务标识信息；

第二子业务请求模块，用于接收所述第一服务器反馈的业务标识信息，根据所述业务标识信息生成第二子业务请求；

重定向模块，用于根据定向指示信息，将所述第二子业务请求发送至具有第二业务功能的第二服务器，以使得所述第二服务器根据所述第二子业务请求生成业务信息；

反馈模块，用于接收所述第二服务器反馈的业务信息，将该业务信息转发给客户端。

本申请实施例还提供的一种服务器侧网关，设置于服务系统内，与客户端和该服务系统内的第一服务器和第二服务器相连接，所述服务器侧网关包括：

业务请求模块，用于接收客户端发送的业务请求，并将所述业务请求的第一子业务请求转发至执行第一业务功能的第一服务器，以便所述第一服务器根据所述第一子业务请求，利用所述第一业务功能生成业务标识信息；

第二子业务请求模块，用于接收所述第一服务器反馈的所述业务标识信息，根据所述业务标识信息生成第二子业务请求；

重定向模块，用于根据定向指示信息，将所述第二子业务请求发送至具有第二业务功能的第二服务器，以使得所述第二服务器根据所述第二子业务请求生成业务信息；

反馈模块，用于接收所述第二服务器反馈的业务信息，将该业务信息转发给客户端。

本申请实施例另提供的一种基于重定向的信息传输装置，包括：

发送模块，用于对客户端发送的业务请求的第一子业务请求的处理结果，生成第二子业务请求，并根据定向指示信息将所述第二子业务请求发送给具有第二业务功能的第二服务器，以使得所述第二服务器根据所述第二子业务请求生成业务信息；

反馈模块，用于接收所述第二服务器反馈的业务信息，将该业务信息转发给客户端。

本申请实施例还提供的一种服务系统，所述服务系统与客户端连接，该服务系统包括：

服务器侧网关，用于接收所述客户端发送的业务请求，并将所述业务请求的第一子业务请求转发至执行第一业务功能的第一服务器，接收所述第一服务器反馈的业务标识信息，根据所述业务标识信息生成第二子业务请求，根据定向指示信息，将所述第二子业务请求发送至具有第二业务功能的第二服务器，接收所述第二服务器反馈的业务信息，将该业务信息转发给客户端；

第一服务器，用于接收所述网关发送的业务请求，根据所述业务请求生成所述业务标识信息，将该业务标识信息反馈给所述网关；

第二服务器，用于接收所述网关发送的第二子业务请求，根据所述第二子业务请求生成所述业务信息，将所述业务信息反馈给所述网关。

本申请实施例提供一种基于重定向的信息传输方法及装置，在该方法中，由服务器侧接收客户端的业务请求，并将业务请求中的第一子业务请求转发给第一服务器，并且，该服务器侧会根据第一服务器所反馈的业务标识信息，生成相应的第二子业务请求，并根据定向指示信息对第二子业务请求进行重定向，发送给第二服务器，使得第二服务器创建相应的业务服务，直到第二服务器将创建的业务服务反馈给服务器侧后，服务器侧会将该业务服务通过之前与客户端建立的连接，再发送给客户端。可见，本申请中的重定向操作不发生在客户端中，而是由服务器侧完成，也就是说，在服务器侧内的重定向过程，属于服务系统内的交互，这样的方式，可以有效减少网络环境的限制，并提升了信息传输的效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的基于重定向的信息传输过程；

图2a、2b、2c为本申请实施例提供的应用实例中的基于重定向的信息传 输过程的示意图；

图3为本申请实施例提供的另一种基于重定向的信息传输过程；

图4为本申请实施例提供的基于重定向的信息传输装置结构示意图；

图5为本申请实施例提供的服务器侧网关的结构示意图；

图6为本申请实施例提供的另一种基于重定向的信息传输装置结构示意图；

图7为本申请实施例提供的服务系统的结构示意图。

具体实施方式

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

如图1所示，本申请实施例中提供一种基于重定向的信息传输过程，该过程具体包括如下步骤：

S101，接收客户端发送的业务请求，并将所述业务请求的第一子业务请求转发至具有第一业务功能的第一服务器，以便所述第一服务器根据所述第一子业务请求，利用所述第一业务功能生成业务标识信息。

在实际应用场景下，当用户使用客户端获取业务服务时，通常需要建立与服务器之间的连接(如：服务器连接)。客户端与服务器之间通过网关进行彼此的连接，在本申请实施例中，可由设置于服务器侧的网关实现重定向，其中，服务器侧网关是指一种用于实现服务器与客户端之间建立网络连接的网络设备，客户端侧和服务器侧往往均设置有网关(设置在客户端侧的网关，通常用于实现局域网间的互连，这里不对客户端侧的网关进行说明)。

当然，也可以由设置于服务器侧的其他网络设备完成，如：中间件，或者，专门提供重定向功能的服务器等，这里并不对本申请构成限定。

为了方便描述，在本申请实施例中，以服务器侧网关为执行主体进行说明，这里并不构成对本申请的限定。

在连接建立后，用户便可以使用客户端发出相应的操作，以获取业务服务，如：用户使用客户端，在相应的网站中针对某商品进行下单操作，以购买该商品。上述示例中，用户在客户端上进行了操作后，客户端便会生成相应的业务请求，发送至服务器侧网关，再通过服务器侧网关将该业务请求中的某一子业务请求发送至对应的服务器中。

这里需要说明的是，某些业务服务需要调用服务系统中不同的服务器的功能。例如：用户购买某商品，那么，整个购买过程包括下单和支付两部分，故对于购买过程而言，不仅需要调用下单服务器中的下单功能，也需要调用支付服务器中的支付功能。此时，用户发出了购买请求(购买请求中就包含有下单请求，可以认为，下单请求是整个购买业务的一部分，也即，第一子业务请求)，那么，该下单请求将首先发送至下单服务器中(也即，第一服务器)。

所以，在本申请实施例中，同一业务可能由不同的子业务构成，服务器侧网关接收到了客户端发出的业务请求(如：上例中的购买请求)后，就会将该业务请求中的第一子业务请求(上例中的下单请求)首先发送至具有第一业务功能的第一服务器中，以便所述第一服务器根据所述第一子业务请求，利用所述第一业务功能生成业务标识信息。

S102，接收所述第一服务器反馈的业务标识信息，根据所述业务标识信息生成第二子业务请求。

当服务器侧网关向第一服务器发送了第一子业务请求后，第一服务器就会根据该第一子业务请求进行响应处理，生成与该第一子业务请求对应的业务标识信息发送给服务器侧网关。

延续上例：业务请求是针对某一商品的购买请求，第一子业务请求是下单请求，那么，第一服务器会根据该下单请求，生成相应的订单信息(如：订单号)并反馈。此时，订单信息就是业务标识信息。

需要说明的是，所述的业务标识信息，并非是整个业务过程的最后结果，而是一种中间过程的过渡信息，该业务标识信息可以作为后续过程中的一种标识，如：上例中的订单信息作为一种业务标识信息，可以唯一确定出一笔支付业务，后续就可以根据该订单信息，对这笔支付业务进行支付。

所以，服务器侧网关便可以根据所述业务标识信息执行下一步操作(如：网关根据订单信息，向具有支付功能的服务器请求支付页面)。具体而言，服务器侧网关会根据所述业务标识信息生成第二子业务请求。

这里需要说明的是，第二子业务请求是一种用于进行业务创建的请求。当然，所述的第二子业务请求中携带有所述业务标识信息，或者，第二子业务请求中携带了业务标识信息中起到标识作用的部分信息，这里并不构成对本申请的限定。

S103，在服务器侧，根据定向指示信息，将所述第二子业务请求发送至具有第二业务功能的第二服务器，以使得所述第二服务器根据所述第二子业务请求生成业务信息。

在实际应用中，用户所获取的业务服务，通常需要不同的服务器来共同完成，服务器侧网关所接收到的第一服务器反馈的业务标识信息，只表明了该第一服务器完成了自身的业务服务，而若要使得整个业务完成，就需要调用其他的服务器。

故在本申请中，服务器侧网关会对生成的第二子业务请求进行重定向，使得所述第二子业务请求不再发送至第一服务器，而是发送至其他服务器中(在本申请实施例中，第二子业务请求发送至第二服务器)。其中，所述的第一服务器和第二服务器，分别提供不同的业务服务。

具体而言，本申请中服务器侧网关会根据定向指示信息来进行重定向，也即，所述的定向指示信息用以指示第二子业务请求将要发送的目标位置。在本申请实施例中，所述的定向指示信息有两种来源：一种是由业务标识信息中携带的，另一种是该服务器侧网关自身生成的。服务器侧网关根据所述定向指示 信息，就可以确定出所述第二子业务请求所要发送到的目标位置，也即，将所述第二子业务请求发送至第二服务器。

与现有技术不同的是，现有技术中的重定向过程由客户端实现，而本申请实施例中进行重定向的过程，并不由客户端执行，而是由服务器侧网关完成，显然，由于服务器侧网关处于服务系统中，那么，服务器侧网关便可以便捷地与服务系统内的各服务器进行信息传输，并不受网络环境的限制，而现有技术中，客户端与服务系统中各服务器之间的信息传输将受到网关环境的影响，可见，本申请中服务器侧网关与各服务器之间进行信息传输交互的效率，远高于客户端与各服务器之间进行交互的效率。

S104，服务器侧接收所述第二服务器反馈的业务信息，将该业务信息转发给客户端。

第二服务器接收到了服务器侧网关发送的第二子业务请求后，就会根据该第二子业务请求创建相应的业务，并且生成相应的业务信息并反馈至服务器侧网关中。从而，服务器侧网关会将接收到的该业务信息，转发给客户端。

通过上述步骤可见，本申请实施例中的重定向操作不发生在客户端中，而是由服务器侧网关完成，而服务器侧网关属于服务系统中的一部分，也就是说，服务器侧网关与各服务器之间的交互，属于服务系统内的交互，这样的方式，可以有效减少网络环境的限制，并提升了交互的效率。

需要说明的是，现有技术中客户端进行重定向的方式，客户端需要分别建立不同的连接，以实现与不同服务器进行信息传输交互，例如：在上述示例中，客户端首先需要与下单服务器建立连接，在进行了重定向后，还需要与支付服务器建立连接。显然，这样的方式将增加连接成本以及消耗服务系统的网络资源。

因此，作为本申请实施例中的一种优选方式，服务器侧网关通过与所述客户端建立的连接接收所述业务请求，并通过该连接将所述业务信息反馈至所述客户端。可见，在本申请实施例中，服务器侧网关与客户端之间，只需维持一 条连接即可，这样的方式有效地节约了连接成本，而且，在实际应用中，网络服务商的服务系统，通常为大量的客户端提供业务服务，那么，若服务系统与各客户端之间至维持一条连接，则可以有效节省服务系统的网络资源。

另外，现有技术中客户端重定向的方式，还会增加客户端的流量资源的消耗，具体而言，以上述示例为例，假设客户端向服务系统中的服务器发送请求需要消耗1KB流量，客户端接收服务系统中的服务器反馈的信息需要消耗1KB流量，那么，由于客户端需要分别向下单服务器、支付服务器发送请求，并接收两个服务器所反馈的信息，所以，整个过程需要消耗4KB的流量。而采用本申请实施例中服务器侧网关的重定向方式，服务器侧网关与各服务器之间的信息传输交互均属于服务系统内的交互，而客户端只需向服务器侧网关发送请求、以及接收服务器侧网关反馈的信息，所以，对于客户端而言，整个过程只需消耗2KB流量。显然，本申请中服务器侧网关进行重定向的方式，可以有效节省客户端的流量资源(节省50％)。

在本申请实施例中，对于服务器侧网关而言，由于涉及到不同服务器中不同功能的调用，所以采用应用层中的应用程序编程接口(Application Programming Interface，API)完成对不同服务器中功能的调用以及与不同服务器之间的交互。

所以在本申请实施例中，可以认为服务器侧网关进行重定向的过程，就是变更不同服务器的API的过程。下面将进行详细说明。

作为本申请实施例的一种优选方式，在服务系统中，不同的服务器会将各自的API预先发布给服务器侧网关，这样一来，在该服务器侧网关本地，就可以调用不同服务器的API，实现与不同服务器之间的交互，并获取不同服务器中的各类功能。

在该优选方式下，服务器侧网关向服务器(包括第一服务器和第二服务器)发送请求或接收服务器的反馈，均可以直接通过该服务器侧网关本地已有的API完成。

具体而言，在上述步骤S101中，将所述业务请求转发至具有第一业务功能的第一服务器，具体为：确定与所述第一服务器对应的API，调用所述API，将所述业务请求通过所述API发送至所述第一服务器。

为了能够更清楚的阐述本申请实施例中的具体方案，现将结合附图进行详细说明。

如图2a所示，为客户端、服务系统中的服务器侧网关以及服务器(包括第一服务器和第二服务器)之间的架构。在图2a中，第一服务器对应的API为API 1，第二服务器对应的API为API 2。客户端将业务请求发送到服务器侧网关中，此时，服务器侧网关将确定第一服务器对应的API，也即，确定为API 1，那么，服务器侧网关则会调用该API 1将所述业务请求的第一子业务请求发送至第一服务器中(在图2a中，API 1为实线状态，表示被调用，而API 2为虚线状态，表示未被调用)。并且，服务器侧网关还将通过API 1接收第一服务器反馈的业务标识信息。

当服务器侧网关接收到了第一服务器反馈的业务标识信息后，就会根据该业务标识信息生成第二子业务请求，以在相应的服务器中进行业务服务的创建。这就需要对所述第二子业务请求进行重定向，以发送至相应的服务器中。

而由于本申请的定向指示信息有两种来源：由业务标识信息中携带，或由服务器侧网关自身生成。故下面将针对两种情况进行说明：

一、定向指示信息由业务标识信息中携带

该情况下，在基于SOA架构的服务系统中，对于需要调用多种不同服务功能的业务而言，具有不同服务功能的各服务器之间会预先进行业务约定(业务约定的形式可以是以配置文件的方式实现)，也即，业务约定就表示了某服务器执行整个业务的某一部分，并生成相应的标识信息，其他服务器根据生成的标识信息，执行该业务的后续部分，从而，形成一个完整的业务服务。

所以，第一服务器在生成了业务标识信息后，该业务标识信息中就包含了定向指示信息，从而，当服务器侧网关接收到了第一服务器所反馈的业务标识 信息后，便可以直接根据其中的定向指示信息，进行重定向的操作，也即，当所述业务标识信息中携带有定向指示信息时，根据定向指示信息，将所述第二子业务请求发送至具有第二业务功能的第二服务器，具体为：确定所述定向指示信息对应的API，确定所述API对应的第二服务器，调用所述API将所述第二子业务请求发送至与所述API对应的第二服务器。

沿用上例，当网关生成第二子业务请求后，将根据定向指示信息确定出与该第二子业务请求对应API(该API的第二服务器)，此时，网关将调用与第二服务器对应的API，也即，API 2，并通过API 2将所述第二子业务请求发送至第二服务器。即如图2b所示，API 2为实线状态，表示已经被调用。

二、定向指示信息由服务器侧网关自身生成

在实际应用场景下，对于某些业务标识信息，其中并未携带有定向指示信息，例如：用户在某网站中使用自身的用户信息进行注册后，账户服务器会返回注册成功的响应结果，但是，该响应结果中并为包含有定向指示信息。此时，服务器侧网关就需要自身生成相应的定向指示信息，以便执行后续业务。

具体而言，在本申请实施例中，当所述业务标识信息中未携带有定向指示信息时，所述方法还包括：服务器侧网关根据预设的业务逻辑关系，确定与所述业务标识信息对应的业务服务，确定所述业务服务所对应的API，生成定向指示信息。

其中，所述的业务逻辑关系，指示了一套完整的业务服务流程内，各服务器执行不同功能的先后顺序。所述的业务逻辑关系可以采用配置文件的方式存储在服务器侧网关，该业务逻辑关系可以由服务系统的主机进行更新，当然，这里并不构成对本申请的限定。

沿用上述注册的示例，服务器侧网关根据所述业务逻辑关系，可以获知，当账户服务器返回注册成功的响应结果后，应该根据该响应结果，向网站资源服务器发送请求，获取相应网站资源(表现形式可以是跳转回主页，或者是解锁页面中未显示的内容等等)。

从而，根据定向指示信息，将所述第二子业务请求发送至具有第二业务功能的第二服务器，具体为：确定所述定向指示信息对应的API，确定所述API对应的第二服务器，调用所述API将所述第二子业务请求发送至与所述API对应的第二服务器。

当然，针对上述两种情况下，当服务器侧网关向第二服务器传输信息时，与第一服务器对应的API仍处于被调用的状态，也就是服务器侧网关与第一服务器还保持着连接，显然，这样的方式可能会造成网络资源的浪费(因为进行了重定向后，服务器侧网关不再使用第一服务器的API)。所以，作为一种更为优选的方式，在本申请实施例中，在调用所述API将所述第二子业务请求发送至与所述API对应的第二服务器之前，还包括：停用与所述第一服务器对应的API。

如图2c所示，当停用了与第一服务器对应的API后，图2c中的API 1处于虚线状态，表示未被调用，API 2为实线状态，表示已被调用。

经过上述步骤后，服务器侧网关会在接收到第二服务器反馈的业务信息后，将业务信息通过与客户端之间的连接，发送给客户端(仅与客户端维持一条连接)。

作为本申请实施例的另一种方式，服务器侧网关中的API并非是由不同服务器预先发布的，而是当服务器侧网关需要向相应的服务器传输信息时，再从相应的服务器中获取API。在该方式下，服务器侧网关所执行的信息传输的过程与上述方式相类似，故在此不再敖述。

上述的某些实施例中，由服务器侧网关实现与第一服务器和第二服务器之间的信息传输交互，从而减少了与客户端的交互次数，这样的方式有利于提升客户端获得业务服务的效率。从上述内容中可见，服务器侧网关与第一服务器和第二服务器之间的信息交互虽然属于整个服务系统内的交互，但可以是几个不同设备之间的信息交互，这种情形下会在一定程度上占用整个服务系统内的传输资源。基于此，本申请实施例中还提供了一种基于重定向的信息传输方法， 如图3所示，该方法包括：

S301，第一服务器根据对客户端发送的业务请求的第一子业务请求的处理结果，并根据定向指示信息将所述第二子业务请求发送给具有第二业务功能的第二服务器，以使得所述第二服务器根据所述第二子业务请求生成业务信息。

这里所述的业务请求与上述实施例中的相同，均可由客户端发出，该业务请求中同样可以包含第一子业务请求，这里不再过多赘述。同理，这里的第二服务器，也是上述实施例中具有第二业务功能的服务器。

与上述方法不同之处包括，本实施例中客户端所发出的业务请求可以直接发送给该第一服务器中，由该第一服务器对业务请求的第一子业务请求进行处理，处理结果中可以包含业务标识信息，随后，第一服务器进一步根据业务标识信息生成第二子业务请求发送给第二服务器。

S302，所述第一服务器接收所述第二服务器反馈的业务信息，将该业务信息反馈至客户端。

在本方法中，第一服务器可以直接实现与客户端以及第二服务器的信息交互。这种方式能够节省服务系统内部的信息传输资源，进而提升信息传输的效率。

以上为本申请提供的基于重定向的信息传输方法的几种实施例，基于同样的思路，本申请还提供了基于重定向的信息传输装置的实施例，如图4所示。图4中的基于重定向的信息传输装置，所述装置包括：业务请求模块401、第二子业务请求模块402、重定向模块403以及反馈模块404，其中，

所述业务请求模块401，用于接收客户端发送的业务请求，并将所述业务请求的第一子业务请求转发至具有第一业务功能的第一服务器。

所述第二子业务请求模块402，用于接收所述第一服务器反馈的业务标识信息，根据所述业务标识信息生成第二子业务请求。

所述重定向模块403，用于根据定向指示信息，将所述第二子业务请求发送至具有第二业务功能的第二服务器，以使得所述第二服务器根据所述第二子 业务请求生成业务信息。

所述反馈模块404，用于接收所述第二服务器反馈的业务信息，将该业务信息转发至客户端。

需要说明的是，在本申请实施例中，服务器侧通过与所述客户端建立的连接接收所述业务请求，并通过该连接将所述业务信息反馈至所述客户端。

所述业务请求模块401，具体用于确定与所述第一服务器对应的API，调用所述API，将所述业务请求的第一子业务请求通过所述API发送至所述第一服务器，以便所述第一服务器根据所述第一子业务请求，利用所述第一业务功能生成业务标识信息。

所述重定向模块403，具体用于确定所述定向指示信息对应的API，确定所述API对应的第二服务器，调用所述API将所述第二子业务请求发送至与所述API对应的第二服务器。

在本申请实施例中的一种场景下，所述定向指示信息包括：携带在所述业务标识信息中的定向指示信息。

然而在实际应用中，并非全部的定向指示信息均由业务标识信息携带，在这样的场景下，当所述业务标识信息中携带有定向指示信息时，所述重定向模块403，还用于根据预设的业务逻辑关系，确定与所述业务标识信息对应的业务服务，确定所述业务服务所对应的API，生成定向指示信息。

另外，作为本申请实施例中的一种优选方式，所述重定向模块403，还用于在调用所述API将所述第二子业务请求发送至与所述API对应的第二服务器之前，停用与所述第一服务器对应的API。

本申请实施例还提供一种服务器侧网关，如图5所示。其中，所述服务器侧网关设置于服务系统内，与客户端和该服务系统内的第一服务器和第二服务器相连接，所述服务器侧网关包括：

业务请求模块501、第二子业务请求模块502、重定向模块503以及反馈模块504，其中，

业务请求模块501，用于接收客户端发送的业务请求，并将所述业务请求的第一子业务请求转发至具有第一业务功能的第一服务器，以便所述第一服务器根据所述第一子业务请求，利用所述第一业务功能生成业务标识信息；

第二子业务请求模块502，用于接收所述第一服务器反馈的业务标识信息，根据所述业务标识信息生成第二子业务请求；

重定向模块503，用于根据定向指示信息，将所述第二子业务请求发送至具有第二业务功能的第二服务器，以使得所述第二服务器根据所述第二子业务请求生成业务信息；

反馈模块504，用于接收所述第二服务器反馈的业务信息，将该业务信息转发至客户端。

需要说明的是，服务器侧通过与所述客户端建立的连接接收所述业务请求，并通过该连接将所述业务信息反馈至所述客户端。

对于上述模块，具体而言，所述业务请求模块501，具体用于确定与所述第一服务器对应的API，调用所述API，将所述业务请求通过所述API发送至所述第一服务器。

所述重定向模块503，具体用于确定所述定向指示信息对应的API，确定所述API对应的第二服务器，调用所述API将所述第二子业务请求发送至与所述API对应的第二服务器。

所述定向指示信息包括：携带在所述业务标识信息中的定向指示信息。

而在某些实际应用场景中，某些业务标识信息中并未携带定向指示信息，故在本申请实施例中，当所述业务标识信息中携带有定向指示信息时，所述重定向模块503，还用于根据预设的业务逻辑关系，确定与所述业务标识信息对应的业务服务，确定所述业务服务所对应的API，生成定向指示信息。

当然，作为一种优选方式，所述重定向模块503，还用于在调用所述API将所述第二子业务请求发送至与所述API对应的第二服务器之前，停用与所述第一服务器对应的API。

本申请还提供基于重定向的信息传输装置，如图6所示，设置在第一服务器中，包括：

发送模块601，用于根据对客户端发送的业务请求的第一子业务请求的处理结果，生成第二子业务请求，并根据定向指示信息将所述第二子业务请求发送给具有第二业务功能的第二服务器，以使得所述第二服务器根据所述第二子业务请求生成业务信息。

反馈模块602，用于接收所述第二服务器反馈的业务信息，将该业务信息转发给客户端。

本申请还提供一种服务器系统，如图7所示。其中，所述服务系统与客户端连接，该服务系统包括：

服务器侧网关701，用于接收所述客户端发送的业务请求，并将所述业务请求的第一子业务请求转发至具有第一业务功能的第一服务器，接收所述第一服务器反馈的业务标识信息，根据所述业务标识信息生成第二子业务请求，根据定向指示信息，将所述第二子业务请求发送至具有第二业务功能的第二服务器，接收所述第二服务器反馈的业务信息，将该业务信息转发给客户端。

第一服务器702，用于接收所述服务器侧网关发送的业务请求，根据所述业务请求生成所述业务标识信息，将该业务标识信息反馈给所述服务器侧网关。

第二服务器703，用于接收所述服务器侧网关发送的第二子业务请求，根据所述第二子业务请求生成所述业务信息，将所述业务信息反馈给所述服务器侧网关。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任 何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。