一种请求处理方法及装置与流程

本申请涉及计算机技术领域，尤其是涉及一种请求处理方法及装置。

背景技术：

目前，智能终端上运行的应用需要在多种类型的渠道上发布，如游戏平台、应用商店、苹果appstore和googleplay等，渠道能够提供应用的下载与更新服务，还可以提供登录和支付服务。通常应用在渠道上发布时，需要接入渠道的服务接口。

然而，由于渠道的种类极多，并且每个渠道的接入参数都互不相同，应用的提供方需要通过不同渠道的软件开发工具包(softwaredevelopmentkit，sdk)接入不同类型的渠道服务器，针对每一种类型的渠道逐一进行接入设置，在对渠道接入参数进行更新、维护时也需要逐一进行配置，难以进行维护工作。

技术实现要素：

有鉴于此，本申请的目的在于提供一种请求方法及装置，可以灵活使用不同渠道的服务能力，方便了开发上的管理和维护。

本申请实施例提供了一种请求处理方法，应用于多渠道管理服务器，所述多渠道管理服务器用于结合多渠道管理客户端，为应用提供针对多种渠道类型的服务能力管理服务；所述方法包括：

接收多渠道管理客户端在应用客户端触发目标服务请求后，发送的目标指令信息；

根据所述目标指令信息所指示的渠道类型、预先获取的渠道参数信息，以及基于参数模板为每个所述渠道参数信息自动适配的参数类型，向与所述渠道类型对应的渠道服务器请求获取返回信息；

基于所述返回信息向所述多渠道管理客户端反馈目标服务响应信息，以便所述多渠道管理客户端根据所述目标服务响应信息响应所述目标服务请求。

在一些可能的实施方式中，在所述目标服务请求为登录请求的情况下：所述接收多渠道管理客户端在应用客户端触发目标服务请求后，发送的目标指令信息，包括：

接收多渠道管理客户端在应用客户端触发登录请求后，发送的包含登录令牌信息和渠道类型信息的所述目标指令信息，所述登录令牌信息为所述多渠道管理客户端向所述渠道服务器发起登录请求后，获取的所述渠道服务器的返回值；

所述向与所述渠道类型对应的渠道服务器请求获取与所述目标服务请求对应的返回信息，包括：

向与所述渠道类型对应的渠道服务器发送携带有所述登录令牌信息的登录验证请求，以便所述渠道服务器在验证所述登录令牌信息后返回用户信息；

所述向所述多渠道管理客户端反馈目标服务响应信息，包括：

向所述多渠道管理客户端反馈所述多渠道管理服务器提供的用于登录的临时票据。

在一些可能的实施方式中，基于所述返回信息向所述多渠道管理客户端反馈目标服务响应信息之后，还包括：

接收应用服务器发送的登录验证信息，并对所述登录验证信息进行验证；

在验证通过后，将所述用户信息发送给所述应用服务器。

在一些可能的实施方式中，所述登录验证信息中包括所述临时票据和签名信息；

所述对所述登录验证信息进行验证，包括：

验证所述临时票据是否为之前分配的临时票据，并基于预先分配给所述应用的密钥校验所述签名信息是否正确。

在一些可能的实施方式中，在所述目标服务请求为支付请求的情况下：

所述接收多渠道管理客户端在应用客户端触发目标服务请求后，发送的目标指令信息，包括：

接收多渠道管理客户端在应用客户端触发支付请求后，发送的支付信息；

所述向与所述渠道类型对应的渠道服务器请求获取与所述目标服务请求对应的返回信息，包括：

向与所述渠道类型对应的渠道服务器请求与所述支付信息对应的渠道订单信息；所述渠道订单信息中包含有与所述渠道类型关联的订单信息；

所述向所述多渠道管理客户端反馈目标服务响应信息，包括：

根据所述渠道订单信息，生成用于支付的中转订单信息；所述中转订单信息包括所述渠道订单信息，以及多渠道管理订单信息，所述多渠道管理订单信息中包含有与所述多渠道管理服务器关联的订单信息；

向所述多渠道管理客户端反馈所述中转订单信息，以便所述多渠道管理客户端基于所述中转订单信息向所述渠道服务器发起支付流程。

在一些可能的实施方式中，基于所述返回信息向所述多渠道管理客户端反馈目标服务响应信息之后，还包括：

接收所述渠道服务器发送的支付结果，并对所述支付结果进行验证；

在验证通过后，将所述支付结果发送至所述应用服务器，以便所述应用服务器对所述支付结果进行验证。

在一些可能的实施方式中，所述基于参数模板为每个所述渠道参数信息自动适配参数类型，包括：

根据预先设置的属性类型，确定与所述渠道类型对应的每个所述渠道参数信息的属性信息；

根据每个所述渠道参数信息对应的所述属性信息，以及所述参数模板，确定每个所述渠道参数信息的参数类型信息。

在一些可能的实施方式中，所述方法还包括生成所述参数模板的步骤：

获取参考应用的应用客户端访问所述渠道服务器时使用的至少一个初始渠道参数信息及每个初始渠道参数信息对应的参数类型信息；

根据预先设置的属性类型，确定每个初始渠道参数信息的属性信息；

根据每个初始渠道参数信息的参数类型信息和属性信息，生成所述参数模板。

在一些可能的实施方式中，在生成所述参数模板后，所述方法还包括：

根据生成的所述参数模板，确定每个渠道参数信息对应的参数类型信息；

根据每个所述渠道参数信息及其对应的所述参数类型信息，模拟接入所述渠道服务器的客户端向所述渠道服务器发起登录请求；

确定所述渠道服务器的第一返回信息是否异常；

若所述第一返回信息存在异常，则确定所述参数模板配置错误。

