CN110109766A - 数据请求方法、装置、系统、数据转发装置及存储介质 - Google Patents

Abstract

本申请实施例提供了一种数据请求方法、装置、系统、数据转发装置及存储介质。方法包括：获得数据请求端发送的数据获取请求；确定出与数据获取请求对应的目标数据提供端，以及确定出目标数据提供端的数据提供方式；从多个微服务进程中确定出能够按照与数据提供方式对应的方式请求数据的目标微服务进程；通过目标微服务进程向目标数据提供端请求数据。由于针对各数据提供方式都专门建立了微服务进程来以对应的方式请求数据，故在发送前可以先确定出与数据提供方式对应的微服务进程，再通过目标微服务进程以适配的方式去请求数据，就可以避免在请求时出现与数据请求方式不对应的情况，从而避免请求失败的情况发生。

Description

数据请求方法、装置、系统、数据转发装置及存储介质

技术领域

本申请涉及数据传输技术领域，具体而言，涉及一种数据请求方法、装置、系统、数据转发装置及存储介质。

背景技术

在目前的数据跨平台共享技术中，数据提供平台通常有多个，每个数据提供平台又有各自的数据提供方式，且各数据提供平台的数据提供方式相差甚远，例如，A平台提供的视频数据，但是B平台提供的确是文档数据。这就使得向各平台发送的请求难以与各平台的数据提供方式都适配，例如，由于视频数据的提供方式和文档数据的提供方式差异很大，则请求的格式在适配视频数据的提供方式基础上该请求的格式就难以适配文档数据的提供方式，一旦出现不适配的情况就会导致向该数据提供平台请求数据失败。

发明内容

本申请的目的在于提供一种数据请求方法、装置、系统、数据转发装置及存储介质，以避免因请求不适配而导致的数据请求失败的情况。

第一方面，本申请实施例提供了一种数据请求方法，所述方法包括：

获得数据请求端发送的数据获取请求；确定出与所述数据获取请求对应的目标数据提供端，以及确定出所述目标数据提供端的数据提供方式；从多个微服务进程中确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程；通过所述目标微服务进程向所述目标数据提供端请求数据。

在本申请实施例中，由于针对各数据提供方式都专门建立了微服务进程来以对应的方式请求数据，故在请求发送前可以先确定出与数据提供方式对应的微服务进程，再通过确定出的微服务进程以适配的方式去请求数据，就可以避免在请求时出现与数据请求方式不对应的情况，从而避免请求失败的情况发生。

结合第一方面，在第一种可能的实现方式中，从多个微服务进程中确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程，包括：

获取每个所述微服务进程在创建时生成的注册信息，其中，所述注册信息中包含有对应所述微服务进程的数据请求方式；

根据所述注册信息，确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程。

在本申请实施例中，由于在创建微服务进程时就在生成的注册信息中写入了该微服务进程的数据请求方式，故在后续使用时无需再次写入，通过对注册信息进行分析的方式可以便捷并准确的确定出目标微服务进程。

结合第一方面，在第二种可能的实现方式中，通过所述目标微服务进程向所述目标数据提供端请求数据，包括：

判断所述目标微服务进程是否处于可用状态；

若是，通过所述目标微服务进程将所述数据获取请求的格式转换成与所述数据提供方式对应的格式，并向所述目标数据提供端发送格式转换后的所述数据获取请求。

在本申请实施例中，利用目标微服务进程，可以对数据获取请求进行格式转换就生成转换后与数据提供方式对应的数据获取请求，这种方式的计算量小，可以降低设备负荷，并降低对设备的性能要求。

结合第一方面的第二种可能的实现方式，在第三种可能的实现方式中，判断所述目标微服务进程是否处于可用状态，包括：

判断所述目标微服务进程是否发送过续租报文以及在发送所述续租报文之后所述目标微服务进程是否发送过进程注销报文；

其中，所述目标微服务进程发送过所述续租报文且在发送所述续租报文之后所述目标微服务进程未发送过所述进程注销报文表示所述目标微服务进程处于所述可用状态。

在本申请实施例中，通过对是否续租以及是否进程注销进行判断可以准确的确定目标微服务进程是否处于可用状态，避免由于目标微服务进程不可用而导致数据请求失败。

结合第一方面的第二种可能的实现方式，在第四种可能的实现方式中，

每个所述微服务进程中封装的数据请求引擎为API引擎、自动索引引擎、DB引擎或流数据引擎。

在本申请实施例中，基于封装的引擎，微服务进程则可以以API、自动索引、DB或流数据方式去请求数据，这极大的丰富了微服务进程请求数据的方式，使得方案针对各种数据提供方式都可以适应。

结合第一方面的第二种可能的实现方式，在第五种可能的实现方式中，

在通过所述目标微服务进程向所述目标数据提供端请求数据之后，所述方法还包括：

获取所述目标数据提供端基于响应格式转换后的所述数据获取请求而返回的所需数据；

生成所述所需数据的数据结构的注释信息；

将所述所需数据和所述注释信息发送给所述数据请求端。

在本申请实施例中，通过对数据结构进行注释，使得数据请求端基于注释就可以知晓数据结构的含义，使得数据请求端可以有更好的使用体验。

结合第一方面，在第六种可能的实现方式中，所述方法还包括：

周期性判断在当前周期内获取的所有请求的响应率是否达到响应率阈值；

若是，继续获取新的请求并处理，否则，在当前时刻起之后的预设时长内停止获取新的请求。

在本申请实施例中，在确定响应率过低时，可以暂停获取新的数据获取请求，从而避免继续获取新的数据获取请求却无法响应而导致系统崩溃。

结合第一方面或第一方面的第一种至第六种中的任一种可能的实现方式，在第七种可能的实现方式中，在获得数据请求端发送的数据获取请求之前，所述方法还包括：

