CN110213331B - 业务请求的处理方法、终端设备、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种业务请求的处理方法、终端设备、电子设备及存储介质，属于移动通信领域，方法包括：从中间服务器中获取服务策略信息；在检测到第一业务请求的情况下，根据服务策略信息判断第一业务请求对应的服务是否已变更；第一业务请求对应的服务已变更时，从服务策略信息获取第一业务请求对应的目标服务策略以及请求参数；根据目标服务策略对第一业务请求进行验证；在第一业务请求验证通过的情况下，根据请求参数生成第二业务请求，并向后台服务器发送第二业务请求。本发明实施例在摆脱应用软件中服务更新对后台服务器的依赖关系和降低版本更新成本的同时，还避免了版本差异和已废弃或禁止请求导致后台服务器处理压力过大。

Description

业务请求的处理方法、终端设备、电子设备及存储介质

技术领域

本发明属于计算机技术领域，特别是涉及一种业务请求的处理方法、终端设备、电子设备及存储介质。

背景技术

近年来，随着移动互联网的迅猛发展，用户使用移动客户端的时间和频率也在日益增长，因此移动客户端的稳定性、安全性和效率成为了各大移动客户端运营商和广大用户们关心的问题。

现有技术中，应用软件在发布之后，主要的业务逻辑已经确定，且所有的逻辑处理都需要后台服务器的支持。移动客户端在获取数据时，通过基于网络协议的接口发送请求到后台服务器。

在这种现有模式下，如果想要变更应用软件中服务所对应接口的任何参数，需要变更客户端的现有业务逻辑，并重新部署发布该应用软件的新版本，这种方式由于应用软件与后台服务器的强依赖关系，应用软件客户端发送请求的变更必须依赖于后台服务器，导致更新程序繁琐而且成本较高。再者由于用户未能及时更新应用软件，就会出现大量用户同时使用不同版本的应用软件，造成后台服务器需要界定所接受业务请求的应用软件版本以提供不同的服务，导致后台服务器负载过大，或者旧版本的应用软件会继续发送已废弃或禁用的请求，不但导致后台服务器产生不必要的流量，而且会导致用户在不知情的情况下无法正常使用应用软件的已变更服务。

发明内容

有鉴于此，本发明提供一种业务请求的处理方法、终端设备、电子设备及存储介质，以便解决移动客户端的服务更新过度依赖于后台服务器，导致移动客户端更新成本过高，版本差异和更新之后导致移动客户端稳定性低和已废弃或禁用请求导致服务器处理压力大的问题。

依据本发明的第一方面，提供了一种业务请求的处理方法，应用于终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述方法包括：

从所述中间服务器中获取服务策略信息；

在检测到第一业务请求的情况下，根据所述服务策略信息判断所述第一业务请求对应的服务是否已变更；

当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数；

根据所述目标服务策略对所述第一业务请求进行验证；

在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。

可选的，所述根据所述目标服务策略对所述第一业务请求进行验证的步骤之后，还包括：

当所述第一业务请求验证未通过时，拦截所述第一业务请求并显示错误提示信息。

可选的，所述第一业务请求包括目标服务标识；所述当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数，包括：

当所述第一业务请求对应的服务已变更时，根据所述第一业务请求的目标服务标识，从所述服务策略信息中获取相对应的请求参数；

根据所述请求参数，从所述服务策略信息获取中相对应的目标服务策略。

可选的，所述从所述中间服务器中获取服务策略信息的步骤，包括：

在检测到所述终端设备内的应用软件启动时，控制部署在所述终端设备内的代理节点从所述中间服务器获取所述服务策略信息。

可选的，所述服务策略信息是所述中间服务器根据服务变更配置对服务初始策略信息进行更新得到的，所述服务变更配置是所述后台服务器发送的。

可选的，所述服务初始策略信息是所述后台服务器根据服务初始配置生成的，并发送至所述中间服务器以存储。

可选的，所述请求参数包括：接口配置、超时配置、缓存配置、重传配置中的至少一项。

可选的，所述目标服务策略包括：格式规则、版本规则、禁用规则中的至少一项。

依据本发明的第二方面，提供了一种终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，其特征在于，所述终端设备包括：

获取模块，用于从所述中间服务器中获取服务策略信息；

判断模块，用于在检测到第一业务请求的情况下，根据所述服务策略信息判断所述第一业务请求对应的服务是否已变更；

查询模块，用于当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数

验证模块，用于根据所述目标服务策略对所述第一业务请求进行验证；

发送模块，用于在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。

可选的，所述终端设备，还包括：

报错模块，当所述第一业务请求验证未通过时，拦截所述第一业务请求并显示错误提示信息。

可选的，所述第一业务请求包括目标服务标识，所述查询模块，包括：