在一些可能的实施方式中，在确定所述渠道服务器的第一返回信息是否异常之后，所述方法还包括：

若所述第一返回信息不存在异常，则根据所述第一返回信息、所述渠道参数信息及所述参数模板，向所述渠道服务器发起登录验证请求；

确定所述渠道服务器的第二返回信息是否异常；

若所述第二返回信息存在异常，则确定所述参数模板配置错误。

本申请实施例还提供了另一种请求处理方法，应用于多渠道管理客户端，所述多渠道管理客户端用于结合多渠道管理服务器，为应用提供针对多种渠道类型的服务能力管理服务；所述方法包括：

接收应用客户端发送的目标服务请求，确定所述目标服务请求对应的目标指令信息；

将所述目标指令信息发送至所述多渠道管理服务器，所述目标指令信息用于所述多渠道管理服务器根据所述目标指令信息中所指示的渠道类型、预先获取的渠道参数信息，以及基于参数模板为每个所述渠道参数信息自动适配的参数类型，向与所述渠道类型对应的渠道服务器请求获取返回信息；

接收所述多渠道管理服务器基于所述返回信息反馈的目标服务响应信息，并根据所述目标服务响应信息响应所述目标服务请求。

在一些可能的实施方式中，在所述目标服务请求为登录请求的情况下：

所述返回信息为所述渠道服务器在验证所述多渠道管理服务器发送的登录验证请求中携带的登录验证信息后，返回给所述多渠道管理服务器的用户信息；

所述确定所述目标服务请求对应的目标指令信息，包括：

根据所述目标服务请求指示的渠道类型，调用所述渠道类型对应的渠道服务器的登录接口，获取包含登录令牌信息和渠道类型信息的所述目标指令信息；

所述接收所述多渠道管理服务器反馈的目标服务响应信息，包括：

接收所述多渠道管理服务器反馈的所述多渠道管理服务器提供的用于登录的临时票据。

在一些可能的实施方式中，根据所述目标服务响应信息响应所述目标服务请求，包括：

将所述临时票据发送至所述应用客户端，以便所述应用客户端将所述临时票据发送至所述应用客户端对应的应用服务器。

在一些可能的实施方式中，在所述目标服务请求为支付请求的情况下：

所述返回信息中包括所述渠道服务器提供的与所述支付信息对应的渠道订单信息；

所述确定所述目标服务请求对应的目标指令信息，包括：

确定所述支付请求携带的支付信息；

所述接收所述多渠道管理服务器反馈的目标服务响应信息，包括：

接收所述多渠道管理服务器反馈的、根据所述渠道订单信息生成的用于支付的中转订单信息；所述中转订单信息包括所述渠道订单信息，以及多渠道管理订单信息，所述多渠道管理订单信息中包含有与所述多渠道管理服务器关联的订单信息。

在一些可能的实施方式中，所述根据所述目标服务响应信息响应所述目标服务请求，包括：

根据所述中转订单信息中的所述多渠道管理订单信息，调用所述渠道服务器的支付接口，根据所述中转订单信息中的渠道订单信息向所述渠道服务器发起支付流程，并获取所述渠道服务器返回的支付结果；

将所述支付结果发送至所述应用客户端。

本申请实施例还提供了一种请求处理装置，用于多渠道管理服务器，所述多渠道管理服务器用于结合多渠道管理客户端，为应用提供针对多种渠道类型的服务能力管理服务；所述装置包括：

接收模块，用于接收多渠道管理客户端在应用客户端触发目标服务请求后，发送的目标指令信息；

请求模块，用于根据所述目标指令信息所指示的渠道类型、预先获取的渠道参数信息，以及基于参数模板为每个所述渠道参数信息自动适配的参数类型，向与所述渠道类型对应的渠道服务器请求获取返回信息；

反馈模块，用于基于所述返回信息向所述多渠道管理客户端反馈目标服务响应信息，以便所述多渠道管理客户端根据所述目标服务响应信息响应所述目标服务请求。

在一些可能的实施方式中，在所述目标服务请求为登录请求的情况下：所述接收模块具体用于：

接收多渠道管理客户端在应用客户端触发登录请求后，发送的包含登录令牌信息和渠道类型信息的所述目标指令信息，所述登录令牌信息为所述多渠道管理客户端向所述渠道服务器发起登录请求后，获取的所述渠道服务器的返回值；

所述请求模块在向与所述渠道类型对应的渠道服务器请求获取与所述目标服务请求对应的返回信息时，具体用于：

向与所述渠道类型对应的渠道服务器发送携带有所述登录令牌信息的登录验证请求，以便所述渠道服务器在验证所述登录令牌信息后返回用户信息；

所述反馈模块在向所述多渠道管理客户端反馈目标服务响应信息时，具体用于：

向所述多渠道管理客户端反馈所述多渠道管理服务器提供的用于登录的临时票据。

在一些可能的实施方式中，所述装置还包括第一验证模块，所述第一验证模用于在基于所述返回信息向所述多渠道管理客户端反馈目标服务响应信息之后：

接收应用服务器发送的登录验证信息，并对所述登录验证信息进行验证；

在验证通过后，将所述用户信息发送给所述应用服务器。

在一些可能的实施方式中，所述登录验证信息中包括所述临时票据和签名信息；

所述第一验证模块在对所述登录验证信息进行验证时，具体用于：

验证所述临时票据是否为之前分配的临时票据，并基于预先分配给所述应用的密钥校验所述签名信息是否正确。

在一些可能的实施方式中，在所述目标服务请求为支付请求的情况下：

所述接收模块在接收多渠道管理客户端在应用客户端触发目标服务请求后，发送的目标指令信息时，具体用于：