周期性判断在当前周期内获取的所有请求的响应率是否达到响应率阈值；

若是，继续获取新的请求并处理，否则，在当前时刻起之后的预设时长内停止获取新的请求；

将所述目标数据目录发送到所述数据请求端，使得所述数据请求端基于所述目标数据目录生成所述数据获取请求。

在本申请实施例中，由于可以获取并将目标数据提供端的目标数据目录发送给数据请求端，这样就便于数据请求端基于目标数据目录而获取自己需要请求什么样的数据，从而发送相应的数据请求。

结合第一方面的第七种可能的实现方式，在第八种可能的实现方式中，

利用每个所述微服务进程对对应的所述数据提供端进行监测，判断每个所述数据提供端中的数据结构是否发生改变；

若是，根据发生改变的所述数据结构更新对应的所述数据提供端的数据目录。

在本申请实施例中，基于对数据提供端进行监测，就可以基于数据提供端发生改变的数据结构而实时的对数据目录进行更新。

第二方面，本申请实施例提供了一种数据请求方法，所述方法包括：

获取所述数据请求端发送的目录获取请求，其中，所述目录获取请求中携带有数据目录对应的标识；

从多个数据提供端的数据目录中确定出与所述标识对应的目标数据目录，其中，所述目标数据目录对应的数据提供端为目标数据提供端；

将所述目标数据目录发送到所述数据请求。

第三方面，本申请实施例提供了一种数据请求装置，所述装置包括：

获取模块，用于获得数据请求端发送的数据获取请求；

处理模块，用于确定出与所述数据获取请求对应的目标数据提供端，以及确定出所述目标数据提供端的数据提供方式；

所述处理模块，还用于从多个微服务进程中确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程；

所述获取模块，还用于通过所述目标微服务进程向所述目标数据提供端请求数据。

结合第三方面，在第一种可能的实现方式中，

所述处理模块，还用于获取每个所述微服务进程在创建时生成的注册信息，其中，所述注册信息中包含有对应所述微服务进程的数据请求方式；根据所述注册信息，确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程。

结合第三方面，在第二种可能的实现方式中，

所述获取模块，还用于判断所述目标微服务进程是否处于可用状态；若是，通过所述目标微服务进程将所述数据获取请求的格式转换成与所述数据提供方式对应的格式，并向所述目标数据提供端发送格式转换后的所述数据获取请求。

结合第三方面的第二种可能的实现方式，在第三种可能的实现方式中，

所述获取模块，还用于判断所述目标微服务进程是否发送过续租报文以及在发送所述续租报文之后所述目标微服务进程是否发送过进程注销报文；

其中，所述目标微服务进程发送过所述续租报文且在发送所述续租报文之后所述目标微服务进程未发送过所述进程注销报文表示所述目标微服务进程处于所述可用状态。

结合第三方面的第二种可能的实现方式，在第四种可能的实现方式中，所述装置还包括：

所述获取模块，还用于获取所述目标数据提供端基于响应格式转换后的所述数据获取请求而返回的所需数据；

所述处理模块，用于生成所述所需数据的数据结构的注释信息；

发送模块，用于将所述所需数据和所述注释信息发送给所述数据请求端。

结合第三方面，在第六种可能的实现方式中，所述装置还包括：

所述处理模块，还用于周期性判断在当前周期内获取的所有请求的响应率是否达到响应率阈值；若是，继续获取新的请求并处理，否则，在当前时刻起之后的预设时长内停止获取新的请求。

结合第三方面的第四种可能的实现方式，在第六种可能的实现方式中，所述装置还包括：

所述获取模块，还用于获取所述数据请求端发送的目录获取请求，其中，所述目录获取请求中携带有数据目录对应的标识；

所述处理模块，还用于从多个数据提供端的数据目录中确定出与所述标识对应的目标数据目录，其中，所述目标数据目录对应的数据提供端为所述目标数据提供端；

所述发送模块，还用于将所述目标数据目录发送到所述数据请求端，使得所述数据请求端基于所述目标数据目录生成所述数据获取请求。

结合第三方面的第六种可能的实现方式，在第八种可能的实现方式中，

所述处理模块，还用于利用每个所述微服务进程对对应的所述数据提供端进行监测，判断每个所述数据提供端中的数据结构是否发生改变；若是，根据发生改变的所述数据结构更新对应的所述数据提供端的数据目录。

第四方面，本申请实施例提供了一种数据请求装置，所述装置包括：

获取模块，用于获取所述数据请求端发送的目录获取请求，其中，所述目录获取请求中携带有数据目录对应的标识；

处理模块，用于从多个数据提供端的数据目录中确定出与所述标识对应的目标数据目录，其中，所述目标数据目录对应的数据提供端为目标数据提供端；

发送模块，用于将所述目标数据目录发送到所述数据请求端。

第五方面，本申请实施例提供了一种数据转发装置，所数据转发装置包括：通信接口、存储器、处理器；

所述通信接口、所述存储器和所述处理器连接；

所述储存器，用于存储程序；

所述处理器，用于运行所述程序以执行如第一方面、第一方面的第一种至第八种中的任一种可能的实现方式或第二方面所述的数据请求方法的步骤。

第六方面，本申请实施例提供了一种数据共享系统，所述数据共享系统包括：数据提供端、数据请求端和数据转发装置；

所述数据转发装置，用于基于所述数据提供端和所述数据请求端进行通信，以执行如第一方面、第一方面的第一种至第八种中的任一种可能的实现方式或第二方面所述的数据请求方法的步骤。

第七方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被计算机运行时执行如第一方面、第一方面的第一种至第八种中的任一种可能的实现方式或第二方面所述的数据请求方法的步骤。

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

附图说明

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

图1示出了本申请实施例提供的一种数据共享系统的结构框图；

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

图3示出了本申请实施例提供的一种数据请求方法中数据目录的示意图；