第一查询子模块，用于当所述第一业务请求对应的服务已变更时，根据所述第一业务请求的目标服务标识，从所述服务策略信息中获取相对应的请求参数；

第二查询子模块，用于根据所述请求参数，从所述服务策略信息获取中相对应的目标服务策略。

可选的，所述获取模块，还用于在检测到所述终端设备内的应用软件启动时，控制部署在所述终端设备内的代理节点从所述中间服务器获取服务策略信息。

可选的，所述服务策略信息是所述中间服务器根据服务变更配置对服务初始策略信息进行更新得到的，所述服务变更配置是所述后台服务器发送的。

可选的，所述服务初始策略信息是所述后台服务器根据服务初始配置生成的，并发送至所述中间服务器以存储。

可选的，所述请求参数包括：接口配置、超时配置、缓存配置、重传配置中的至少一项。

可选的，所述目标服务策略包括：格式规则、版本规则、禁用规则中的至少一项。

依据本发明第三方面，提供一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一方面任一所述的业务请求的处理方法。

依据本发明第四方面，提供一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现上述第一方面任一所述的业务请求的处理方法。

针对现有技术，本发明具备如下优点：

本发明提供了一种业务请求的处理方法、终端设备、电子设备及存储介质，所述方法应用于终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述方法包括：从所述中间服务器中获取服务策略信息；在检测到第一业务请求的情况下，根据所述服务策略信息判断所述第一业务请求对应的服务是否已变更；当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数；根据所述目标服务策略对所述第一业务请求进行验证；在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。通过在终端设备和后台服务器之间设置中间服务器对终端设备提供服务策略信息以变更业务请求，摆脱了应用软件与后台服务器之间在服务变更时的强依赖关系，并且通过终端设备根据服务策略信息对应用软件的业务请求在发送前进行验证拦截和重新配置，在避免了已被废弃或禁用的请求给后台服务造成压力过大的问题的同时，实现了无需重新发布新版应用软件也可灵活变更服务请求配置的效果。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1是本发明实施例提供的一种业务请求的处理方法的步骤流程图；

图2是本发明实施例提供的另一种业务请求的处理方法的步骤流程图；

图3是本发明实施例提供的再一种业务请求的处理方法的步骤流程图；

图4是本发明实施例提供的一种终端设备的结构框图；

图5是本发明实施例提供的另一种终端设备的结构框图；

图6是本发明实施例提供的再一种终端设备的结构框图；

图7是本发明实施例提供的传统业务请求的处理时，数据传输过程的示意图；

图8是本发明实施例提供的另一种业务请求的处理时，数据传输过程的示意图；

图9是本发明实施例提供的中间服务器与后台服务器间的数据传输过程示意图。

具体实施方式

下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。

图1是本发明实施例提供的一种业务请求的处理方法的步骤流程图，所述方法应用于终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述方法包括：

步骤110，从所述中间服务器中获取服务策略信息。

在本发明实施例中，所述终端设备可以是日常使用的各种移动终端设备，如手机、平板电脑等。所述中间服务器可以是具有一定存储能力和数据处理能力的前置机，如CDN(Content Delivery Network，内容分发网络)或者Nginx(engine x一款轻量级的Web服务器/反向代理服务器及电子邮件代理服务器)等其他动态内容系统。操作人员在每次发布应用服务时，通过在所述中间服务器进行注册，注册登记所述应用服务的标识及参数等信息。完成注册后所述中间服务器就可以接收并存储相对应的服务策略信息。所述服务策略信息可以包括服务标识与请求参数之间的对应关系，请求参数与接口地址之间的对应关系，以及配置参数。

步骤120，在检测到第一业务请求的情况下，根据所述服务策略信息判断所述第一业务请求对应的服务是否已变更。

在本发明实施例中，所述终端设备提取所述第一业务信息中的目标服务标识，根据所述目标服务标识在所述服务策略信息中查询所述第一业务请求对应的服务是否存在对应的目标服务策略及请求参数，以判断所述服务是否已变更。若所述服务策略信息中存在于所述第一业务请求相对应的目标服务策略及请求参数时，确认所述第一业务请求对应的服务已变更；若所述服务策略信息中不存在所述第一业务请求相对应的目标服务策略信息及请求参数时，确认所述第一业务请求对应的服务未变更。

所述终端设备在未检测到第一业务请求的情况下，保持检测第一业务请求的运行状态。

步骤130，当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数。

在本发明实施例中，所述第一业务请求是用户通过终端设备操作应用软件发送的请求，所述第一业务请求可以包括目标服务标识。所述目标服务策略是从所述中间服务器获取的所述服务策略信息中与第一业务请求相对应的服务策略。所述请求参数是与所述业务请求相对应的接口配置参数。在实际应用中，为了应用服务器的接口地址和内容不会直接暴露在外部，通过引入服务标识的方式，获取所述业务请求中的所述目标服务标识在所述服务策略信息中进行搜索，即可获取相对应的目标服务策略及请求参数。通过这种方式，无需将准确的服务内容及参数直接暴露在外部，也可实现业务数据的获取。