接收多渠道管理客户端在应用客户端触发支付请求后，发送的支付信息；

所述请求模块在向与所述渠道类型对应的渠道服务器请求获取与所述目标服务请求对应的返回信息时，具体用于：

向与所述渠道类型对应的渠道服务器请求与所述支付信息对应的渠道订单信息；所述渠道订单信息中包含有与所述渠道类型关联的订单信息；

所述反馈模块在向所述多渠道管理客户端反馈目标服务响应信息时，具体用于：

根据所述渠道订单信息，生成用于支付的中转订单信息；所述中转订单信息包括所述渠道订单信息，以及多渠道管理订单信息，所述多渠道管理订单信息中包含有与所述多渠道管理服务器关联的订单信息；

向所述多渠道管理客户端反馈所述中转订单信息，以便所述多渠道管理客户端基于所述中转订单信息向所述渠道服务器发起支付流程。

在一些可能的实施方式中，装置还包括第二验证模块，所述第二验证模块用于在基于所述返回信息向所述多渠道管理客户端反馈目标服务响应信息之后：

接收所述渠道服务器发送的支付结果，并对所述支付结果进行验证；

在验证通过后，将所述支付结果发送至所述应用服务器，以便所述应用服务器对所述支付结果进行验证。

在一些可能的实施方式中，所述请求模块在基于参数模板为每个所述渠道参数信息自动适配参数类型时，具体用于：

根据预先设置的属性类型，确定与所述渠道类型对应的每个所述渠道参数信息的属性信息；

根据每个所述渠道参数信息对应的所述属性信息，以及所述参数模板，确定每个所述渠道参数信息的参数类型信息。

在一些可能的实施方式中，所述装置还包括参数模板生成模块，所述参数模板生成模块用于：

获取参考应用的应用客户端访问所述渠道服务器时使用的至少一个初始渠道参数信息及每个初始渠道参数信息对应的参数类型信息；

根据预先设置的属性类型，确定每个初始渠道参数信息的属性信息；

根据每个初始渠道参数信息的参数类型信息和属性信息，生成所述参数模板。

在一些可能的实施方式中，所述装置还包括参数模板测试模块，所述参数模板测试模块用于：

根据生成的所述参数模板，确定每个渠道参数信息对应的参数类型信息；

根据每个所述渠道参数信息及其对应的所述参数类型信息，模拟接入所述渠道服务器的客户端向所述渠道服务器发起登录请求；

确定所述渠道服务器的第一返回信息是否异常；

若所述第一返回信息存在异常，则确定所述参数模板配置错误。

在一些可能的实施方式中，所述参数模板测试模块还用于：

若所述第一返回信息不存在异常，则根据所述第一返回信息、所述渠道参数信息及所述参数模板，向所述渠道服务器发起登录验证请求；

确定所述渠道服务器的第二返回信息是否异常；

若所述第二返回信息存在异常，则确定所述参数模板配置错误。

本申请实施例还提供了一种请求处理装置，用于多渠道管理客户端，所述多渠道管理客户端用于结合多渠道管理服务器，为应用提供针对多种渠道类型的服务能力管理服务；所述装置包括：

确定模块，用于接收应用客户端发送的目标服务请求，确定所述目标服务请求对应的目标指令信息；

发送模块，用于将所述目标指令信息发送至所述多渠道管理服务器，所述目标指令信息用于所述多渠道管理服务器根据所述目标指令信息中所指示的渠道类型、预先获取的渠道参数信息，以及基于参数模板为每个所述渠道参数信息自动适配的参数类型，向与所述渠道类型对应的渠道服务器请求获取返回信息；

响应模块，用于接收所述多渠道管理服务器基于所述返回信息反馈的目标服务响应信息，并根据所述目标服务响应信息响应所述目标服务请求。

在一些可能的实施方式中，在所述目标服务请求为登录请求的情况下：

所述返回信息为所述渠道服务器在验证所述多渠道管理服务器发送的登录验证请求中携带的登录验证信息后，返回给所述多渠道管理服务器的用户信息；

所述确定模块在确定所述目标服务请求对应的目标指令信息时，具体用于：

根据所述目标服务请求指示的渠道类型，调用所述渠道类型对应的渠道服务器的登录接口，获取包含登录令牌信息和渠道类型信息的所述目标指令信息；

所述响应模块在接收所述多渠道管理服务器反馈的目标服务响应信息时，具体用于：

接收所述多渠道管理服务器反馈的所述多渠道管理服务器提供的用于登录的临时票据。

在一些可能的实施方式中，所述响应模块在根据所述目标服务响应信息响应所述目标服务请求时，具体用于：

将所述临时票据发送至所述应用客户端，以便所述应用客户端将所述临时票据发送至所述应用客户端对应的应用服务器。

在一些可能的实施方式中，在所述目标服务请求为支付请求的情况下：

所述返回信息中包括所述渠道服务器提供的与所述支付信息对应的渠道订单信息；

所述确定模块在确定所述目标服务请求对应的目标指令信息时，具体用于：

确定所述支付请求携带的支付信息；

所述响应模块在接收所述多渠道管理服务器反馈的目标服务响应信息时，具体用于：

接收所述多渠道管理服务器反馈的、根据所述渠道订单信息生成的用于支付的中转订单信息；所述中转订单信息包括所述渠道订单信息，以及多渠道管理订单信息，所述多渠道管理订单信息中包含有与所述多渠道管理服务器关联的订单信息。

在一些可能的实施方式中，所述响应模块在根据所述目标服务响应信息响应所述目标服务请求时，具体用于：

根据所述中转订单信息中的所述多渠道管理订单信息，调用所述渠道服务器的支付接口，根据所述中转订单信息中的渠道订单信息向所述渠道服务器发起支付流程，并获取所述渠道服务器返回的支付结果；