图4示出了本申请实施例提供的一种数据请求方法中注释信息的示意图；

图5示出了本申请实施例提供的一种数据请求装置的结构框图。

具体实施方式

下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

请参阅图1，本申请实施例提供了一种数据共享系统10，该数据共享系统10可以包括：数据提供端100、数据请求端200和数据转发装置300。

示例性的，为实现多平台的数据共享时，数据提供端100和数据请求端200可以为多个。不同的数据提供端100之间、不同的数据请求端200之间、以及不同的数据提供端100和数据请求端200之间的拥有者可以不同，例如，数据提供端A1可以所属于财务局、但数据提供端A2可以所属于检查局。当然，同一拥有者也可以拥有不止一个的数据提供端100或数据请求端200，例如，财务局可以拥有数据提供端A1和数据提供端A2。

另外，根据实际情况，比如在数据量小的情况下，为便于尽可能多的响应更多的数据请求，属于同一拥有者的不同的数据提供端100提供的数据可以相同。或者在数据量大的情况下，为便于降低设备的负荷，可以将数据分担到不同的数据提供端100，从而使得属于同一拥有者的不同的数据提供端100提供的数据可以不相同，例如，财务局拥有数据提供端A1提供的数据是A片区内用户的税务缴纳数据，但财务局拥有数据提供端A2提供的数据是另一B片区内用户的税务缴纳数据。

需要理解到的是，本实施例中所述的数据提供端100和数据请求端200可以是逻辑层面上的概念，它们可以由物理层面上的物理设备实现，即当该物理设备需要进行数据请求时，则该物理设备可以作为数据请求端100，反之，在当该物理设备需要响应数据请求而提供数据时，则该物理设备便可以作为数据提供端200。

作为示例性的方式，实现数据提供端100或数据请求端200的物理设备可以是终端或者服务器。其中，终端可以是个人电脑(persoMal computer，PC)、平板电脑、智能手机、个人数字助理(persoMal digital assistaMt，PDA)等。服务器则可以是单个服务器，也可以是服务器组，且服务器组可以是集中式的，也可以是分布式的，以及服务器也可以基于云平台例如私有云、公有云、混合云、社区云(community cloud)、分布式云、跨云(inter-cloud)、多云(multi-cloud)等，或者它们的任意组合来实现。

在数据共享系统10中，数据转发装置300可以是一个或者多个，其数量可以根据数据需求量进行选择，例如，在数据需求量大时，数据转发装置300可以是多个，反之，则可以是一个。

于本实施中，数据转发装置300也可以是物理设备实现，例如，数据转发装置300也可以由终端或者服务器实现，进一步的，数据转发装置300可以包括：通信接口310、用于执行程序指令的一个或多个处理器320、总线330、和不同形式的存储器340，例如，磁盘、ROM、或RAM，或其任意组合。示例性地，数据转发装置300还可以包括存储在ROM、RAM、或其他类型的非暂时性存储介质、或其任意组合中的程序指令。根据这些程序指令可以实现本申请的方法。

存储器340中存储有程序，而处理器320通过总线330可以调用并运行储存器340中存储的程序。处理器320在运行该程序时，在逻辑层面上，处理器320可以建立并维护多个微服务进程301，且每个微服务进程301可以用于按每个微服务进程301预设的至少一种数据请求方式去请求数据。那么在处理器320处理由通信接口320获取的数据请求端200发送的数据获取请求时，处理器可以根据数据获取请求确定出对应的数据提供端100的数据提供方式，这样处理器320便调用能够按照该数据提供方式对应的方式请求数据的微服务进程301，从该数据提供端100请求到数据并发送给对应的数据请求端200，从而实现了本申请所述的方法。

示例性的，微服务进程301中可以包含进行了封装的程序，封装的程序不同则使得微服务进程301可以按照不同的方式去请求数据。数据提供端100的数据提供方式可以包括：API调用方式、自动索引方式、DB(Database，数据库)查询的方式和流数据传输的方式等。那么按照这些数据提供方式，各微服务进程301中则可以例如数据请求引擎的程序，即每个微服务进程301中封装的数据请求引擎相应的为API引擎、自动索引引擎、DB引擎或流数据引擎。

进一步的，在每个数据提供端100提供了各类型的数据的基础上，那么微服务进程301则可以针对每个数据提供端100提供的各类型数据的数据提供方式而封装相应方式的数据请求引擎。

作为可选的第一种方式，可以针对每个数据提供端100提供的每种类型数据的数据提供方式而建立一个微服务进程301。例如，数据提供端A提供文本类型数据又提供视频数据，那么针对数据提供端A提供的文本类型数据的API调用方式，则可以建立一个封装了API引擎并可以专门请求数据提供端A提供的文本类型数据的微服务进程A1。并且还可以针对数据提供端A提供的视频数据的流数据传输方式，可以再建立一个封装了流数据引擎并可以专门请求数据提供端A提供的视频数据的微服务进程A2。

可以理解到，实施微服务进程301的第一种方式的实施比较细化，也是数据请求的精准度比较高和失败率比较低的一种方式。在实际中这种方式比较耗费资源，若数据提供端100的数据或数据提供端100提供的数据的类型比较少的情况下，可以选择采用这种方式。

作为可选的第二种方式，可以针对每个数据提供端100提供的所有类型数据的数据提供方式而建立一个微服务进程301。例如，数据提供端A3提供文本类型数据又提供视频数据，那么针对数据提供端A3提供的文本类型数据的API调用方式和提供的视频数据的流数据传输方式，则可以建立一个封装了API引擎和流数据引擎的微服务进程A3，其中，API引擎可以用于专门请求数据提供端A3提供的文本类型数据，而流数据引擎则可以用于专门请求数据提供端A3提供的视频数据。