在所述第一业务请求对应的服务未变更时，所述终端设备向所述第一业务请求对应的后台服务器转发所述第一业务请求，可以理解，当所述第一业务请求对应的服务未变更时，终端设备是将所述第一业务请求进行放行，并不会对所述第一业务请求进行变更。

步骤140，根据所述目标服务策略对所述第一业务请求进行验证。

在本发明实施例中，所述目标服务策略是操作人员预先配置得到的，根据不同的目标服务策略对所述第一业务请求进行验证，所述验证例如终端设备中的应用软件版本是否过低或请求指令格式是否合法等，具体验证项目可根据不同需要通过配置目标服务策略进行调整。对于验证不通过的第一业务请求可在客户端层面进行拦截，以减少后台服务器接收到的无效数据流量，和验证业务请求所需的服务器资源。

步骤150，在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。

在本发明实施例中，对于验证通过的第一业务请求，根据所述第一业务请求相对应的请求参数，生成相应的第二业务请求，再将所述第二业务请求发送至后台服务器以获取目标服务，所述请求参数可以包括接口地址、请求格式、超时配置、缓存时间配置、接口参数校验、失败重试配置等业务请求所需的参数。所述请求参数可以根据实际需要通过对服务策略信息进行配置，以实现灵活修改，从而适应终端设备中应用软件的更新和维护需求。

本发明提供了一种业务请求的处理方法，所述方法应用于终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述方法包括：应用于终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述方法包括：从所述中间服务器中获取服务策略信息；在检测到第一业务请求的情况下，根据所述服务策略信息判断所述第一业务请求对应的服务是否已变更；当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数；根据所述目标服务策略对所述第一业务请求进行验证；在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。本发明实施例通过通过在终端设备和后台服务器之间设置中间服务器对终端设备提供服务策略信息以变更业务请求，摆脱了应用软件与后台服务器之间在服务变更时的强依赖关系，并且通过终端设备根据服务策略信息对应用软件的业务请求在发送前进行验证拦截和重新配置，在避免了已被废弃或禁用的请求给后台服务造成压力过大的问题的同时，实现了无需重新发布新版应用软件也可灵活变更服务请求配置。

图2是本发明实施例提供的另一种业务请求的处理方法的步骤流程图，所述方法应用于如图8所示的终端设备810，所述终端设备810通过代理节点820分别与后台服务器840、中间服务器830通信连接，所述后台服务器840与所述中间服务器830通信连接，包括：

步骤210，在检测到所述终端设备内的应用软件启动时，部署在所述终端设备内的代理节点向所述中间服务器发送服务策略获取请求。

参照图7示出的传统技术中，终端设备710的应用软件在需要请求获取服务信息时，是直接向后台服务器720送业务请求的，这种方式不仅不能保障业务数据的获取，而且已变更或已废弃的业务请求会给后台服务器带来冗余的数据处理负担。并且在这种模式下，若应用软件的版本或者服务发生变更时，需要发布新版本的应用软件，程序复杂且成本高昂，限制了应用软件的更新和服务变更需求。

在本发明实施例中，所述服务策略获取请求包含有应用软件的目标服务标识。所述检测操作可以是针对预先指定的一个或多个应用软件。所述代理节点可以是安装在所述终端设备内的应用或者前置部署于所述终端设备应用中的插件，可以在所述终端设备内设置一个代理节点与所述中间服务器通信连接。所述代理节点用于所述终端设备的服务获取与验证判断。每当用户启动应用时，主动向所述中间服务器获取最新的服务策略信息，已保证所述终端设备可以获取最新的服务。

所述终端设备在检测到指定应用软件启动时，通过部署于其内部的代理节点向所述中间服务器发送服务策略获取请求，所述服务策略获取请求携带有所述应用程序的目标服务标识。所述代理节点与所述中间服务器之间是一一对应的，这种对应关系是所述代理节点部署到终端设备中时确定的。所述部署步骤可以是用户通过终端设备单独对代理节点程序进行安装，也可以是携带于应用程序中，在终端设备安装应用应用程序时部署所述代理节点。在实际应用中，所述代理节点处理的对象可以是针对单个应用程序中的业务请求，也可以针对多个应用程序中的业务请求。

步骤220，从所述中间服务器中获取服务策略信息。

在本发明实施例中，所述终端设备接收所述中间服务器根据所述应用软件的目标服务标识返回的服务策略信息。操作人员将首次发布的服务在所述中间服务器上完成注册后，可以实时通过后台服务器对服务策略信息进行上传更新，通过修改服务策略信息中的请求地址、参数映射等内容，实现了对业务请求的无感知热切换。