将所述支付结果发送至所述应用客户端。

本申请实施例还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如上述的请求处理方法的步骤。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如上述的请求处理方法的步骤。

本申请实施例提供的请求处理方法及装置，多渠道管理服务器首先接收多渠道管理客户端在应用客户端触发目标服务请求后，发送的目标指令信息；然后，根据所述目标指令信息所指示的渠道类型、预先获取的渠道参数信息，以及基于参数模板为每个所述渠道参数信息自动适配的参数类型，向与所述渠道类型对应的渠道服务器请求获取返回信息；最后，基于所述返回信息向所述多渠道管理客户端反馈目标服务响应信息，以便所述多渠道管理客户端根据所述目标服务响应信息响应所述目标服务请求。本申请通过设置多渠道管理服务器和多渠道管理客户端，将应用需要接入的多个渠道进行统一管理，可以灵活使用不同渠道的服务能力，方便了开发上的管理和维护；此外，多渠道管理服务器引入了参数模板来自动适配参数类型，减少了应用开发人员针对不同渠道进行参数类型配置的开发难度。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例所提供的一种请求处理系统的结构示意图；

图2示出了本申请实施例所提供的一种请求处理方法的流程图；

图3示出了本申请实施例所提供的另一种请求处理方法的流程图；

图4示出了本申请实施例所提供的再一种请求处理方法的流程图；

图5示出了本申请实施例所提供的一种请求处理装置的结构示意图；

图6示出了本申请实施例所提供的另一种请求处理装置的结构示意图；

图7示出了本申请实施例所提供的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的每个其他实施例，都属于本申请保护的范围。

智能终端上运行的应用需要在多种类型的渠道上发布，渠道能够提供应用的下载与更新服务，还可以提供登录和支付服务。通常应用在渠道上发布时，需要接入渠道的服务接口。由于渠道的种类极多，并且每个渠道的接入参数都互不相同，应用的提供方需要通过不同渠道的sdk接入不同类型的渠道服务器，针对每一种类型的渠道逐一进行接入设置，在对渠道接入参数进行更新、维护时也需要逐一进行配置，维护复杂度较高。

基于此，本申请实施例提供了一种请求处理系统，以灵活使用不同渠道的服务能力，方便了开发上的管理和维护。

请参阅图1，图1为本申请实施例所提供的一种请求处理系统的结构示意图。如图1中所示，本申请实施例提供的请求处理系统，包括应用客户端、应用服务器、多渠道管理客户端、多渠道管理服务器及渠道服务器。

应用客户端可以与应用服务器、多渠道管理客户端进行通信；多渠道管理客户端与多渠道管理服务器之间可以进行通信，还可以与渠道服务器进行通信；应用服务器还可以与多渠道管理服务器进行通信。

其中，多渠道管理客户端可以集成在应用客户端中，渠道服务器可以有多个，每个渠道服务器对应一种渠道类型。多渠道管理服务器结合多渠道管理客户端，可以为应用提供针对多种渠道类型的服务能力管理服务。

基于上述请求处理系统，本申请实施例还提供一种请求处理方法。请参阅图2，图2为本实施例提供的请求处理方法的流程图。如图2所示，本申请实施例提供的请求处理方法，包括：

s201、应用客户端响应目标服务触发操作，向多渠道管理客户端发送目标服务请求，所述目标服务请求携带有所述应用客户端对应的渠道类型。

该步骤中，当应用客户端检测到用户输入的目标服务触发操作时，可以向多渠道管理客户端发送目标服务请求，目标服务请求中可以携带有应用客户端的身份标识、应用客户端对应的渠道类型、目标服务的类型、目标服务的具体内容等。

其中，目标服务的类型可以包括登录、支付等需要与渠道服务器进行交互的服务。

s202、多渠道管理客户端接收应用客户端发送的目标服务请求，确定所述目标服务请求对应的目标指令信息。

该步骤中，多渠道管理客户端在接收目标服务请求后，可以根据目标服务请求确定目标指令信息，目标指令信息可以包括应用客户端的身份标志、应用客户端对应的渠道类型、目标服务的类型、目标服务的具体内容、令牌信息等，目标指令信息用于使多渠道管理服务器根据目标指令信息向渠道服务器请求返回信息。不同类型的目标服务对应的目标指令信息的内容可以是不同的。

s203、多渠道管理客户端将所述目标指令信息发送至所述多渠道管理服务器。

s204、多渠道管理服务器在接收多渠道管理客户端发送的目标指令信息后，根据所述目标指令信息所指示的渠道类型、预先获取的渠道参数信息，以及基于参数模板为每个所述渠道参数信息自动适配的参数类型，向与所述渠道类型对应的渠道服务器请求获取返回信息。

该步骤中，多渠道管理服务器在接收到目标指令信息后，可以根据目标指令信息指示的渠道类型、预先获取的渠道参数信息，以及基于参数模板为每个所述渠道参数信息自动适配的参数类型，向与该渠道类型对应的渠道服务器请求获取与目标服务请求对应的返回信息，具体的，多渠道管理服务器可以先向与渠道类型对应的渠道服务器请求渠道访问参数，再根据参数模板确定每个请求到的渠道访问参数的参数类型信息，并根据每个渠道访问参数及其对应的参数类型信息，调用渠道服务器的服务接口，将目标指令信息发送给渠道服务器，向渠道服务器请求获取返回信息，目标指令信息中可以携带有目标服务请求。

这里，预先获取的渠道参数信息是应用调用渠道服务器需要的参数信息；渠道参数信息可以是多渠道管理服务器在首次接入渠道服务器时获取到的。