作为可选的第三种方式，还可以针对不同数据提供端100的相同数据提供方式而建立一个微服务进程301。例如，数据提供端A4提供文本类型数据且数据提供端A5也提供文本类型数据，那么针对数据提供端A提供的文本类型数据的API调用方式和针对数据提供端B提供的文本类型数据的API调用方式，建立一个封装了第一API引擎和第二API引擎的微服务进程AB，其中，第一API引擎用于专门请求数据提供端A提供的文本类型数据，而第二API引擎则用于专门请求数据提供端B提供的文本类型数据。

可以理解到，实施微服务进程的第二和第三种方式较于第一种方式则没有这么细化，其数据请求的精准度会稍低且失败率也会稍高。在实际中这种方式比较节约资源，若数据提供端100的数据或数据提供端提供的数据的类型比较多的情况下，可以选择采用这种方式。

另外，在实际实施中，数据转发装置300中也不限于只以第一、第二或第三种来建立各微服务进程301，其也可以同时采用第一、第二和第三种中的至少两种来建立各微服务进程301。

上述是对系统架构层面的介绍说明，下面将对数据转发装置基于与数据提供端和数据请求端的通信而如何执行本申请的方法进行详细地说明。

如图2所示，本申请实施例提供了一种数据请求方法，该数据请求方法可以由数据转发装置执行，数据请求方法可以包括：步骤S101、步骤S102、步骤S103、步骤S104、步骤S105、步骤S106、步骤S107、步骤S108和步骤S109。

步骤S101：获取所述数据请求端发送的目录获取请求，其中，所述目录获取请求中携带有与所述目标数据提供端的目标数据目录对应的标识。

步骤S102：从多个数据提供端的数据目录中确定出与所述标识对应的所述目标数据目录。

步骤S103：将所述目标数据目录发送到所述数据请求端，使得所述数据请求端基于所述目标数据目录生成所述数据获取请求。

步骤S104：获得数据请求端发送的数据获取请求。

步骤S105：确定出与所述数据获取请求对应的目标数据提供端，以及确定出所述目标数据提供端的数据提供方式。

步骤S106：从多个微服务进程中确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程。

步骤S107：通过所述目标微服务进程向所述目标数据提供端请求数据。

步骤S108：生成所述所需数据的数据结构的注释信息。

步骤S109：将所述所需数据和所述注释信息发送给所述数据请求端。

下面将对本申请数据请求方法的流程进行详细地说明。

由于数据提供端很多，且各数据提供端提供的数据也种类繁多，因此数据请求端在请求数据之前，为便于获知自己需要向数据提供端请求何种数据，那么数据请求端可以向数据转发装置发送目录获取请求。

相应的，数据转发装置则可以执行步骤S101。

步骤S101：获取所述数据请求端发送的目录获取请求，其中，所述目录获取请求中携带有与所述目标数据提供端的目标数据目录对应的标识。

数据转发装置通过与数据请求端的通信，数据请求端则可以获取数据请求端发送的目录获取请求。其中，数据转发装置基于目录获取请求可以把相应数据提供端的数据目录发送给数据请求端，以便于数据请求端的用户基于数据目录可以清楚获知自己需要向数据提供端请求何种数据。

在此基于上，为便于数据转发装置通过目录获取请求而确定需要把哪个数据提供端的数据目录发送给数据请求端，数据请求端在生成目录获取请求时则可以在目录获取请求中对相应的数据请求端进行标注。

示例性的，数据请求端可以生成目标数据提供端的目标数据目录对应的标识，并在生成目录获取请求时将该标识写入到该目录获取请求中，使得该目录获取请求中携带与目标数据提供端的目标数据目录对应的标识。这样数据转发装置基于该标识便可以便捷且准确的确定出需要提供哪个目标数据提供端的目标数据目录。

进一步的，在第一种情况下，若目标数据目录的名称字段比较短，标识可以是目标数据目录的名称字段，以便于匹配。例如目标数据目录1的名称字段为A-BB，则可以将标识设置为A-BB；目标数据目录2的名称字段为C-BB，则可以将标识设置为C-BB。在第二种情况下，若目标数据目录的名称字段比较短在目标数据目录的名称字段比较长，标识可以是重新设置一个比较短的字段，以降低匹配时的计算量。例如目标数据目录的名称字段为A-BB-CC-DD-E，则可以将标识设置为A1，例如目标数据目录的名称字段为S-BB-CC-DD-E，则可以将标识设置为S1。

当然，关于标识的具体实施例也不限于上述例举的实施方式，与上述实施方式等同的方式也应在本申请的保护范围内。

进一步的，在数据转发装置获取目录获取请求的情况下，通过对该目录获取请求拆封装，则可以获取到该目录获取请求中携带的标识。

步骤S102：从多个数据提供端的数据目录中确定出与所述标识对应的所述目标数据目录。

数据转发装置在获取标识后，数据转发装置则可以通过标识来确定出标识对应的目标数据目录。

示例性的，作为确定标识对应的目标数据目录的第一种方式，在标识是目标数据目录的名称字段的情况下，数据转发装置中预设了每个数据提供端的数据目录的名称字段，那么数据转发装置可以将标识与每个数据提供端的数据目录的名称字段匹配。在数据转发装置确定某个数据提供端的数据目录的名称字段与标识匹配时，则可以确该匹配的数据提供端的数据目录为标识对应的目标数据提供端的目标数据目录。

示例性的，作为确定标识对应的目标数据目录的第二种方式，在标识是重新设置一个比较短的字段的情况下，数据转发装置中预设了每个数据提供端的数据目录的名称字段，并还预先建立每个数据目录的名称字段与对应的标识的字段之间的关联关系。那么数据转发装置可以通过该标识而确定出该标识对应的关联关系，并确定出关联关系中数据提供端的数据目录为标识对应的目标数据提供端的目标数据目录。