可选的，所述服务策略信息是所述中间服务器根据服务变更配置对服务初始策略信息进行更新得到的，所述服务变更配置是所述后台服务器发送的。所述服务初始策略信息是所述后台服务器根据服务初始配置生成的，并发送至所述中间服务器以存储。

在本发明实施例中，操作人员可以将服务发布至后台服务器，后台服务器根据发布的服务生成相应的服务初始配置，以及对应的服务初始策略信息，并将请求参数和服务初始策略信息发送至中间服务器，当该服务未发生变更时，终端设备可以从中间服务器上获取服务初始策略信息。当该服务发生变更时，所述后台服务器向所述中间服务器发送服务变更配置之后，中间服务器根据服务变更配置对服务初始策略进行变更后得到服务策略信息，终端设备可以从中间服务器获取最新的服务策略信息。本领域技术人员可以，当该服务再次发生变更时，操作人员可再次根据服务变更内容向中间服务器发送服务变更配置，以使得中间服务器对本地存储的服务策略信息进行更新。

步骤230，在检测到第一业务请求的情况下，根据所述服务策略信息判断所述第一业务请求对应的服务是否已变更。

此步骤与实施例二中的步骤120相同，在此不再详述。

步骤240，当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数。

在本发明实施例中，当检测到终端设备接收到的第一业务请求时，提取所述第一业务请求中的目标服务标识，在所述服务策略信息中查询项对应的目标服务策略和请求参数，所述第一业务请求可以包括但不限于目标服务标识、终端设备参数、应用软件参数，所述终端设备参数可以包括但不限于终端设备的系统版本、硬件配置等，所述应用软件参数可以包括但不限于应用软件的版本、运行状态等。所述目标服务策略包括目标服务请求的配置验证条件，以确定所述第一业务请求是否符合所述目标服务策略。

在未检测到第一业务请求的情况下，代表不存在业务请求，从而不进行任何处理。

步骤250，根据所述目标服务策略对所述第一业务请求进行验证。

在本发明实施例中，根据所述目标服务策略对所述第一业务请求进行验证，其中，所述目标服务策略可以包括格式规则、版本规则、禁用规则中的至少一项。当所述第一业务请求所对应的目标应用服务器存在目标服务规则时，所述终端设备可以通过格式规则判断所述第一业务请求的格式是否符合格式规则，不符合格式规则的第一业务请求确认验证不通过。通过版本规则判断目标应用软件的版本是否已无效，不符合版本规则的第一业务请求确认为验证未通过。通过禁用规则判断第一业务请求所对应的服务是否已被禁用，当所述第一业务请求所对应的目标服务标识存在于所述禁用规则时，确认所述第一业务请求未通过。本领域技术人员可以理解，所述目标服务策略可以包含上述三种规则中的一个或多个，验证过程中若有任一配置规则不通过，则确认所述第一业务请求验证不通过。

通过对所述第一业务请求进行验证，使得不符合目标服务策略的的第一业务请求可以在客户端被报错并拦截，不会发送至后台服务器，减轻的后台服务器的数据处理压力的同时，避免了非法请求给后台服务器带来的安全风险。

可选的，所述目标服务策略包括：格式规则、版本规则、禁用规则的至少一项。

在本发明实施例中，所述版本规则可以包括无效版本的应用软件的标识，所述应用软件因为版本过低或存在漏洞等原因已被废弃，后台服务器已不再提供该版本应用软件的服务时，可在所述版本规则添加该版本的应用软件标识，通过判断所述版本配置中是否存在第一业务请求中的应用软件的版本标识，判断所述第一业务请求是否验证通过，当所述版本规则中存在所述第一业务请求对应的应用软件版本标识时，确认所述第一业务请求验证不通过，若不存在，确认所述第一业务请求验证通过。

所述格式规则可以包括业务请求的合法格式，将所述第一业务请求的格式与所述格式规则进行比对，当所述第一业务请求的格式不符合所述格式规则时，确认所述第一业务请求验证不通过，当所述第一业务请求的格式符合所述格式规则时，确认所述第一业务请求验证通过。所述格式规则以包括：预设编码包含内容、预设编码长度、预设编码协议等。

所述禁用规则可以包括被禁用服务标识列表，判断所述禁用服务标识列表中是否包含所述目标服务器标识，当所述第一业务请求所携带的目标服务标识存在于所述禁用服务标识列表中时，确认所述第一业务请求验证未通过，当所述目标服务标识不存在于所述禁用服务标识列表时，确认所述第一业务请求验证通过。

步骤260，在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。

在本发明实施例中，当所述第一业务请求通过验证后，根据相对应的请求参数，生成具有正确接口地址的第二业务请求，并发送至所述后台服务器。所述第二业务请求包含了目标服务标识。