具体的，参数模板中可以包括有渠道参数信息的参数类型信息与属性信息的对应关系，具有不同参数类型信息的渠道参数信息具有不同的属性信息。

在一些实施例中，在多渠道管理服务器向渠道服务器请求返回信息时，需要调用渠道服务器的服务端口，基于参数模板为每个所述渠道参数信息自动适配参数类型具体可以包括：

根据预先设置的属性类型，确定与所述渠道类型对应的每个所述渠道参数信息的属性信息；

根据每个所述渠道参数信息对应的所述属性信息，以及所述参数模板，确定每个所述渠道参数信息的参数类型信息。

其中，参数模板是根据初始渠道参数信息确定的，由于初始渠道参数信息与渠道参数信息是同种类的参数信息，参数模板中含有的初始渠道参数信息的属性信息与参数类型信息之间的对应关系，可以直接应用到调用渠道服务器的服务端口所需的渠道参数信息的参数类型以及该渠道参数信息对应的属性信息上，渠道参数信息的属性信息可以包括参数的长度、字符类型、参数名称、参数数量等信息，由于不同类型的渠道服务器的端口配置不同，调用服务端口所需的渠道参数信息也不同，并且每个渠道参数信息之间也互不相同，每个渠道参数信息的特征都是独有的，因此，可以通过渠道参数信息的属性信息确定渠道参数信息的类型信息，再根据类型信息使用这些渠道参数信息。

该步骤中，可以根据预先设置的属性类型，确定渠道参数信息各个属性类型对应的属性信息，如确定每个渠道参数信息的长度、参数名称等。确定好属性信息后，可以从参数模板中确定与确定的属性信息对应的参数类型信息，并将该参数类型信息作为该渠道参数信息的参数类型信息。

渠道参数信息的类型可以包括appid、appkey、appsecret、cpid等类型，访问不同类型的渠道服务器所需的渠道参数信息类型也不同。

该步骤中，渠道参数信息可以是向渠道服务器预先请求的参数信息，也可以是在调用渠道服务器时实时请求的参数信息，渠道参数信息是调用渠道服务器的服务接口所需的参数的参数值。

由于在每次调用渠道服务器的服务接口时，不同应用所需的参数的值可能会改变，并且在服务接口更新维护后参数的值也可能会改变，但所需参数的类型不便，因此，需要识别渠道服务器返回的渠道参数信息的参数类型信息，通过在初次接入渠道服务器时获取的初始渠道参数信息及初始渠道参数信息对应的参数类型信息，生成参数模板，可以在再次请求渠道参数信息时，根据参数模板确定每个渠道参数信息的参数类型信息，并根据参数类型信息使用渠道参数信息。

示例性的，参数模板可以是形如＂a＝1，a，b＂的字符串，其中，a表示参数类型信息，1、a、b分别为该类型信息对应的渠道参数信息的属性信息。

进一步的，在一些可能的实施例中，可以通过以下步骤生成参数模板：

获取参考应用的应用客户端访问所述渠道服务器时使用的至少一个初始渠道参数信息及每个初始渠道参数信息对应的参数类型信息；

根据预先设置的属性类型，确定每个初始渠道参数信息的属性信息；

根据每个初始渠道参数信息的参数类型信息和属性信息，生成所述参数模板。

该步骤中，多渠道管理服务器在获取到参考应用的应用客户端访问渠道服务器所需的至少一个所述初始参数信息及每个测试参数信息对应的参数类型信息之后，可以根据参数类型信息与初始渠道参数信息的属性信息之间的对应关系，生成参数模板。

其中，参考应用可以是同样需要接入与渠道类型对应的渠道服务器的应用，其访问渠道服务器时所使用的初始渠道参数信息与当前的应用所需要的参数信息的属性信息、参数类型信息一致，具体的参数值存在区别。

在一些可能的实施方式中，在生成所述参数模板后，所述方法还包括：

根据生成的所述参数模板，确定每个渠道参数信息对应的参数类型信息；

根据每个所述渠道参数信息及其对应的所述参数类型信息，模拟接入所述渠道服务器的客户端向所述渠道服务器发起登录请求；

确定所述渠道服务器的第一返回信息是否存在异常；

若所述第一返回信息存在异常，则确定所述参数模板配置错误。

该步骤中，在模拟接入渠道服务器的客户端向渠道服务器发起登录请求后，可以确定渠道服务器的第一返回信息是否为正确的登录令牌信息，若是正确的，则可以确定参数模板配置正常，若不正确，则可以确定参数模板配置存在异常。

其中，接入渠道服务器的客户端可以是多渠道管理客户端，也可以是测试用的专有客户端。

这里，确定渠道服务器的第一返回信息是否为正确的登录令牌信息的方式可以是根据第一返回信息的格式，确定返回的信息是否为登录令牌信息，或确定第一返回信息是否与预先储存的返回信息一致。

在一些可能的实施方式中，在确定所述渠道服务器的第一返回信息是否异常之后，所述方法还包括：

若所述第一返回信息不存在异常，则根据所述第一返回信息、所述渠道参数信息及所述参数模板，向所述渠道服务器发起登录验证请求；

确定所述渠道服务器的第二返回信息是否异常；

若所述第二返回信息存在异常，则确定所述参数模板配置错误。

其中，第二返回信息可以是渠道服务器返回的用户信息，若用户信息为正确的用户信息，则可以确定参数模板配置正常无误。

该步骤中，在生成参数模板之后，多渠道管理服务器可以对生成的参数模板进行检测，利用生成的参数模板测试访问渠道服务器，并根据渠道服务器的返回信息判断参数模板是否出现配置错误。