基于确定的目标数据目录，数据转发装置则确定需要将该目标数据目录发送给数据请求端，即可以执行步骤S103。

步骤S103：将所述目标数据目录发送到所述数据请求端，使得所述数据请求端基于所述目标数据目录生成所述数据获取请求。

数据转发装置基于确定出目标数据目录，则需要将该目标数据目录发送给数据请求端。

可选地，作为将目标数据目录发送给数据请求端的第一种方式，数据转发装置中可以设置每个目标数据目录的相关数据，其中，每个目标数据目录的相关数据可以是网页类型数据或者也可以是文件类型数据。基于此，数据转发装置可以采用推送的方式将目标数据目录的网页类型数据以网页的形式发送到数据请求端，使得数据请求端可以以网页的形式将该目标数据目录展示。或者，数据转发装置还可以采用数据传输的方式将该目标数据目录的文件类型数据发送给数据请求端，使得数据请求端对文件进行打开加载并显示，从而展示出目标数据目录展示。

可选地，作为将目标数据目录发送给数据请求端的第二种方式，每个目标数据目录的相关数据并未存储在数据转发装置上，其可以能存储在其它的服务器上。基于此，数据转发装置中可以设置每个目标数据目录的相关数据的链接。然后数据转发装置基于确定出的目标数据目录，可以将目标数据目录的链接发送给数据请求端，使得数据请求端基于链接去访问相应的服务器从而获取并展示出该目标数据目录。

数据请求端展示的目标数据目录可以是如图3所示，目标数据目录展示出目标数据提供端可以提供哪些种类的数据，例如图2中目标数据提供端为公安局人口库情况下，目标数据目录中包含的数据种类可以是：区域人口数据、区域驾驶人数据、区域暂住人口数据。

这样，数据请求端的用户基于展示出的目标数据目录，便可以获知自己需要向目标数据提供端请求何种数据。用户可以操作数据请求端，使得数据请求端生成携带有数据请求信息的数据获取请求，其中，该数据请求信息可以用于表示需要向目标数据提供端请求哪一种类的目标数据。

数据请求端通过将数据获取请求发送给数据转发装置，数据转发装置便可以执行步骤S104。

当然可以理解的是，数据请求端并不是每一次发送数据获取请求都要向数据转发装置请求数据目录，在用户知道自己需要向目标数据提供端请求何种数据的情况下或者数据请求端已经存储了目标数据目录的情况下，数据请求端可以无需请求该目标数据目录而直接生成数据获取请求。

步骤S104：获得数据请求端发送的数据获取请求。

数据转发装置通过与数据请求端的通信，则相应的获取到该数据请求端发送的数据获取请求。

示例性的，由于本实施例的微服务进程与普通进程在请求数据的维度上略有差别，普通进程请求的是大类的数据，但微服务进程请求的是子类的数据。此外，由于不同的数据请求方发送的数据获取请求的格式也可能不同，有的数据请求方发送的数据获取请求是普通请求的格式，例如，数据请求方A发送的普通请求的格式可以为A/A1-xxxx.A2-xxx，但有的数据请求方发送的数据获取请求确是微服务请求的格式，，数据请求方A发送的微服务请求的格式可以为A1-xxxx。

基于此，为便于对数据获取请求进行处理，数据转发装置在获取到普通请求格式的数据获取请求时，数据转发装置则可也根据普通请求格式的数据获取请求，而重新生成至少一个微服务请求格式的数据获取请求，生成微服务请求格式的每个数据获取请求中请求的数据类型为大类数据下一个子类数据。

例如，在普通请求格式的数据获取请求A的格式为A/A1-xxxx.A2-xxx的情况下，则可以基于其携带的A/信息表示为大类数据的人员身份信息，且该信息中的A1-xxxx.A2-xxx则包含的是人员身份信息下子类数据为人员教育信息和人员工作信息。从而可以根据该A1-xxxx.A2-xxx信息而生成微服务请求A1和微服务请求A2。其中，微服务请求A1的格式可以为A1-xxxx，而微服务请求B的格式可以为A2-xxx。

数据转发装置获取到微服务格式的数据获取请求或者获取到由普通格式转换成微服务格式的数据获取请求后，通过对获取到该数据获取请求进行解封装，则可以获取到数据获取请求中携带的数据请求信息。例如，微服务请求A1的格式为A1-xxxx的情况下，其xxxx字段内包含或者对应的信息则可以是微服务请求A1携带的数据请求信息。

那么在获取到数据请求信息后，便可以继续执行步骤S105。

步骤S105：确定出与所述数据获取请求对应的目标数据提供端，以及确定出所述目标数据提供端的数据提供方式。

由于不同的数据提供端的数据提供方式也可能完全不同，例如，数据提供端A的数据提供方式为API(Application Programming Interface,应用程序编程接口)的方式，但数据提供端B的数据提供方式则为流数据的方式。基于这种情况，为清楚的获知每个数据提供端的数据提供方式，数据转发装置中预先存储了每个数据提供端的数据提供方式，或者预先对每个数据提供端的数据提供方式进行标识。

进一步的，由于每个数据提供端能提供的数据类型可能有多种，且同一数据提供端的不同类型的数据的数据提供方式也可能不同。例如，数据提供端A提供文本类型数据又提供视频数据，那么针对文本类型数据可以采用API的提供方式，但针对视频数据则可以采用流数据的提供方式。故预先存储的每个数据提供端的数据提供方式可以是预先存储了每个数据提供端中每种数据类型的数据提供方式；或者，或者预先对每个数据提供端的数据提供方式进行标识则可以是对每个数据提供端中每种数据类型的数据提供方式进行标识。

进一步的，由于数据请求信息可以用于表示向目标数据提供端请求哪一种类的目标数据，故数据转发装置获取到数据请求信息后，即确定出了哪个数据提供端为本次需要请求数据的目标数据提供端，以及获知了本次需要向目标数据提供端请求哪一种类的目标数据。

