数据访问方法、系统和网关服务设备

技术领域

本公开属于互联网技术领域，具体涉及一种数据访问方法、系统和网关服务设备。

背景技术

目前，单个前端服务在实际应用过程中需要依赖各种不同的代理服务，前端服务通常利用HTTP协议传输数据，以访问代理服务。在复杂化的互联网应用服务中，前端服务不可避免的涉及到对多种不同代理服务的调用，而前端服务访问代理服务时需要重新包装修改处理对应的访问请求，以及代理服务向前端服务反馈响应数据时，同样需要重新包装修改处理这些响应，通常这些处理都是重复的工作量堆积。

发明内容

本公开旨在至少解决现有技术中存在的技术问题之一，提供一种数据访问方法、系统和网关服务设备。

第一方面，解决本公开技术问题所采用的技术方案是一种数据访问方法，其中，包括：

响应于接收到各个用户分别发起的、针对代理服务端的第一访问请求，对各个所述第一访问请求进行统一的网关鉴权，并针对任意一个验证通过的第一访问请求，创建所述第一访问请求对应的目标代理服务端的第二访问请求；

基于各个所述第二访问请求，分别获取与所述第二访问请求对应的服务访问凭证；所述服务访问凭证为预先存储的所述目标代理服务端的访问凭证；

基于所述第二访问请求和与之对应的所述服务访问凭证，访问所述目标代理服务端。

在一些实施例中，所述对各个所述第一访问请求进行统一的网关鉴权，包括：

按照所述第一访问请求中指示用户的相关信息，获取预先存储的、已经授权给用户的用户授权凭证；

对所述第一访问请求进行解析，得到所述第一访问请求所携带的用户凭证；

将所述用户授权凭证与所述用户凭证进行匹配，且在所述用户授权凭证与所述用户凭证一致的情况下，确定所述第一访问请求的网关鉴权验证通过。

在一些实施例中，所述创建所述第一访问请求对应的目标代理服务端的第二访问请求，包括：

对所述第一访问请求进行解析，确定所述第一访问请求的请求类型，并判断所述第一访问请求是否具有第一请求头信息；

基于所述请求类型，确定所述第一访问请求的第一复制策略；

基于对所述第一访问请求是否具有第一请求头信息的判断结果，确定所述第一访问请求的第二复制策略；

按照所述第一复制策略、所述第二复制策略和预先制定的第三复制策略，对所述第一访问请求进行处理，得到所述第二访问请求。

在一些实施例中，所述基于对所述第一访问请求是否具有第一请求头信息的判断结果，确定所述第一访问请求的第二复制策略，包括：

在所述第一访问请求携带有所述第一请求头信息的情况下，验证所述第一请求头信息中是否存在不支持的处理格式，在所述第一请求头信息中不存在不支持的处理格式的情况下，确定所述第二复制策略为指示复制所述第一请求头信息作为第二请求头信息的策略；

在所述第一访问请求未携带有所述第一请求头信息的情况下，确定所述第二复制策略为指示调用预先制定的请求头作为所述第二请求头信息的策略。

在一些实施例中，所述验证所述第一请求头信息中是否存在不支持的处理格式，还包括：

在所述第一请求头信息中存在不支持的处理格式的情况下，确定所述第二复制策略为指示调整所述第一请求头信息中不支持的处理格式为可支持处理格式，并复制调整后的所述第一请求头信息作为第二请求头信息的策略。

在一些实施例中，所述按照所述第一复制策略、所述第二复制策略和预先制定的第三复制策略，对所述第一访问请求进行处理，得到所述第二访问请求，包括：

按照所述第一复制策略的指示，对所述第一访问请求中所述请求类型对应的查询参数进行处理，得到处理后的查询参数；

按照所述第二复制策略的指示，基于所述第一请求头信息，确定第二请求头信息；

按照所述第三复制策略的指示，将所述第一访问请求中的网络地址前缀替换为所述目标代理服务端的实际网络地址前缀；

基于所述处理后的查询参数、所述第二请求头信息和所述实际网络地址前缀，生成第二访问请求。

在一些实施例中，所述基于所述第二访问请求和与之对应的所述服务访问凭证，访问所述目标代理服务端，包括：

基于所述第二访问请求，确定所述目标代理服务端的凭证传递方式；

基于所述凭证传递方式和所述服务访问凭证，生成第三访问请求；