s205、渠道服务器响应多渠道管理服务器的请求，将所述多渠道管理服务器请求的与目标服务请求对应的返回信息发送至所述多渠道管理服务器。

该步骤中，渠道服务器在接收到目标指令信息后，可以根据目标指令信息中的目标服务请求，返回与目标服务请求对应的返回信息，比如，若目标服务请求为登录请求，可以返回登录请求对应的用户信息，若目标服务请求为支付请求，可以返回支付请求对应的渠道订单信息。

s206、多渠道管理服务器基于所述返回信息向所述多渠道管理客户端反馈目标服务响应信息。

该步骤中，在多渠道管理服务器接收到返回信息后，可以根据返回信息，生成目标服务响应信息，并将目标服务响应信息发送至多渠道管理客户端。

其中，目标服务响应信息是根据返回信息确定的，不同的返回信息所生成的目标服务响应信息不同。

s207、多渠道管理客户端接收所述多渠道管理服务器反馈的目标服务响应信息，并根据所述目标服务响应信息响应所述目标服务请求。

该步骤中，多渠道管理客户端在接收到目标服务响应信息后，可以根据目标服务响应信息的内容，与应用客户端、多渠道管理服务器、渠道服务器中至少一端进行进一步的通信和数据处理，响应目标服务请求，对应用进行目标服务。

请参阅图3，图3为本申请另一实施例提供的请求处理方法的流程图。如图3中所示，当目标服务请求为登录请求时，本申请实施例提供的请求处理方法，包括：

步骤1、该步骤中，应用客户端(游戏客户端)响应登录服务触发操作，向多渠道管理客户端(gsdk客户端)发送登录服务请求，所述登录服务请求携带有所述应用客户端对应的渠道类型。

步骤2、多渠道管理客户端根据所述目标服务请求指示的渠道类型，调用所述渠道类型对应的渠道服务器的登录接口，获取包含登录令牌信息和渠道类型信息的所述目标指令信息。

其中，登录令牌信息可以是验证码、临时密码等令牌信息，可以设置为当前数分钟内有效。

步骤3、多渠道管理客户端将目标指令信息发送至多渠道管理服务器(gsdk服务器)；多渠道管理服务器根据目标指令信息中携带的渠道类型、预先获取的渠道参数信息，以及基于参数模板为每个所述渠道参数信息自动适配的参数类型，将目标指令信息发送至渠道服务器；渠道服务器对目标指令信息中的登录令牌信息进行验证，验证接收到的登录令牌信息是否为步骤2中返回给多渠道管理客户端的登录令牌信息，以及登录令牌信息是否在有效时限内，并在验证通过后将登录请求对应的用户信息返回至多渠道管理服务器；多渠道管理服务器在接收到用户信息后，生成带有用于登录的临时票据(access＿token)的登录服务响应信息，并将其发送至多渠道管理客户端；多渠道管理客户端将登录服务响应信息发送至应用客户端。

其中，用户信息可以包括用户的身份标志、昵称、头像等信息。

步骤4、应用客户端将接收到的登录服务响应信息发送至与应用客户端对应的应用服务器(游戏服务器)；游戏服务器在接收到登录服务响应信息后，根据登录响应信息指示的渠道类型，生成与渠道类型对应的签名信息，并向多渠道管理服务器发送登录验证信息；登录验证信息中包含签名信息和临时票据；多渠道管理服务器在接收到登录验证信息后，对登录验证信息进行验证，验证临时票据是否为之前分配的临时票据，并基于预先分配给应用的密钥校验签名信息是否正确，在验证通过后，将用户信息发送给应用服务器；应用服务器在接收到用户信息后，根据用户信息完成应用客户端发起的登录流程。

具体的，应用服务器可以将临时票据、多渠道管理服务器分配给应用服务器的唯一标识、请求时间等信息进行键值对的排序，再加上分配给应用的密钥进行一种hash算法生成签名，再将签名信息通过http请求发送给多渠道管理服务器，多渠道管理服务器再利用密钥进行校验签名信息是否正确。

在应用服务器接收到用户信息后，可以确定用户信息对应的角色信息，并返回角色信息给应用客户端，使应用客户端完成登录，在登录后，用户可以进行角色创建或直接进入游戏世界的操作。

其中，登录验证信息除了包括临时票据以外，还可以包括应用客户端的身份标识、用户身份标识、请求时间等信息，在进行验证时可以同时对上述信息进行验证，可以为临时票据设置一个有效时间，超出预设的有效时间则临时票据失效，无法通过验证。

请参阅图4，图4为本申请另一实施例提供的请求处理方法的流程图。如图4中所示，当目标服务请求为支付请求时，本申请实施例提供的请求处理方法，包括：

步骤1、应用客户端(游戏客户端)响应支付服务触发操作，向多渠道管理客户端(gsdk客户端)发送支付服务请求，所述支付服务请求携带有所述应用客户端对应的渠道类型。

步骤2、多渠道管理客户端将携带有支付服务请求的支付信息发送给多渠道管理服务器(gsdk服务器)；多渠道管理服务器在接收到支付信息后，根据所述支付信息所指示的渠道类型、预先获取的渠道参数类型，以及基于参数模板为每个所述渠道参数信息自动适配的参数类型，向与渠道类型对应的渠道服务器请求获取与支付信息对应的渠道订单信息；渠道服务器响应多渠道管理服务器的请求，根据支付信息，生成渠道订单信息，并将其发送至多渠道管理服务器；渠道订单信息中包含有与所述渠道类型关联的订单信息；多渠道管理服务器根据渠道服务器返回的渠道订单信息，生成用于支付的中转订单信息，并发送中转订单信息至多渠道管理客户端，中转订单信息包括所述渠道订单信息，以及多渠道管理订单信息，多渠道管理订单信息中包含有与所述多渠道管理服务器关联的订单信息。