在此基础上，数据转发装置可以基于数据请求信息确定出需要请求的目标数据的类型，从预设的多种数据提供方式中确定出该目标数据提供端的数据提供方式，即从多种数据提供方式确定出目标数据提供端提供的各类型数据中与该目标数据的类型相同的目标数据的数据提供方式。

基于确定出的目标数据的数据提供方式，数据转发装置还可以继续执行步骤S106。

步骤S106：从多个微服务进程中确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程。

在数据提供端为多个且不同的数据提供端的数据提供方式差异可能很大的情况下，为实现以每种数据提供方式对应的方式向相应的数据提供端请求数据，以避免请求失败。根据每个数据提供端的数据提供方式，数据转发装置中还预设了与之对应的多个微服务进程。

本实施例中，为实现基于确定出的目标数据提供端的数据提供方式而快捷且准确的确定出对应的目标微服务进程。作为一种示例性的方式，数据转发装置可以在每个微服务进程在创建时生成的注册信息中写入该微服务进程的数据请求方式。其中，数据请求方式的内容可以用于表示该微服务进程用于利用什么数据请求方式向哪个数据提供端请求何种类型的数据，例如，数据请求方式内容可以是：数据请求方式为AA，该数据请求方式为对应数据提供方式为BB，该微服务进程用于请求数据提供端XX的XX类型数据。

能够理解的是，在一个微服务进程中封装了多个数据请求引擎，且每个数据请求引擎可以用于请求一个数据提供端请求的某种数据类型的情况下，生成该微服务进程的注册信息中携带的数据请求方式也相应的为多个。

基于此，数据转发装置将目标数据提供端的数据提供方式与每个注册信息中的数据请求方式匹配，就可以确定出数据请求方式与该目标数据提供端的数据提供方式匹配的目标微服务进程，即确定出能够按照与数据提供方式对应的方式请求数据的目标微服务进程。

本实施例中，数据转发装置确定出目标微服务进程后，数据转发装置便可以执行步骤S107。

步骤S107：通过所述目标微服务进程向所述目标数据提供端请求数据。

本实施例中，确定出目标微服务进程的含义是理论上可以通过该目标微服务进程去请求相应的数据，但这不代表实际上该目标微服务进程就可用。若该目标微服务进程在实际中处于不可用的状态，利用该目标微服务进程去请求数据则会出现请求失败的情况。因此为保证数据请求的成功，在通过目标微服务进程去请求数据之前，数据转发装置可以先判断该目标微服务进程是否处于可用状态。

示例性的，确定目标微服务进程是否处于可用状态可以有两个条件，1是该目标微服务进程是否进行了续租，2是该目标微服务进程是否已经被注销。故基于这两个条件，数据转发装置则可以基于判断目标微服务进程是否发送过心跳方式的续租报文以及在发送续租报文之后该目标微服务进程是否发送过进程注销报文来准确的确定该目标微服务进程是否处于可用状态。

若判断为目标微服务进程未发送过续租报文，或在发送续租报文之后目标微服务进程还发送过进程注销报文，那么则表示该目标微服务进程可能以及被注销或关闭了，并且在表项中该目标微服务进程以及被删除了，从而便可以确定该目标微服务进程处于不可用状态。因此数据转发装置可以确定无法利用该目标微服务进程来请求数据。数据转发装置则可以生成包含该目标微服务进程可能已经被注销或失效了的请求失败信息并发送给数据请求端，使得用户基于该请求失败信息可以获知请求失败的具体原因。

若判断为目标微服务进程发送过续租报文且在发送续租报文之后目标微服务进程未发送过进程注销报文，那么则表示该目标微服务进程可能既没有被注销也没有关闭，从而便可以确定该目标微服务进程处于可用状态。因此数据转发装置确定可以利用该目标微服务进程来请求数据。

进一步的，数据转发装置基于确定利用该目标微服务进程来请求数据，数据转发装置可以调用该目标微服务进程，以通过该目标微服务进程来将数据获取请求的格式转换成与数据提供方式对应格式。那么通过该目标微服务进程向目标数据提供端发送格式转换后的数据获取请求便可以实现对数据的请求。

本实施例中，数据转发装置通过目标微服务进程向目标数据提供端发送格式转换后的数据获取请求，目标数据提供端响应该格式转换后的数据获取请求便可以从自身存储的数据确定出本次请求的所需数据。那么目标数据提供端将该所需数据再以对应的数据提供方式返回给数据转发装置，数据转发装置便可以获取该目标数据提供端基于响应格式转换后的数据获取请求而返回的所需数据。

作为第一种实施方式，数据转发装置在获取到该所需数据，便可以再将该所需数据发送给数据请求端，那么数据请求端则获取到了该所需数据，从而请求的流程可以结束了。

此外，作为第二种和第三种实施方式，数据转发装置还可以继续执行步骤S108和步骤S109。

作为第二种实施方，由于所需数据的数据结构可以是原始的代码结构，且不同数据提供端的数据结构差异很大，为便于用户获知数据结构中哪些字段对应的数据是自己需要的数据，数据转发装置预设了每个数据提供端能够提供的所有数据的所有数据结构的全部注释信息。例如图4所示，图4是关于注释信息的示意图，全部注释信息中对数据结构中每个字段的含义进行解释。那么，数据转发装置在获取到该所需数据，便可以再将该所需数据和该目标数据提供端的全部注释信息也一并发送给数据请求端，使得用户基于全部注释信息中每个字段的含义可以获知所需数据中哪些字段对应的数据是自己所需的数据。