通过在服务策略信息中查询并获取到的所述第一业务请求相对应的请求参数，确定目标服务的正确接口地址，生成并发送所述第二业务请求，实现了对业务服务请求的无感知热切换，使得应用软件的更新和维护更加便捷高效。

步骤270，当所述第一业务请求的验证未通过时，拦截所述第一业务请求并显示错误提示信息。

在本发明实施例中，当所述第一业务请求未能通过所对应的目标服务策略的验证时，终端设备及时向用户发出错误提示信息，避免出现用户因为第一业务请求无效，导致长时间等待却无法获取服务数据的情况发生。所述错误提示信息可以以语音信息提示、文字信息推送或其他类型的提醒方式通过终端设备向用户展示。

本发明提供了另一种业务请求的处理方法，所述方法应用于终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述方法包括：应用于终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述方法包括：从所述中间服务器中获取服务策略信息；在检测到第一业务请求的情况下，根据所述服务策略信息判断所述第一业务请求对应的服务是否已变更；当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数；根据所述目标服务策略对所述第一业务请求进行验证；在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。通过在终端设备和后台服务器之间设置中间服务器对终端设备提供服务策略信息以变更业务请求，以使得终端设备可以在本端对业务请求进行验证拦截和重新配置，不仅避免了已被废弃或禁用的请求给后台服务器造成不必要的处理压力，实现了无需重新发布新版应用软件也可灵活变更服务请求配置的效果。并且可以通过后台服务器对中间服务器中的服务策略信息进行变更的方式，实现了业务请求的无感知热切换，极大的提高了应用软件维护更新的效率。

图3是本发明实施例提供的再一种业务请求的处理方法的步骤流程图，所述方法应用于终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述方法包括：

步骤310，在检测到所述终端设备内的应用软件启动时，部署在所述终端设备内的代理节点向所述中间服务器发送服务策略获取请求。

此步骤与实施例二中的步骤210相同，在此不再详述。

在本发明实施例中，所述服务策略信息可以包括目标服务策略、请求参数。所述目标服务策略用于对终端设备中目标应用软件发送的第一业务请求进行验证，而请求参数用于在所述第一业务请求验证通过的情况下，对所述第一业务请求进行重新配置生成对应变更后的服务接口的第二业务请求。可选的，请求参数包括：接口配置、超时配置、缓存配置、重传配置中的至少一项。

接口配置包括：变更接口地址、接口参数，所述接口配置用于对第一业务请求中的接口参数进行重新配置以生成包含目标服务标识的第二业务请求，从而使得终端设备在可以在目标服务变更后仍可顺利获取目标服务标识对应的服务数据。

所述超时配置用于设置第二业务请求在传输超时的情况下对所述第二业务请求进行的后续操作，可以是删除所述第二业务请求或重新发送等，所述超时配置可以基于后台服务器的请求处理负荷状态进行。

所述缓存配置用于设置第二业务请求的接口级别的缓存，在缓存有效时间内无需发送请求，减少不必要业务请求数据，减轻了后台服务器的数据处理压力。

所述重传配置用于对第二业务请求的重传频率进行设置，或者设置取消重传机制，以适应后台服务器的不同需求。

本发明实施例通过对第一业务请求根据具体的请求参数进行重新配置以生成第一业务请求，简化了服务更新后接口转换的过程，提高了应用软件服务更新的灵活性。

步骤320，从所述中间服务器中获取服务策略信息。

此步骤与实施例二中的步骤220相同，在此不再详述。

步骤330，在检测到第一业务请求的情况下，根据服务策略信息判断所述第一业务请求对应的服务是否已变更。

此步骤与实施例一中的步骤120相同，在此不再详述。

步骤340，当所述第一业务请求对应的服务已变更时，根据所述第一业务请求的目标服务标识，从所述服务策略信息中获取相对应的请求参数。

在本发明实施例中，所述目标服务标识是在目标服务注册时生成的唯一标识符，可通过所述唯一标识符搜索到所述第一业务请求相对应的请求参数。

步骤350，根据所述请求参数，从所述服务策略信息中获取相对应的目标服务策略。

在本发明实施例中，由于所述服务策略信息中包含有请求参数和服务策略之间的映射关系，根据所述请求参数，即可在所述服务策略信息中获取所述目标服务策略。这样可以在不将业务内容和信息暴露在外部的情况下实现业务服务的获取。

步骤360，根据所述目标服务策略对所述第一业务请求进行验证。

此步骤与实施例二中的步骤240相同，在此不再详述。

步骤370，在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。

此步骤与实施例二中的步骤250相同，在此不再详述。

步骤380，当所述第一业务请求的验证未通过时，拦截所述第一业务请求并显示错误提示信息。