基于所述第三访问请求，访问所述目标代理服务端。

在一些实施例中，所述基于所述凭证传递方式和所述服务访问凭证，生成第三访问请求，包括：

在所述目标代理服务端的凭证传递方式为查询参数传递、且所述第二访问请求中存在查询参数的情况下，将所述服务访问凭证添加至所述所述第二访问请求中的查询参数中，生成第三访问请求。

在一些实施例中，所述基于所述凭证传递方式和所述服务访问凭证，生成第三访问请求，包括：

在所述目标代理服务端的凭证传递方式为查询参数传递、且所述第二访问请求中不存在查询参数的情况下，在所述第二访问请求中插入预设拼接符，并添加所述服务访问凭证，生成第三访问请求。

在一些实施例中，所述基于所述凭证传递方式和所述服务访问凭证，生成第三访问请求，包括：

在所述目标代理服务端的凭证传递方式为请求头传递的情况下，将所述服务访问凭证添加至所述所述第二请求头信息中，生成第三访问请求。

在一些实施例中，所述基于所述第三访问请求，访问所述目标代理服务端，包括：

响应于接收到所述目标代理服务端基于所述第三访问请求所反馈的访问结果，对所述访问结果进行解析，确定所述用户所请求的实际访问数据、响应头信息和协议状态码；

基于所述用户所请求的实际访问数据、响应头信息和协议状态码，生成响应结果，并将所述响应结果反馈给所述用户。

在一些实施例中，存储所述目标代理服务端的服务访问凭证的步骤包括：

接收所述目标代理服务端发送的服务访问凭证，并存储；

所述服务访问凭证为所述目标代理服务端在所述用户登录时基于所述用户标识生成的键值对；或者，所述服务访问凭证为所述目标代理服务端基于自身身份信息生成的唯一授权凭证。

第二方面，本公开实施例还提供了一种网关服务设备，被配置为获取不同用户分别发起的、针对代理服务端的第一访问请求；对各个所述第一访问请求进行统一的网关鉴权，并针对任意一个验证通过的第一访问请求，创建所述第一访问请求对应的目标代理服务端的第二访问请求；基于各个所述第二访问请求，分别获取与所述第二访问请求对应的服务访问凭证；所述服务访问凭证为预先存储的所述目标代理服务端的访问凭证；基于所述第二访问请求和与之对应的所述服务访问凭证，访问所述目标代理服务端。

第三方面，本公开实施例还提供了一种数据访问系统，包括多个前端服务端，网关服务设备和多个代理服务端；

所述前端服务端，被配置为向所述网关服务端发起针对代理服务端的第一访问请求；

所述网关服务设备，被配置为响应于接收到各个用户分别发起的、针对代理服务端的第一访问请求，对各个所述第一访问请求进行统一的网关鉴权，并针对任意一个验证通过的第一访问请求，创建所述第一访问请求对应的目标代理服务端的第二访问请求；基于各个所述第二访问请求，分别获取与所述第二访问请求对应的服务访问凭证；所述服务访问凭证为预先存储的所述目标代理服务端的访问凭证；基于所述第二访问请求和与之对应的所述服务访问凭证，访问所述目标代理服务端。

第四方面，本公开实施例还提供了一种计算机非瞬态可读存储介质，该计算机非瞬态可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如第一方面中任一项所述的数据访问方法的步骤。

附图说明

图1为本公开实施例提供的一种数据访问方法的流程图；

图2为本公开实施例提供的数据访问方法的流程示意图；

图3为本公开实施例提供的一种数据访问系统的示意图；

图4为本公开实施例提供的数据访问系统的访问流程示意图。

具体实施方式

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

除非另外定义，本公开使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。同样，“一个”、“一”或者“该”等类似词语也不表示数量限制，而是表示存在至少一个。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。

在本公开中提及的“多个或者若干个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

在对本公开具体内容进行说明之前，对本公开涉及到的特殊名词做具体性说明。

1、Spring框架，是一个从实际开发中抽取出来的框架，其完成了大量开发中的通用步骤。Spring框架包括轻量级核心框架和灵活的MVC Web应用框架。基于该Spring框架可以实现大部分Java的实际应用开发。