其中，渠道订单信息中可以包括渠道服务器设置的第一商品标识和/或第一订单标识，以及商品名、购买数量、订单创建时间、商品价格等；中转订单信息可以包括多渠道管理服务器设置的第二商品标识和/或第二订单标识，以及商品名、购买数量、订单创建时间、商品价格等。

步骤3、多渠道管理客户端在接收到中转订单信息后，根据中转订单信息中的多渠道管理订单信息，调用渠道服务器的支付接口，再根据渠道订单信息进行支付，并获取渠道服务器返回的支付结果；多渠道管理客户端在接收到支付结果后，将支付结果发送至应用客户端。

其中，支付结果可以包括渠道订单信息、支付是否成功、渠道服务器的身份标识等信息。

步骤4、渠道服务器在完成支付后，将支付结果发送至多渠道管理服务器，多渠道管理服务器根据支付结果携带的渠道服务器的身份标识对支付结果进行验证，验证通过后将支付结果发送至应用服务器(游戏服务器)；应用服务器接收到支付结果后，对支付结果进行验证，在验证通过后将支付结果中指示的虚拟物品发放至应用客户端。

该步骤中，多渠道管理服务器可以通过渠道服务器预先提供给应用的密钥和渠道服务器的订单签名方式，对支付结果进行验证。

本申请实施例提供的请求处理方法，多渠道管理服务器首先接收多渠道管理客户端在应用客户端触发目标服务请求后，发送的目标指令信息；然后，根据所述目标指令信息所指示的渠道类型、预先获取的渠道参数信息，以及基于参数模板为每个所述渠道参数信息自动适配的参数类型，向与所述渠道类型对应的渠道服务器请求获取返回信息；最后，基于所述返回信息向所述多渠道管理客户端反馈目标服务响应信息，以便所述多渠道管理客户端根据所述目标服务响应信息响应所述目标服务请求。本申请通过设置多渠道管理服务器和多渠道管理客户端，将应用需要接入的多个渠道进行统一管理，可以灵活使用不同渠道的服务能力，方便了开发上的管理和维护；此外，多渠道管理服务器引入了参数模板来自动适配参数类型，减少了应用开发人员针对不同渠道进行参数类型配置的开发难度。

请参阅图5，图5为本申请实施例提供的一种请求处理装置。如图5所示，所述请求处理装置500，用于多渠道管理服务器，所述多渠道管理服务器用于结合多渠道管理客户端，为应用提供针对多种渠道类型的服务能力管理服务；所述请求处理装置500包括：

接收模块510，用于接收多渠道管理客户端在应用客户端触发目标服务请求后，发送的目标指令信息；

请求模块520，用于根据所述目标指令信息所指示的渠道类型、预先获取的渠道参数信息，以及基于参数模板为每个所述渠道参数信息自动适配的参数类型，向与所述渠道类型对应的渠道服务器请求获取返回信息；

反馈模块530，用于基于所述返回信息向所述多渠道管理客户端反馈目标服务响应信息，以便所述多渠道管理客户端根据所述目标服务响应信息响应所述目标服务请求。

在一些可能的实施方式中，在所述目标服务请求为登录请求的情况下：所述接收模块510具体用于：

接收多渠道管理客户端在应用客户端触发登录请求后，发送的包含登录令牌信息和渠道类型信息的所述目标指令信息，所述登录令牌信息为所述多渠道管理客户端向所述渠道服务器发起登录请求后，获取的所述渠道服务器的返回值；

所述请求模块520在向与所述渠道类型对应的渠道服务器请求获取与所述目标服务请求对应的返回信息时，具体用于：

向与所述渠道类型对应的渠道服务器发送携带有所述登录令牌信息的登录验证请求，以便所述渠道服务器在验证所述登录令牌信息后返回用户信息；

所述反馈模块530在向所述多渠道管理客户端反馈目标服务响应信息时，具体用于：

向所述多渠道管理客户端反馈所述多渠道管理服务器提供的用于登录的临时票据。

在一些可能的实施方式中，所述请求处理装置500还包括第一验证模块540，所述第一验证模块540用于在基于所述返回信息向所述多渠道管理客户端反馈目标服务响应信息之后：

接收应用服务器发送的登录验证信息，并对所述登录验证信息进行验证；

在验证通过后，将所述用户信息发送给所述应用服务器。

在一些可能的实施方式中，所述登录验证信息中包括所述临时票据和签名信息；

所述第一验证模块540在对所述登录验证信息进行验证时，具体用于：

验证所述临时票据是否为之前分配的临时票据，并基于预先分配给所述应用的密钥校验所述签名信息是否正确。

在一些可能的实施方式中，在所述目标服务请求为支付请求的情况下：

所述接收模块510在接收多渠道管理客户端在应用客户端触发目标服务请求后，发送的目标指令信息时，具体用于：

接收多渠道管理客户端在应用客户端触发支付请求后，发送的支付信息；

所述请求模块520在向与所述渠道类型对应的渠道服务器请求获取与所述目标服务请求对应的返回信息时，具体用于：

向与所述渠道类型对应的渠道服务器请求与所述支付信息对应的渠道订单信息；所述渠道订单信息中包含有与所述渠道类型关联的订单信息；

所述反馈模块530在向所述多渠道管理客户端反馈目标服务响应信息时，具体用于：

根据所述渠道订单信息，生成用于支付的中转订单信息；所述中转订单信息包括所述渠道订单信息，以及多渠道管理订单信息，所述多渠道管理订单信息中包含有与所述多渠道管理服务器关联的订单信息；

向所述多渠道管理客户端反馈所述中转订单信息，以便所述多渠道管理客户端基于所述中转订单信息向所述渠道服务器发起支付流程。