作为第三种实施方式，其较于第二种实施方式，数据转发装置不仅预设了每个数据提供端能够提供的所有数据的所有数据结构的全部注释信息。数据转发装置在获取到所需数据后，还可以将所需数据与该目标数据提供端的全部注释信息进行匹配，从而确定出全部注释信息中有哪些字段是所需数据中具有的字段。然后数据转发装置便可以生成对所需数据中具有的字段的含义进行标注的注释信息。

其中，作为数据转发装置生成对所需数据中具有的字段的含义进行标注的注释信息的一种方式，数据转发装置重新生成的注释信息可以是一个新的文件。那么数据转发装置将该所需数据和重新生成的该注释信息也一并发送给数据请求端，使得用户基于重新生成的该注释信息中每个字段的含义可以快速的获知所需数据的数据结构中哪些是自己所需的数据。

作为数据转发装置生成对所需数据中具有的字段的含义进行标注的注释信息的另一种方式，数据转发装置重新生成该注释信息可以将所需数据中每个字段的含义标注到所需数据中，使得生成的注释信息包含在该所需数据内。例如，所需数据中的字段是：A-CCCC-ss-DD，那么将每个字段的含义标注到所需数据中则可以是：A-CCCC(用户身份信息)-ss-DD。这样数据转发装置便可以将该携带有注释信息的所需数据发送给数据请求端，使得用户基于所需数据中每个字段的标注而清楚的获知数据结构含义，并获知哪些数据是自己所需的数据。

本实施例中，数据转发装置预设的每个数据提供端的数据目录中不仅包含数据的类型，其具体可以包含每种数据类型的数据结构，即数据目录可以展示出每种数据类型中包含哪些字段。

为保证数据目录的正确性，数据转发装置还可以利用每个微服务进程对对应的数据提供端进行监测，判断每个数据提供端中的数据结构是否发生改变，即判断每个数据提供端提供的数据中是否有字段发生改变。

若确定发生改变，数据转发装置则可以根据发生改变的数据结构更新对应的数据提供端的数据目录，即数据转发装置根据数据结构中新增的字段、删除的字段和/或改变的字段对数据目录中的字段做相应的调整。

本实施例中，为实现对数据请求端发的请求及时作出响应，以提高用户的使用体验，数据转发装置可以对获取的每个请求进行跟踪监测，以判断每个请求是否超时还未响应，其中，超时的时间可以根据实际需要进行选择，例如，数据转发装置的性能很强大则设置的超时时间可以短一点，反之则可以长一点。若确定该请求超时还未响应，那么数据转发装置以自身预设的响应方式来响应该请求，例如，数据转发装置可以向数据请求端发送自定义的信息来实现对该请求的响应，其中，自定义的信息可以是XXX请求失败或XXX繁忙请求稍后再试等信息。

另外，为避免由于请求数量太多而导致无法及时响应的请求数量越来越多，进而导致系统崩溃，数据转发装置还可以采用隔离方式。具体的，数据转发装置可以判断对在预设时间段内获取的所有请求的响应率是否达到响应率阈值。其中，预设时间段可以是当前时刻之前的一段时长，其时长可以根据实际需求进行设置，例如预设时间段可以设置为10分钟、20分钟、30分等。另外，响应率则可以是预设时间段内超时响应或未响应的请求在预设时间段内获取的所有请求中的占比。再者，响应率阈值也可以根据实际情况进行选择，例如请求的数量很多则可以把响应率阈值设置的低一些，反之则可以高一些。

若数据转发装置确定响应率是否达到响应率阈值，则说明超时响应或未响应的请求数量还不是很多，数据转发装置可以继续处理获取的新的请求；否则，数据转发装置则可以在当前时刻之后的预设时长内停止获取新的请求，以免超时响应或未响应的请求数量越来越多而导致系统崩溃。进一步的，在停止获取新的请求经过该预设时长后，数据转发装置又可以恢复处理获取的新的请求。为避免数据转发装置再次陷入崩溃的风险，数据转发装置在恢复处理后，数据转发装置可以选择性的获取并处理少量的请求，并判断确定恢复后的响应率是否大于响应率阈值时，若大于，再逐步增加对请求的获取量。

请参阅图5，本申请的一些实施例提供了一种数据请求装置400，该数据请求装置400应用于数据转发装置，该数据请求装置400可以包括：

获取模块410，用于获得数据请求端发送的数据获取请求。

处理模块420，用于确定出与所述数据获取请求对应的目标数据提供端，以及确定出所述目标数据提供端的数据提供方式。

所述处理模块420，还用于从多个微服务进程中确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程。

所述获取模块410，还用于通过所述目标微服务进程向所述目标数据提供端请求数据。

可选地，所述处理模块420，还用于获取每个所述微服务进程在创建时生成的注册信息，其中，所述注册信息中包含有对应所述微服务进程的数据请求方式；根据所述注册信息，确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程。

可选地，所述请求模块410，还用于判断所述目标微服务进程是否处于可用状态；若是，通过所述目标微服务进程将所述数据获取请求的格式转换成与所述数据提供方式对应的格式，并向所述目标数据提供端发送格式转换后的所述数据获取请求。

可选地，所述获取模块410，还用于判断所述目标微服务进程是否发送过续租报文以及在发送所述续租报文之后所述目标微服务进程是否发送过进程注销报文；

其中，所述目标微服务进程发送过所述续租报文且在发送所述续租报文之后所述目标微服务进程未发送过所述进程注销报文表示所述目标微服务进程处于所述可用状态。

可选地，该数据请求装置400还可以包括：

所述获取模块410，还用于获取所述目标数据提供端基于响应格式转换后的所述数据获取请求而返回的所需数据。

所述处理模块420，还用于生成所述所需数据的数据结构的注释信息。

发送模块430，用于将所述所需数据和所述注释信息发送给所述数据请求端。