2、Spring Boot是一种全新Java框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该Spring Boot框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。Spring Boot框架提供了构建Web应用程序的全功能MVC模块。MVC作为WEB项目开发的核心环节，正如三个单词的分解那样，C(控制器)将V(视图、用户客户端)与M(javaBean:封装数据)分开构成了MVC。Spring MVC分离了控制器、模型对象、过滤器以及处理程序对象的角色，这种分离让它们更容易进行定制。

3、JSON Web Token(JWT)是一种跨域身份验证解决方案，具体通过客户端保存数据，而服务器根本不保存会话数据，每个请求都被发送回服务器。JWT的原则是在服务器身份验证之后，将生成一个JSON对象并将其发送回用户。之后，当用户与服务器通信时，客户在请求中发回JSON对象。服务器仅依赖于这个JSON对象来标识用户。为了防止用户篡改数据，服务器将在生成对象时添加签名。JWT的数据结构包括JWT头、有效载荷和签名的一个长字串。其中，JWT头部分是一个描述JWT元数据的JSON对象；有效载荷部分，是JWT的主体内容部分，也是一个JSON对象，包含需要传递的数据。签名哈希部分是对上面两部分数据签名，通过指定的算法生成哈希，以确保数据不会被篡改。

4、Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。Token的目的是为了减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。

5、URL，Uniform Resource Locator，统一资源定位系统，是因特网的万维网服务程序上用于指定信息位置的表示方法。通常用于表示请求访问网页的地址。

6、HTTP，HyperText Transfer Protocol，超文本传输协议，是一个简单的请求-响应协议。

7、W3C，World Wide Web Consortium，万维网联盟，是Web技术领域的一种技术标准机构，支撑互联网技术的应用。

8、GET、POST、PUT、DELETE、HEAD、PATCH和OPTIONS为HTTP协议的请求类型。

9、在WEB开发中，query和params是两个经常用到的概念，是用来传递数据的方式，但是有一些不同之处。params是URL的一部分，通常用于传递资源的标识符或者唯一标识符。例如，一个博客网站的文章详情页面的URL可能是/blog/posts/123，其中的123就是params，表示这个页面展示的是博客文章的ID为123的那篇。query则是URL中的另一部分，用于传递一些查询信息，比如搜索关键词、排序方式、分页等等。在URL中，query通常以？开头，然后是一些键值对，用&符号连接。例如，一个博客网站的文章列表页面的URL可能是：/blog/posts？sort＝created_at&order＝desc&page＝2，其中的sort、order、page就是query的信息，表示按照创建时间降序排列，显示第二页的文章列表。

10、from表单是一个包含表单元素的区域，用于向服务器传输数据，从而实现用户与WEB服务器的交互。其中，表单元素是允许用户在表单中输入内容，比如：文本域(textarea)、下拉列表(select)等等。可以使用标签来创建表单。

11、body是用在网页中的一种HTML标签，表示网页的主体部分，也就是用户可以看到的内容，可以包含文本、图片、音频和视频等各种内容。

12、CONTENT_TYPE内容类型，一般是指网页中存在的Content-Type，用于定义网络文件的类型和网页的编码，决定文件接收方将以什么形式、什么编码读取这个文件。

13、AUTHORIZATION是HTTP请求头(也即HTTP HEADER)的一部分，用于指示用户代理的认证凭据(通常是用户名和密码)以访问受密码保护的资源。这个请求头通常用于验证API访问授权，或登陆过程中的身份验证。

14、ORIGIN指的是请求发起者的源地址。

15、ACCEPT_ENCODING是浏览器发给服务器，声明浏览器支持的编码类型。

第一方面，本公开提供了一种数据访问方法，其执行主体可以是网关服务设备。网关服务设备是一种应用于数据访问系统中用于提供网关服务的设备。网关可以理解为一种协议转换器，网关在网络层以上实现网络互联。通常情况下，网关对接收到的信息需要重新打包，以适用目标代理服务的需求。

对于一个数据访问系统，其主体架构通常包括多个前端服务端，网关服务设备和多个代理服务端。

本公开提供一种数据访问方法，基于开发的特定网关系统(也即本公开中网关服务设备所支撑的网关系统)，统一不同代理服务端的调用策略，主要体现在对各种不同前端服务端发送的第一访问请求进行统一的网关鉴权、透明的请求转发，可以适配不同的代理服务。

图1为本公开实施例提供的一种数据访问方法的流程图，如图1所示，该数据访问方法包括步骤S11～S13。