在本发明实施例中，当所述第一业务请求验证未通过时，在返回错误提示信息的同时，根据步骤350中所述终端设备根据所述目标服务策略对所述第一业务请求的验证情况，向用户显示具体验证错误情况。所述错误提示信息可以是将验证错误情况转换为文本形式的提示语，例如版本过期、请求格式异常等，以方便用户了解错误原因，可以更加快捷地排除故障。还可以将验证错误情况转换为语音形式的提示信息向用户展示。

可选的，所述服务初始策略信息是所述后台服务器根据服务初始配置生成的，并发送至所述中间服务器以存储。

在本发明实施例中，不同于普通微服务的服务注册需要消耗大量服务器资源做服务同步、服务更新，本实施例只需要一个静态文件既可以完成的服务发现机制，大大降低复杂性。所述后台服务器根据服务初始配置生成静态文件形式的服务初始策略信息，再发送至所述中间服务器存储，中间服务器根据终端设备发送的服务初始策略信息获取请求向终端设备提供所述服务策略信息。

本发明实施例通过在中间服务器向终端设备提供服务初始策略信息以对终端设备的业务请求进行验证拦截和变更，摆脱了终端设备中应用软件与后台服务器之间的强依赖关系的同时，减轻了后台服务器的运行压力，使得服务变更操作是实现更加灵活。

可选的，所述服务策略信息是所述中间服务器根据服务变更配置对服务初始策略信息进行更新得到的，所述服务变更配置是所述后台服务器发送的。

在本发明实施例中，应用软件的操作人员可以在后台服务器修改服务信息，后台服务器根据修改的服务信息生成服务变更信息，发送给中间服务器，以使得中间服务器对本地的服务初始策略信息或服务策略信息进行更新；还可以生成变更后的服务策略信息发送至中间服务器，以替换原服务策略信息。

参照图9所示，在中间服务器1010未接收并存储后台服务器1020发送的服务器策略信息时，后台服务器1020根据服务初始配置生成服务初始策略信息，发送给中间服务器1010，以使得中间服务1010存储服务初始策略信息；在中间服务器1010已接收并存储后台服务器1020发送的服务出策略信息时，后台服务器1020可以通过向中间服务器1010发送服务变更配置，以使得中间服务器1010根据服务变更配置对本地存储的服务初始策略信息或服务策略信息进行更新。

本发明可以在服务发生变更时，主动、及时的更新服务策略信息。

本发明提供了再一种业务请求的处理方法，所述方法应用于终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述方法包括：应用于终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述方法包括：从所述中间服务器中获取服务策略信息；在检测到第一业务请求的情况下，根据所述服务策略信息判断所述第一业务请求对应的服务是否已变更；当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数；根据所述目标服务策略对所述第一业务请求进行验证；在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。通过在终端设备和后台服务器之间设置中间服务器对终端设备提供服务策略信息以变更业务请求，以使得终端设备可以在本端对业务请求进行验证拦截和重新配置，不仅避免了已被废弃或禁用的请求给后台服务器造成不必要的处理压力，实现了无需重新发布新版应用软件也可灵活变更服务请求配置的效果。并且可以通过后台服务器对中间服务器中的服务策略信息进行变更的方式，实现了业务请求的无感知热切换，极大的提高了应用软件维护更新的效率。

图4是本发明实施例提供的一种终端设备40的结构框图，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述终端设备包括：

获取模块410，用于从所述中间服务器中获取服务策略信息。

判断模块420，用于在检测到第一业务请求的情况下，根据服务策略信息判断所述第一业务请求对应的服务是否已变更。

查询模块430，用于当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数。

验证模块440，用于根据所述目标服务策略对所述第一业务请求进行验证。

发送模块450，用于在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。

本发明提供了一种终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述终端设备包括：获取模块，用于从所述中间服务器中获取服务策略信息；判断模块，用于在检测到第一业务请求的情况下，根据服务策略信息判断所述第一业务请求对应的服务是否已变更；查询模块，用于当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数；验证模块，用于根据所述目标服务策略对所述第一业务请求进行验证；发送模块，用于在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。本发明实施例通过中间服务器向终端设备提供服务策略信息，摆脱了应用软件与后台服务器之间在服务变更时的强依赖关系，并且通过终端设备根据服务策略信息对应用软件的业务请求在发送前进行验证拦截和重新配置，在避免了已被废弃或禁用的请求给后台服务造成压力过大的问题的同时，实现了无需重新发布新版应用软件也可灵活变更服务请求配置的效果。

图5是本发明实施例提供的另一种终端设备50的结构框，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述终端设备包括：

获取模块510，用于从所述中间服务器中获取服务策略信息。