以及，所述处理模块420，还用于周期性判断在当前周期内获取的所有请求的响应率是否达到响应率阈值；若是，继续获取新的请求并处理，否则，在当前时刻起之后的预设时长内停止获取新的请求。

所述获取模块410，还用于获取所述数据请求端发送的目录获取请求，其中，所述目录获取请求中携带有数据目录对应的标识。

所述处理模块420，还用于从多个数据提供端的数据目录中确定出与所述标识对应的目标数据目录，其中，所述目标数据目录对应的数据提供端为目标数据提供端。

所述发送模块430，还用于将所述目标数据目录发送到所述数据请求端，使得所述数据请求端基于所述目标数据目录生成所述数据获取请求。

所述处理模块420，还用于利用每个所述微服务进程对对应的所述数据提供端进行监测，判断每个所述数据提供端中的数据结构是否发生改变；若是，根据发生改变的所述数据结构更新对应的所述数据提供端的数据目录。

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

本申请一些实施例还提供了一种计算机可执行的非易失的程序代码的计算机可读储存介质，该计算机可读存储介质上存储有程序代码，该程序代码被计算机运行时执行上述任一实施方式的数据请求方法的步骤。

详细地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的程序代码被运行时，能够执行上述施例的数据请求方法的步骤，以实现源端可以满足实际需求，提升其实际中的适用性。

本申请实施例所提供的数据请求方法的程序代码产品，包括存储了程序代码的计算机可读存储介质，程序代码包括的指令可用于执行前面方法实施例中的方法，具体实现可参见方法实施例，在此不再赘述。

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

综上所述，本申请实施例提供了一种数据请求方法、装置、系统、数据转发装置及存储介质。方法包括：获得数据请求端发送的数据获取请求；确定出与数据获取请求对应的目标数据提供端，以及确定出目标数据提供端的数据提供方式；从多个微服务进程中确定出能够按照与数据提供方式对应的方式请求数据的目标微服务进程；通过目标微服务进程向目标数据提供端请求数据。

由于针对各数据提供方式都专门建立了微服务进程来以对应的方式请求数据，故在发送前可以先确定出与数据提供方式对应的微服务进程，再通过目标微服务进程以适配的方式去请求数据，就可以避免在请求时出现与数据请求方式不对应的情况，从而避免请求失败的情况发生。

以上仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种数据请求方法，其特征在于，所述方法包括：

获得数据请求端发送的数据获取请求；

确定出与所述数据获取请求对应的目标数据提供端，以及确定出所述目标数据提供端的数据提供方式；

从多个微服务进程中确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程；

通过所述目标微服务进程向所述目标数据提供端请求数据。

2.根据权利要求1所述的数据请求方法，其特征在于，从多个微服务进程中确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程，包括：

获取每个所述微服务进程在创建时生成的注册信息，其中，所述注册信息中包含有对应所述微服务进程的数据请求方式；

根据所述注册信息，确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程。

3.根据权利要求1所述的数据请求方法，其特征在于，通过所述目标微服务进程向所述目标数据提供端请求数据，包括：

判断所述目标微服务进程是否处于可用状态；

若是，通过所述目标微服务进程将所述数据获取请求的格式转换成与所述数据提供方式对应的格式，并向所述目标数据提供端发送格式转换后的所述数据获取请求。

4.根据权利要求3所述的数据请求方法，其特征在于，判断所述目标微服务进程是否处于可用状态，包括：

判断所述目标微服务进程是否发送过续租报文以及在发送所述续租报文之后所述目标微服务进程是否发送过进程注销报文；

其中，所述目标微服务进程发送过所述续租报文且在发送所述续租报文之后所述目标微服务进程未发送过所述进程注销报文表示所述目标微服务进程处于所述可用状态。

5.根据权利要求3所述的数据请求方法，其特征在于，

每个所述微服务进程中封装的数据请求引擎为API引擎、自动索引引擎、DB引擎或流数据引擎。

6.根据权利要求3所述的数据请求方法，其特征在于，在通过所述目标微服务进程向所述目标数据提供端请求数据之后，所述方法还包括：

获取所述目标数据提供端基于响应格式转换后的所述数据获取请求而返回的所需数据；

生成所述所需数据的数据结构的注释信息；

将所述所需数据和所述注释信息发送给所述数据请求端。

7.根据权利要求1-6任一权项所述的数据请求方法，其特征在于，在获得数据请求端发送的数据获取请求之前，所述方法还包括：

获取所述数据请求端发送的目录获取请求，其中，所述目录获取请求中携带有数据目录对应的标识；

从多个数据提供端的数据目录中确定出与所述标识对应的目标数据目录，其中，所述目标数据目录对应的数据提供端为所述目标数据提供端；

将所述目标数据目录发送到所述数据请求端，使得所述数据请求端基于所述目标数据目录生成所述数据获取请求。

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

利用每个所述微服务进程对对应的所述数据提供端进行监测，判断每个所述数据提供端中的数据结构是否发生改变；

若是，根据发生改变的所述数据结构更新对应的所述数据提供端的数据目录。

9.一种数据请求方法，其特征在于，所述方法包括：

获取所述数据请求端发送的目录获取请求，其中，所述目录获取请求中携带有数据目录对应的标识；

从多个数据提供端的数据目录中确定出与所述标识对应的目标数据目录，其中，所述目标数据目录对应的数据提供端为目标数据提供端；

将所述目标数据目录发送到所述数据请求端。

10.一种数据请求装置，其特征在于，所述装置包括：

获取模块，用于获得数据请求端发送的数据获取请求；

处理模块，用于确定出与所述数据获取请求对应的目标数据提供端，以及确定出所述目标数据提供端的数据提供方式；

所述处理模块，还用于从多个微服务进程中确定出能够按照与所述数据提供方式对应的方式请求数据的目标微服务进程；

所述获取模块，还用于通过所述目标微服务进程向所述目标数据提供端请求数据。