S11、响应于接收到各个用户分别发起的、针对代理服务端的第一访问请求，对各个第一访问请求进行统一的网关鉴权，并针对任意一个验证通过的第一访问请求，创建第一访问请求对应的目标代理服务端的第二访问请求。

本步骤中，针对代理服务端的第一访问请求其实质是表征前端服务端请求访问代理服务端的原始请求，然而，该第一访问请求并非直接接入代理服务端，而是需要借助网关实现数据传输，因此，第一访问请求被网关服务设备所接收。

本公开的网关服务设备集成有基于Spring Boot内相关MVC框架，开发出的能够执行统一网关鉴权逻辑的轻量级网关系统。该网关系统为各个不同的前端服务端提供统一的域名。

示例性的，网关系统与前端服务端之间可以采用W3C标准的HTTP作为交互协议。

网关服务设备中预先存储有对应前端服务端唯一的用户授权凭证，便于访问用户授权服务。响应于不同用户分别发起的第一访问请求，利用用户授权凭证对第一访问请求进行统一网关鉴权，判断网关鉴权验证是否通过。

示例性的，统一网关鉴权可以采用JWT验证方式进行验证。其中，Token内存储前端服务端唯一的用户授权凭证，例如，用户中心标识、用户角色标识和用户类型等一系列信息。

对于验证通过的第一访问请求进行透明复制，以创建出适配目标代理服务端的第二访问请求。其中“透明”主要体现在经过网关服务设备的复制，不会影响实际对目标代理服务端的访问和后续目标代理服务端反馈的响应。

本步骤中的代理服务端并非是特指某一个代理服务端，而是对后端代理服务的泛指。目标代理服务端是对第一访问请求所要请求访问的某一个代理服务端的特指。

S12、基于各个第二访问请求，分别获取与第二访问请求对应的服务访问凭证。

其中，服务访问凭证为预先存储的目标代理服务端的访问凭证。

本公开的网关服务设备集成有基于Spring Boot内相关MVC框架，开发出的能够执行统一代理服务鉴权逻辑的轻量级网关系统。

该网关服务设备中预先存储有各个代理服务端的访问凭证。针对一个第二访问请求，具体地，首先对第二访问请求进行解析，确定第二访问请求中指示的所要访问目标代理服务端的信息；之后，根据第二访问请求的指示，获取目标代理服务端的访问凭证。

需要说明的是，不同的代理服务端拥有各自不同的代理服务鉴权的方式，网关系统采用统一的策略模式，也即预存各个代理服务端唯一对应的访问凭证，为各个第二访问请求分别授权，以适配不同的代理服务端。

S13、基于第二访问请求和与之对应的服务访问凭证，访问目标代理服务端。

对第二访问请求和与之对应的服务访问凭证进行处理，例如在第二访问请求的基础上附加服务访问凭证，生成第三访问请求，将第三访问请求发送至目标代理服务端，以请求访问目标代理服务端。

本公开将网关系统(也即网关服务设备)作为不同代理服务端的统一入口，通过服务访问凭证，将不同第三访问请求路由到不同的代理服务端。

本公开基于Spring Boot内相关MVC框架，开发出能够执行统一网关鉴权逻辑和统一代理服务鉴权逻辑的轻量级网关系统，对于新接入的第三方代理服务端，只需要在网关系统侧进行统一网关鉴权逻辑和统一代理服务鉴权逻辑的配置，既可实现第三方代理服务的接入，实现不同代理服务端的统一融合，避免对第三方代理服务的重复开发。

在一些实施例中，针对步骤S11中对各个第一访问请求进行统一的网关鉴权的过程，具体包括下述步骤S11-1-1～S11-1-3。

S11-1-1、按照第一访问请求中指示用户的相关信息，获取预先存储的、已经授权给用户的用户授权凭证。

需要说明的是，第一访问请求是用户发起的请求，因此第一访问请求中携带有能够表示用户身份的相关信息，或者是表示用户所属的前端服务端的相关信息。

具体地，对第一访问请求进行解析，确定第一访问请求中指示用户的相关信息，并按照指示用户的相关信息获取该用户的用户授权凭证。

S11-1-2、对第一访问请求进行解析，得到第一访问请求所携带的用户凭证。

第一访问请求中携带发起用户的用户凭证。对第一访问请求进行解析，可以获取到发起用户的用户凭证。

S11-1-3、将用户授权凭证与用户凭证进行匹配，且在用户授权凭证与用户凭证一致的情况下，确定第一访问请求的网关鉴权验证通过。