所述获取模块510，还用于在检测到所述终端设备内的应用软件启动时，控制部署在所述终端设备内的代理节点从所述中间服务器获取服务策略信息。

判断模块520，用于在检测到第一业务请求的情况下，根据服务策略信息判断所述第一业务请求对应的服务是否已变更。

查询模块530，用于在检测到第一业务请求的情况下，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数。

验证模块540，用于根据所述目标服务策略对所述第一业务请求进行验证。

发送模块550，用于在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求；

报错模块560，当所述第一业务请求的验证未通过时，拦截所述第一业务请求并显示错误提示信息。

本发明提供了一种终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述终端设备包括：获取模块，用于从所述中间服务器中获取服务策略信息。所述获取模块，还用于在检测到所述终端设备内的应用软件启动时，控制部署在所述终端设备内的代理节点从所述中间服务器获取服务策略信息。判断模块，用于在检测到第一业务请求的情况下，根据服务策略信息判断所述第一业务请求对应的服务是否已变更。查询模块，用于在检测到第一业务请求的情况下，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数。验证模块，用于根据所述目标服务策略对所述第一业务请求进行验证。发送模块，用于在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求；报错模块，当所述第一业务请求的验证未通过时，拦截所述第一业务请求并显示错误提示信息。本发明实施例通过在终端设备和后台服务器之间设置中间服务器对终端设备提供服务策略信息以变更业务请求，摆脱了应用软件与后台服务器之间在服务变更时的强依赖关系，并且通过终端设备根据服务策略信息对应用软件的业务请求在发送前进行验证拦截和重新配置，在避免了已被废弃或禁用的请求给后台服务造成压力过大的问题的同时，实现了无需重新发布新版应用软件也可灵活变更服务请求配置的效果。

图6是本发明实施例提供的再一种终端设备60的结构框图，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述终端设备包括：

获取模块610，用于从所述中间服务器中获取服务策略信息。

可选的，所述获取模块610，还用于在检测到所述终端设备内的应用软件启动时，控制部署在所述终端设备内的代理节点从所述中间服务器获取服务策略信息。

判断模块620，用于在检测到第一业务请求的情况下，根据服务策略信息判断所述第一业务请求对应的服务是否已变更。

第一查询子模块630，用于在检测到第一业务请求的情况下，根据所述第一业务请求的目标服务标识，从所述服务策略信息中获取相对应的请求参数。

第二查询子模块640，用于根据所述请求参数，从所述服务策略信息获取中相对应的目标服务策略。

验证模块650，用于根据所述目标服务策略对所述第一业务请求进行验证。

发送模块660，用于在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。

报错模块670，当所述第一业务请求的验证未通过时，拦截所述第一业务请求并显示错误提示信息。

可选的，所述服务策略信息是所述中间服务器根据服务变更配置对服务初始策略信息进行更新得到的，所述服务变更配置是所述后台服务器发送的。

可选的，所述服务初始策略信息是所述后台服务器根据服务初始配置生成的，并发送至所述中间服务器以存储。

本发明提供了一种终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述终端设备包括：获取模块，用于从所述中间服务器中获取服务策略信息，还用于在检测到所述终端设备内的应用软件启动时，控制部署在所述终端设备内的代理节点从所述中间服务器获取服务策略信息。判断模块，用于在检测到第一业务请求的情况下，根据服务策略信息判断所述第一业务请求对应的服务是否已变更。第一查询子模块，用于在检测到第一业务请求的情况下，根据所述第一业务请求的目标服务标识，从所述服务策略信息中获取相对应的请求参数。第二查询子模块，用于根据所述请求参数，从所述服务策略信息获取中相对应的目标服务策略。验证模块，用于根据所述目标服务策略对所述第一业务请求进行验证。发送模块，用于在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。报错模块，当所述第一业务请求的验证未通过时，拦截所述第一业务请求并显示错误提示信息。本发明实施例通过在终端设备和后台服务器之间设置中间服务器对终端设备提供服务策略信息以变更业务请求，摆脱了应用软件与后台服务器之间在服务变更时的强依赖关系，并且通过终端设备根据服务策略信息对应用软件的业务请求在发送前进行验证拦截和重新配置，在避免了已被废弃或禁用的请求给后台服务造成压力过大的问题的同时，实现了无需重新发布新版应用软件也可灵活变更服务请求配置的效果。

对于上述终端设备实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

另外，本发明实施例还提供一种电子设备，包括处理器，存储器，存储在存储器上并可在处理上运行的计算机程序，该计算机程序被处理器执行时实现上述一种业务数据处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述一种业务请求的处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，可以为只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random AccessMemory，简称RAM)、磁碟或者光盘等。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域技术人员易于想到的是：上述各个实施例的任意组合应用都是可行的，故上述各个实施例之间的任意组合都是本发明的实施方案，但是由于篇幅限制，本说明书在此就不一一详述了。