在一些可能的实施方式中，请求处理装置500还包括第二验证模块550，所述第二验证模块550用于在基于所述返回信息向所述多渠道管理客户端反馈目标服务响应信息之后：

接收所述渠道服务器发送的支付结果，并对所述支付结果进行验证；

在验证通过后，将所述支付结果发送至所述应用服务器，以便所述应用服务器对所述支付结果进行验证。

在一些可能的实施方式中，所述请求模块520在基于参数模板为每个所述渠道参数信息自动适配参数类型时，具体用于：

根据预先设置的属性类型，确定与所述渠道类型对应的每个所述渠道参数信息的属性信息；

根据每个所述渠道参数信息对应的所述属性信息，以及所述参数模板，确定每个所述渠道参数信息的参数类型信息。

在一些可能的实施方式中，所述请求处理装置500还包括参数模板生成模块560，所述参数模板生成模块560用于：

获取参考应用的应用客户端访问所述渠道服务器时使用的至少一个初始渠道参数信息及每个初始渠道参数信息对应的参数类型信息；

根据预先设置的属性类型，确定每个初始渠道参数信息的属性信息；

根据每个初始渠道参数信息的参数类型信息和属性信息，生成所述参数模板。

在一些可能的实施方式中，所述请求处理装置500还包括参数模板测试模块570，所述参数模板测试模块570用于：

根据生成的所述参数模板，确定每个渠道参数信息对应的参数类型信息；

根据每个所述渠道参数信息及其对应的所述参数类型信息，模拟接入所述渠道服务器的客户端向所述渠道服务器发起登录请求；

确定所述渠道服务器的第一返回信息是否异常；

若所述第一返回信息存在异常，则确定所述参数模板配置错误。

在一些可能的实施方式中，所述参数模板测试模块570还用于：

若所述第一返回信息不存在异常，则根据所述第一返回信息、所述渠道参数信息及所述参数模板，向所述渠道服务器发起登录验证请求；

确定所述渠道服务器的第二返回信息是否异常；

若所述第二返回信息存在异常，则确定所述参数模板配置错误。

请参阅图6，图6为本申请实施例提供的另一种请求处理装置。如图6所示，所述请求处理装置600，用于多渠道管理客户端，所述多渠道管理客户端用于结合多渠道管理服务器，为应用提供针对多种渠道类型的服务能力管理服务；包括：

确定模块610，用于接收应用客户端发送的目标服务请求，确定所述目标服务请求对应的目标指令信息；

发送模块620，用于将所述目标指令信息发送至所述多渠道管理服务器，所述目标指令信息用于所述多渠道管理服务器根据所述目标指令信息中所指示的渠道类型、预先获取的渠道参数信息，以及基于参数模板为每个所述渠道参数信息自动适配的参数类型，向与所述渠道类型对应的渠道服务器请求获取返回信息；

响应模块630，用于接收所述多渠道管理服务器基于所述返回信息反馈的目标服务响应信息，并根据所述目标服务响应信息响应所述目标服务请求。

在一些可能的实施方式中，在所述目标服务请求为登录请求的情况下：

所述返回信息为所述渠道服务器在验证所述多渠道管理服务器发送的登录验证请求中携带的登录验证信息后，返回给所述多渠道管理服务器的用户信息；

所述确定模块610在确定所述目标服务请求对应的目标指令信息时，具体用于：

根据所述目标服务请求指示的渠道类型，调用所述渠道类型对应的渠道服务器的登录接口，获取包含登录令牌信息和渠道类型信息的所述目标指令信息；

所述响应模块630在接收所述多渠道管理服务器反馈的目标服务响应信息时，具体用于：

接收所述多渠道管理服务器反馈的所述多渠道管理服务器提供的用于登录的临时票据。

在一些可能的实施方式中，所述响应模块630在根据所述目标服务响应信息响应所述目标服务请求时，具体用于：

将所述临时票据发送至所述应用客户端，以便所述应用客户端将所述临时票据发送至所述应用客户端对应的应用服务器。

在一些可能的实施方式中，在所述目标服务请求为支付请求的情况下：

所述返回信息中包括所述渠道服务器提供的与所述支付信息对应的渠道订单信息；

所述确定模块610在确定所述目标服务请求对应的目标指令信息时，具体用于：

确定所述支付请求携带的支付信息；

所述响应模块630在接收所述多渠道管理服务器反馈的目标服务响应信息时，具体用于：

接收所述多渠道管理服务器反馈的、根据所述渠道订单信息生成的用于支付的中转订单信息；所述中转订单信息包括所述渠道订单信息，以及多渠道管理订单信息，所述多渠道管理订单信息中包含有与所述多渠道管理服务器关联的订单信息。

在一些可能的实施方式中，所述响应模块630在根据所述目标服务响应信息响应所述目标服务请求时，具体用于：

根据所述中转订单信息中的所述多渠道管理订单信息，调用所述渠道服务器的支付接口，根据所述中转订单信息中的渠道订单信息向所述渠道服务器发起支付流程，并获取所述渠道服务器返回的支付结果；

将所述支付结果发送至所述应用客户端。

请参阅图7，图7为本申请实施例所提供的一种电子设备的结构示意图。如图7中所示，所述电子设备700包括处理器710、存储器720和总线730。

所述存储器720存储有所述处理器710可执行的机器可读指令，当电子设备700运行时，所述处理器710与所述存储器720之间通过总线730通信，所述机器可读指令被所述处理器710执行时，可以执行如上述图2、图3以及图4所示方法实施例中的请求处理方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时可以执行如上述图2、图3以及图4所示方法实施例中的请求处理方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

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

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。