将用户授权凭证与用户凭证进行匹配，以判断当前用户是否为已经授权过的可访问代理服务的用户。在用户授权凭证与用户凭证一致的情况下，确定该用户已被授权，从而确定第一访问请求的在网关鉴权阶段验证通过。

本实施例基于开发完成的轻量化网关系统，实现对各种不同前端服务端发送的第一访问请求进行统一的网关鉴权。

在一些实施例中，针对步骤S11中创建第一访问请求对应的目标代理服务端的第二访问请求的过程，具体包括下述步骤S11-2-1～S11-2-5。

S11-2-1、对第一访问请求进行解析，确定第一访问请求的请求类型，同步执行步骤S11-2-2和S11-2-3。

示例性的，前端服务端与网关服务设备之间通过HTTP协议进行数据传输。此时，第一访问请求也即HTTP协议对应的访问请求。HTTP协议会预先定义一些不同请求类型的访问请求，用于前端服务端与代理服务端之间的数据交互。其中，请求类型包括但不仅限于GET、POST、PUT、DELETE、HEAD、PATCH和OPTIONS等。

S11-2-2、判断第一访问请求是否具有第一请求头信息，跳转执行S11-2-4。

本步骤中第一请求头信息例如为HTTP协议的HTTP HEADER的信息。

前端服务端与网关服务设备之间通过HTTP协议传输第一访问请求，该第一访问请求可能存在HTTP HEADER，也可能不存在；基于此，网关服务设备判断第一访问请求是否具有HTTP HEADER。存在HTTP HEADER和不存在HTTP HEADER的两种判断结果，所确定出的S11-2-4中的第二复制策略不同。

S11-2-3、基于请求类型，确定第一访问请求的第一复制策略。

不同请求类型，对应不同的第一复制策略。

示例性的，在第一访问请求的请求类型为GET或DELETE的情况下，第一复制策略为指示复制第一访问请求中的query和params的策略。

示例性的，在第一访问请求的请求类型为PUT或POST方式的情况下，第一复制策略为指示复制第一访问请求中的query和params，以及处理from表单和body等的策略。

S11-2-4、基于对第一访问请求是否具有第一请求头信息的判断结果，确定第一访问请求的第二复制策略。

若存在HTTP HEADER，则确定第二复制策略为指示复制HTTP HEADER的策略。若不存在HTTP HEADER，则确定第二复制策略为指示复制预先制定的请求头的策略。

S11-2-5、按照第一复制策略、第二复制策略和预先制定的第三复制策略，对第一访问请求进行处理，得到第二访问请求。

具体包括如下步骤S11-2-51～S11-2-54：S11-2-51、按照第一复制策略的指示，对所述第一访问请求中所述请求类型对应的查询参数进行处理，得到处理后的查询参数。

例如，当第一复制策略为指示复制第一访问请求中的query和params的策略的情况下，复制第一访问请求中的query和params。query和params为第一访问请求中所述请求类型对应的查询参数。

例如，当第一复制策略为指示复制第一访问请求中的query和params，以及处理from表单和body等的策略的情况下，复制第一访问请求中的query和params，并对第一访问请求中的from表单和body进行处理，得到复制后的query和params和处理后的from表单和body。其中，query、params、from表单和body为第一访问请求中所述请求类型对应的查询参数。

不同方式的数据复制都涉及数据编码的问题，此处为了适配所用可用系统，本公开可以统一采用UTF8编码方式。当然编码方式不仅限于这一种，还可以选用其他编码方式进行数据复制。

S11-2-52、按照第二复制策略的指示，基于第一请求头信息，确定第二请求头信息。

例如，当第二复制策略为指示复制HTTP HEADER的策略的情况下，复制第一请求头信息作为第二请求头信息。

例如，当第二复制策略为指示复制预先制定的请求头的策略的情况下，复制预先制定的请求头作为第二请求头信息。

本公开对第一请求头信息的复制是为了实际访问目标代理服务端时，避免由于缺失自定义的请求头导致访问出错。

S11-2-53、按照第三复制策略的指示，将第一访问请求中的网络地址前缀替换为目标代理服务端的实际网络地址前缀。

本步骤中的网络地址也即URL。按照第三复制策略的指示，将URL的访问前缀配置为目标代理服务端的实际URL的访问前缀。