在此提供的一种业务请求的处理方法不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造具有本发明方案的系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本发明并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的一种业务请求的处理方法中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者终端设备程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干终端设备的单元权利要求中，这些终端设备中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (18)

1.一种业务请求的处理方法，其特征在于，应用于终端设备，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述方法包括：

从所述中间服务器中获取服务策略信息；

在检测到第一业务请求的情况下，根据所述服务策略信息判断所述第一业务请求对应的服务是否已变更；所述第一业务请求包括目标服务标识；所述目标服务标识用于从所述服务策略信息中获取所述第一业务请求相对应的请求参数；

当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数；

根据所述目标服务策略对所述第一业务请求进行验证；

在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。

2.根据权利要求1所述的方法，其特征在于，所述根据所述目标服务策略对所述第一业务请求进行验证的步骤之后，还包括：

当所述第一业务请求验证未通过时，拦截所述第一业务请求并显示错误提示信息。

3.根据权利要求2所述的方法，其特征在于，所述当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数，包括：

当所述第一业务请求对应的服务已变更时，根据所述第一业务请求的目标服务标识，从所述服务策略信息中获取相对应的请求参数；

根据所述请求参数，从所述服务策略信息获取中相对应的目标服务策略。

4.根据权利要求3所述的方法，其特征在于，所述从所述中间服务器中获取服务策略信息的步骤，包括：

在检测到所述终端设备内的应用软件启动时，控制部署在所述终端设备内的代理节点从所述中间服务器获取服务策略信息。

5.根据权利要求4所述的方法，其特征在于，所述服务策略信息是所述中间服务器根据服务变更配置对服务初始策略信息进行更新得到的，所述服务变更配置是所述后台服务器发送的。

6.根据权利要求5所述的方法，其特征在于，所述服务初始策略信息是所述后台服务器根据服务初始配置生成的，并发送至所述中间服务器以存储。

7.根据权利要求6所述的方法，其特征在于，所述请求参数包括：接口配置、超时配置、缓存配置、重传配置中的至少一项。

8.根据权利要求1至7其中任一项所述的方法，其特征在于，所述目标服务策略包括：格式规则、版本规则、禁用规则中的至少一项。

9.一种终端设备，其特征在于，所述终端设备分别与后台服务器、中间服务器通信连接，所述后台服务器与所述中间服务器通信连接，所述终端设备包括：

获取模块，用于从所述中间服务器中获取服务策略信息；

判断模块，用于在检测到第一业务请求的情况下，根据所述服务策略信息判断所述第一业务请求对应的服务是否已变更；所述第一业务请求包括目标服务标识；所述目标服务标识用于从所述服务策略信息中获取所述第一业务请求相对应的请求参数；

查询模块，用于当所述第一业务请求对应的服务已变更时，从所述服务策略信息中获取所述第一业务请求对应的目标服务策略以及请求参数；

验证模块，用于根据所述目标服务策略对所述第一业务请求进行验证；

发送模块，用于在所述第一业务请求验证通过的情况下，根据所述请求参数生成第二业务请求，并向所述后台服务器发送所述第二业务请求。

10.根据权利要求9所述的终端设备，其特征在于，所述终端设备，还包括：

报错模块，用于当所述第一业务请求验证未通过时，拦截所述第一业务请求并显示错误提示信息。

11.根据权利要求10所述的终端设备，其特征在于，所述查询模块，包括：

第一查询子模块，当所述第一业务请求对应的服务已变更时，根据所述第一业务请求的目标服务标识，从所述服务策略信息中获取相对应的请求参数；

第二查询子模块，用于根据所述请求参数，从所述服务策略信息获取中相对应的目标服务策略。

12.根据权利要求11所述的终端设备，其特征在于，所述获取模块，还用于

在检测到所述终端设备内的应用软件启动时，控制部署在所述终端设备内的代理节点从所述中间服务器获取服务策略信息。

13.根据权利要求12所述的终端设备，其特征在于，所述服务策略信息是所述中间服务器根据服务变更配置对服务初始策略信息进行更新得到的，所述服务变更配置是所述后台服务器发送的。

14.根据权利要求13所述的终端设备，其特征在于，所述服务初始策略信息是所述后台服务器根据服务初始配置生成的，并发送至所述中间服务器以存储。

15.根据权利要求14所述的终端设备，其特征在于，所述请求参数包括：接口配置、超时配置、缓存配置、重传配置中的至少一项。

16.根据权利要求9至15其中任一项所述的终端设备，其特征在于，所述目标服务策略包括：格式规则、版本规则、禁用规则中的至少一项。

17.一种电子设备，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现权利要求1至8中任一所述的业务请求的处理方法。

18.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现权利要求1至8中任一所述的业务请求的处理方法。

Images