S11-2-54、基于处理后的查询参数、第二请求头信息和实际网络地址前缀，生成第二访问请求。

本公开上述步骤S11-2-51～S11-2-54通过对第一访问请求进行透明复制，以创建出适配目标代理服务端的第二访问请求。

按照上述步骤S11-2-51～S11-2-53的复制策略对第一访问请求进行处理，利用处理后的查询参数、第二请求头信息和实际网络地址前缀，共同构成第二访问请求。

在一些实施例中，针对步骤S11-2-4的判断结果，具体包括：在所述第一访问请求未携带有所述第一请求头信息的情况下，确定所述第二复制策略为指示调用预先制定的请求头作为所述第二请求头信息的策略。在所述第一访问请求携带有所述第一请求头信息的情况下，验证第一请求头信息中是否存在不支持的处理格式，在第一请求头信息中不存在不支持的处理格式的情况下，确定所述第二复制策略为指示复制所述第一请求头信息作为第二请求头信息的策略。

示例性的，若不存在HTTP HEADER，则确定第二复制策略为指示复制预先制定的请求头的策略。若存在HTTP HEADER，则需要先验证一下第一请求头信息中是否存在不支持的处理格式。需要说明的是，第一访问请求的所有HEADER信息均会传递给实际访问的目标代理服务端系统，包括但不限于CONTENT_TYPE、AUTHORIZATION、ORIGIN、ACCEPT_ENCODING等信息。其中，ACCEPT_ENCODING为ZIP压缩格式，网关服务设备对压缩类型的访问请求不提供默认支持，因此需要针对性处理。ORIGIN和ACCEPT_ENCODING的格式，网关服务设备提供有默认支持的处理方式，无需针对性处理。也就是说，在所述第一请求头信息中不存在不支持的处理格式的情况下，确定所述第二复制策略为指示复制所述第一请求头信息作为第二请求头信息的策略；在所述第一请求头信息中存在不支持的处理格式的情况下，确定所述第二复制策略为指示调整所述第一请求头信息中不支持的处理格式为可支持处理格式，并复制调整后的所述第一请求头信息作为第二请求头信息的策略。例如，将ACCEPT_ENCODING的ZIP压缩格式调整为非压缩模式进行后续处理。

对于可能存在的CONTENT_TYPE缺失导致的访问出错的情况，通过判断缺失类型自动为其赋值APPLICATION_JSON_VALUE。

在一些实施例中，针对上述步骤S13，具体包括以下步骤S131～S133。

S131、基于第二访问请求，确定目标代理服务端的凭证传递方式。

不同的代理服务端对应不同的凭证传递方式，该凭证传递方式是预先为代理服务端配置的。对第二访问请求进行解析，可以确定第二访问请求中指示的所要访问目标代理服务端的信息，根据第二访问请求中指示的所要访问目标代理服务端的信息，可以确定该目标代理服务端的凭证传递方式。

示例性的，代理服务端的凭证传递方式包括查询参数传递和请求头传递。其中，查询参数传递也即采用query和/或params的传递方式。请求头传递也即采用HTTP HEADER的传递方式。

S132、基于凭证传递方式和服务访问凭证，生成第三访问请求。

具体地，在目标代理服务端的凭证传递方式为查询参数传递的情况下，判断第二访问请求中是否存在查询参数；若存在，则将服务访问凭证添加至所述所述第二访问请求中的查询参数中，生成第三访问请求。示例性的，将服务访问凭证添加至query和/或params中，生成新的访问请求，也即第三访问请求。

若第二访问请求中不存在查询参数，则在第二访问请求中插入预设拼接符，并添加服务访问凭证，生成第三访问请求。

在目标代理服务端的凭证传递方式为请求头传递的情况下，将服务访问凭证添加至所述所述第二请求头信息中，生成第三访问请求。示例性的，将服务访问凭证添加至HTTPHEADER中，例如，可以是插入HTTP HEADER中的AUTHORIZATION中。

S133、基于第三访问请求，访问目标代理服务端。

具体的，网关服务设备将第三访问请求发送至目标代理服务端；目标代理服务端响应于第三访问请求，反馈访问结果。例如，用户请求访问目标代理服务端提供的相关资讯服务，访问结果包含相关资讯服务的实际内容。

针对上述各个步骤S11～S13及其细化步骤，下面以一个示例进行整体性说明。

示例性的，图2为本公开实施例提供的数据访问方法的流程示意图，如图2所示，网关服务设备响应于各个用户分别发起的第一访问请求，并进行统一的网关鉴权；之后，对第一访问请求进行透明复制，生成第二访问请求；之后，按照不同的凭证传递方式进行服务鉴权，生成第三访问请求；按照第三访问请求访问代理服务。

在一些实施例中，访问目标代理服务端的具体过程包括：响应于接收到目标代理服务端基于第三访问请求所反馈的访问结果，先对访问结果进行解析，确定用户所请求的实际访问数据、响应头信息和协议状态码。之后，基于用户所请求的实际访问数据、响应头信息和协议状态码，生成响应结果，并将响应结果反馈给所述用户。

其中，访问结果至少包括实际访问数据、响应头信息和协议状态码。访问结果为用户请求访问目标代理服务端，目标代理服务端根据第三访问请求的指示实际反馈的结果。响应头信息主要用于前端服务端顺利解析访问结果。协议状态码是前端服务端处理响应的重要依据。

基于用户所请求的实际访问数据、响应头信息和协议状态码，生成响应结果。具体地，复制实际访问数据、复制响应头信息、以及复制协议状态码生成响应结果。

本公开对响应的请求头(也即响应头信息)进行复制，主要是处理响应的内容格式，及跨域相关设置，避免由于缺失特定的响应头，导致前端服务端响应解析失败，且可能影响下一次调用时授权信息的传递。

在一些实施例中，针对步骤S12，预先存储目标代理服务端的服务访问凭证的步骤包括：接收目标代理服务端发送的服务访问凭证，并存储，便于下次访问时使用。

示例性的，网关服务设备存储服务访问凭证的方式可以是缓存存储。

其中，所述服务访问凭证为所述目标代理服务端在所述用户登录时基于所述用户标识生成的键值对；或者，所述服务访问凭证为所述目标代理服务端基于自身身份信息生成的唯一授权凭证。

不同的目标代理服务端适配不同的服务访问凭证，不同服务访问凭证对应不同的服务鉴权方式，例如，用户名密码的方式和用户登录存储的方式。

对于用户登录存储的方式，目标代理服务端在用户登录时，基于用户标识，例如前端服务端的身份信息，生成键值对KEY-VALUE，其中，KEY表示用户标识(例如用户中心ID)，VALUE表示服务访问凭证。

在使用阶段，基于各个所述第二访问请求中的用户中心ID，调用与用户中心ID对应的VALUE(也即服务访问凭证)。

对于用户名密码的方式，目标代理服务端基于自身的身份信息，例如目标代理服务端的用户名和密码，生成自身唯一的授权凭证(也即服务访问凭证)，并在接入网关服务设备时，将服务访问凭证上传至网关服务设备。

以上是对本公开提供的数据访问方法的全部说明。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

另外，本公开实施例中还提供了与数据访问方法对应的网关服务设备，由于本公开实施例中的网关服务设备解决问题的原理与本公开实施例上述数据访问方法相似，因此网关服务设备的实施可以参见方法的实施，重复之处不再赘述。

网关服务设备被配置为获取不同用户分别发起的、针对代理服务端的第一访问请求；对各个所述第一访问请求进行统一的网关鉴权，并针对任意一个验证通过的第一访问请求，创建所述第一访问请求对应的目标代理服务端的第二访问请求；基于各个所述第二访问请求，分别获取与所述第二访问请求对应的服务访问凭证；所述服务访问凭证为预先存储的所述目标代理服务端的访问凭证；基于所述第二访问请求和与之对应的所述服务访问凭证，访问所述目标代理服务端。

本公开实施例提供的网关服务设备基于开发的特定网关系统(也即本公开中网关服务设备所支撑的网关系统)，统一不同代理服务端的调用策略，主要体现在对各种不同前端服务端发送的第一访问请求进行统一的网关鉴权、透明的请求转发，可以适配不同的代理服务。同时，将网关服务设备作为不同代理服务端的统一入口，网关服务设备负责将不同请求路由到不同的代理服务端，实现了服务的解耦和聚合。

在一些实施例中，在实际应用阶段，当有新的第三方系统(也即新的代理服务端)需要接入时，配置内容具体包括：需要配置访问第三方系统的目标网络地址和网络地址前缀。例如，实际访问第三方系统的网络地址为https://api.order-service.com/order/list，定义访问该第三方系统的前缀为order-service；新生成的对外访问的目标网络地址为https://api.gateway.com/order-service/order/list。

另外，还需要实现代理服务端的服务访问凭证的获取；还需要配置代理服务端的凭证传递方式，例如可以具体是查询参数传递或请求头传递，从而实现第三方系统的接入。

以上配置只需在第三方系统接入时一次性配置，后续直接按照对外提供的服务直接访问便可实现请求的处理验证转发。

另外，本公开实施例还提供了提供一种数据访问系统，图3为本公开实施例提供的一种数据访问系统的示意图，如图3所示，数据访问系统包括多个前端服务端，例如前端服务端1、前端服务端2和前端服务端3；网关服务设备和多个代理服务端，例如代理服务端A、代理服务端B和代理服务端C；其中任意前端服务端，被配置为向所述网关服务端发起针对代理服务端的第一访问请求。

所述网关服务设备，被配置为响应于接收到各个用户分别发起的、针对代理服务端的第一访问请求，对各个所述第一访问请求进行统一的网关鉴权，并针对任意一个验证通过的第一访问请求，创建所述第一访问请求对应的目标代理服务端的第二访问请求；基于各个所述第二访问请求，分别获取与所述第二访问请求对应的服务访问凭证；所述服务访问凭证为预先存储的所述目标代理服务端的访问凭证；基于所述第二访问请求和与之对应的所述服务访问凭证，访问所述目标代理服务端。

不同的前端服务端可以访问数据访问系统中的任意代理服务端。

在一些实施例中，目标代理服务端，被配置为响应于第三访问请求，反馈访问结果。网关服务设备，具体被配置为响应于接收到目标代理服务端基于第三访问请求所反馈的访问结果，先对访问结果进行解析，确定用户所请求的实际访问数据、响应头信息和协议状态码。之后，基于用户所请求的实际访问数据、响应头信息和协议状态码，生成响应结果，并将响应结果反馈给所述前端服务端。

本公开实施例提供的数据访问系统，基于开发的特定网关系统(也即本公开中网关服务设备所支撑的网关系统)，统一不同代理服务端的调用策略，将网关服务设备作为不同代理服务端的统一入口，将不同请求路由到不同的代理服务，实现服务的解耦和聚合。同时，在请求路由过程中，网关服务设备对各种不同前端服务端发送的第一访问请求进行统一的网关鉴权和透明的请求转发。

图4为本公开实施例提供的数据访问系统的访问流程示意图，如图4所示，前端服务端被配置为向所述网关服务端发起针对代理服务端的第一访问请求；网关服务设备被配置为响应于各个用户分别发起的第一访问请求，并进行统一的网关鉴权；之后，对第一访问请求进行透明复制，生成第二访问请求；之后，按照不同的凭证传递方式进行服务鉴权，生成第三访问请求，并发送至目标代理服务端。目标代理服务端被配置为响应于第三访问请求，反馈访问结果。网关服务设备还被配置为响应于接收到目标代理服务反馈的访问结果，先对访问结果进行解析，确定用户所请求的实际访问数据、响应头信息和协议状态码。之后，基于用户所请求的实际访问数据、响应头信息和协议状态码，生成响应结果，并将响应结果反馈给所述前端服务端。

另外，本公开实施例还提供了一种计算机非瞬态可读存储介质。该计算机非瞬态可读存储介质上存储有计算机程序，其中，该程序被处理器执行时实现如上述实施例中任一的数据访问方法中的步骤。

特别地，根据本公开实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在机器可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分从网络上被下载和安装，和/或从可拆卸介质被安装。在该计算机程序被中央处理单元(Central Processing Unit，CPU)执行时，执行本公开的系统中限定的上述功能。

需要说明的是，本公开所示的计算机非瞬态可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(Random Access Memory,RAM)、只读存储器(Read-Only Memory，ROM)、可擦式可编程只读存储器(Erasable Programmable Read-OnlyMemory，EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-OnlyMemory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机非瞬态可读存储介质，该计算机非瞬态可读存储介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机非瞬态可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本公开各种实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个相连的方框实际上可以表示基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

可以理解的是，以上实施方式仅仅是为了说明本公开的原理而采用的示例性实施方式，然而本公开并不局限于此。对于本领域内的普通技术人员而言，在不脱离本公开的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本公开的保护范围。