CN107800781A - 一种配置数据处理方法和装置 - Google Patents

Abstract

本发明实施例公开了一种配置数据处理方法和装置，其中，所述方法包括：获取与目标配置信息对应的加载请求；获取与所述加载请求对应的第一类配置文件，并获取与所述第一类配置文件具有映射关系的第二类配置文件；所述第二类配置文件与多个第一类配置文件具有映射关系；将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。采用本发明，可对各配置文件进行集中管理，以避免数据的冗余。

Description

一种配置数据处理方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种配置数据处理方法和装置。

背景技术

在微服务架构中，服务之间存在着错综复杂的依赖关系，即每个服务都有自己依赖的配置文件，在这些服务运行期间，需要根据访问流量等因素对这些服务的配置文件进行调整。

传统的配置信息处理方式是将与系统无关的配置信息写入properties文件中，和应用一起打包，即一个应用程序可以对应一个携带配置信息的数据包。然而，当系统规模逐渐扩大，服务的拆分越来越细化时，则需要对各数据包中的配置信息(即待配置文件中的配置数据)进行相应的修改，并在修改后重新进行打包。即此时，分别部署在多个机器上的待配置文件中将携带相同的配置数据，进而造成数据的冗余。于是，当各待配置文件中的相同数据部分存在更新时，需要分别对部署在各台机器上的待配置文件中的数据进行修改，从而增加了对各待配置文件进行维护的难度。

发明内容

本发明实施例所要解决的技术问题在于，提供一种配置数据处理方法和装置，可对各配置文件进行集中管理，以避免各配置文件中数据的冗余。

本发明实施例提供了一种配置数据处理方法，包括：

获取与目标配置信息对应的加载请求；

获取与所述加载请求对应的第一类配置文件，并获取与所述第一类配置文件具有映射关系的第二类配置文件；所述第二类配置文件与多个第一类配置文件具有映射关系；

将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

可选的，所述方法还包括：

接收登录请求，并根据所述登录请求中所携带的目标用户信息，访问目标项目；

获取与所述目标项目对应的多个待配置文件，并根据预设的配置规则，将具有相同服务配置信息的待配置文件添加至同一服务配置集合；

在每个服务配置集合中，从各待配置文件中分离出相同的服务配置信息；

从各服务配置信息中分离出相同的项目配置信息，并创建与所述项目配置信息对应的项目公共配置文件；

创建与分离后的服务配置信息对应的服务公共配置文件，并为分离后的各待配置文件中所剩余的私有配置信息，创建对应的私有配置文件；

为各服务公共配置文件分别创建与所述项目配置文件之间的映射关系，并为各私有配置文件分别创建与所述服务公共配置文件之间的映射关系；一个服务配置集合中，包括一个服务公共配置文件与至少一个与所述服务公共配置文件具有映射关系的私有配置文件。

其中，所述获取与所述第一类配置文件具有映射关系的第二类配置文件，包括：

若所述第一类配置文件为所述服务公共配置文件，则获取与所述服务公共配置文件具有映射关系的所述项目公共配置文件；

则所述将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息，包括：

将获取到的所述服务公共配置文件与获取到的所述项目公共配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

可选的，其中，所述获取与所述第一类配置文件具有映射关系的第二类配置文件，包括：

若所述第一类配置文件为所述私有配置文件，则获取与所述私有配置文件具有映射关系的所述服务公共配置文件，并进一步获取与所述服务公共配置文件具有映射关系的所述项目公共配置文件；

则所述将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息，包括：

将获取到的所述私有配置文件中、获取到的所述服务公共配置文件以及获取到的所述项目公共配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

可选的，所述方法还包括：

监控系统信息参数或应用信息参数是否发生变化；

若所述系统信息参数或所述应用信息参数发生变化，则获取与所述系统信息参数或所述应用信息参数关联的目标配置文件；其中，所述目标配置文件为所述私有配置文件，所述服务公共配置文件、所述项目公共配置文件中的至少一种配置文件；

根据变化后的系统信息参数或所述应用信息参数，更新所述目标配置文件。

本发明实施例第二方面提供了一种配置数据处理装置，包括：

加载请求获取模块，用于获取与目标配置信息对应的加载请求；

第一获取模块，用于获取与所述加载请求对应的第一类配置文件；

第二获取模块，用于获取与所述第一类配置文件具有映射关系的第二类配置文件；所述第二类配置文件与多个第一类配置文件具有映射关系；

配置信息返回模块，用于将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

可选的，所述装置还包括：

目标项目访问模块，用于接收登录请求，并根据所述登录请求中所携带的目标用户信息，访问目标项目；

配置文件添加模块，用于获取与所述目标项目对应的多个待配置文件，并根据预设的配置规则，将具有相同服务配置信息的待配置文件添加至同一服务配置集合；

服务分离模块，用于在每个服务配置集合中，从各待配置文件中分离出相同的服务配置信息；

项目分离模块，用于从各服务配置信息中分离出相同的项目配置信息，并创建与所述项目配置信息对应的项目公共配置文件；

第一创建模块，用于创建与分离后的服务配置信息对应的服务公共配置文件，并为分离后的各待配置文件中所剩余的私有配置信息，创建对应的私有配置文件；

第二创建模块，用于为各服务公共配置文件分别创建与所述项目配置文件之间的映射关系，并为各私有配置文件分别创建与所述服务公共配置文件之间的映射关系；一个服务配置集合中，包括一个服务公共配置文件与至少一个与所述服务公共配置文件具有映射关系的私有配置文件。

其中，所述第二获取模块，具体用于若所述第一类配置文件为所述服务公共配置文件，则获取与所述服务公共配置文件具有映射关系的所述项目公共配置文件；

则所述配置信息返回模块，具体用于将获取到的所述服务公共配置文件与获取到的所述项目公共配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

可选的，其中，所述第二获取模块，具体用于若所述第一类配置文件为所述私有配置文件，则获取与所述私有配置文件具有映射关系的所述服务公共配置文件，并进一步获取与所述服务公共配置文件具有映射关系的所述项目公共配置文件；

则所述配置信息返回模块，具体用于将获取到的所述私有配置文件中、获取到的所述服务公共配置文件以及获取到的所述项目公共配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

可选的，所述装置还包括：

参数监控模块，用于监控系统信息参数是否发生变化；

目标文件获取模块，用于若所述系统信息参数发生变化，则获取与所述系统信息参数关联的目标配置文件；其中，所述目标配置文件为所述私有配置文件，所述服务公共配置文件、所述项目公共配置文件中的至少一种配置文件；

文件更新模块，用于根据变化后的系统信息参数或所述应用信息参数，更新所述目标配置文件。

本发明实施例第三方面提供了一种配置数据处理装置，包括：处理器、存储器、网络接口；

所述处理器分别与网络接口、存储器相连，其中，所述网络接口用于提供网络通讯功能，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，以执行如本发明实施例第一方面中所述的方法。

本发明实施例第四方面提供了一种计算机存储介质，其特征在于，所述计算机存储介质存储有计算机程序，所述计算机程序包括程序指令，当所述处理器执行所述程序指令时执行如本发明实施例第一方面中的方法。

实施本发明实施例，具有如下有益效果：

本发明实施例通过获取与目标配置信息对应的加载请求；获取与所述加载请求对应的第一类配置文件，并获取与所述第一类配置文件具有映射关系的第二类配置文件；所述第二类配置文件与多个第一类配置文件具有映射关系；将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。由此可见，本发明在接收到加载请求时，可首先获取与所述加载请求对应的第一类配置文件，以得到所述第一类配置文件中的数据，然后，还可进一步获取与所述第一类配置文件具有映射关系的第二类配置文件，以得到所述第二类配置文件中的数据，进而可以动态的将各配置文件中的不同数据进行融合，以得到与所述加载请求对应的目标配置信息，从而实现对各配置文件的集中管理。此外，通过对配置文件进行分类，可以确保每个不同配置文件中的数据互不相同，以避免配置文件中数据的冗余。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种网络架构的结构示意图；

图2是本发明实施例提供的一种配置数据处理方法的流程示意图；

图3是本发明实施例提供的一种各配置文件的分布架构图；

图4是本发明实施例提供的另一种配置数据处理方法的流程示意图；

图5是本发明实施例提供的一种配置数据处理装置的结构示意图；

图6是本发明实施例提供的另一种配置数据处理装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参见图1，是本发明实施例提供的一种网络架构的结构示意图。如图1所示，所述网络架构可以包括配置终端2000，服务终端4000以及用户终端集群；所述用户终端集群可以包括多个用户终端，如图1所示，具体包括用户终端3000a、用户终端3000b、…、用户终端3000n；

所述服务终端4000与所述配置终端2000进行网络连接，所述用户终端3000a、用户终端3000b、…、用户终端3000n可以分别与所述配置终端2000进行网络连接。

应当理解，此处，各用户终端可以为用于部署有相应应用程序实例(即进程)的机器(例如，可用于测试的服务器等)。此外，所述配置终端2000还可以与所述服务器终端4000构成具有数据处理功能的一体化设备，即该服务终端4000可以集成于该配置终端2000中，以在该配置终端2000的本地，就可以加载与各用户终端的加载请求所对应的配置文件。此时，所述服务终端4000中存储有与各用户终端中相应应用程序实例所对应的配置信息(例如，对于有三个实例的应用程序A而言，则可以在该服务终端4000中存储有应用程序A中实例1的私有配置信息，实例2的私有配置信息以及实例3的私有配置信息以及与各实例对应的公有配置信息)。

如图1所示，当所述用户终端3000a、用户终端3000b、…、用户终端3000n中的各应用程序启动(即应用程序中的进程启动)时，可向所述配置终端2000发送相应配置信息的加载请求，所述加载请求用于促使所述配置终端2000，从服务终端4000中获取启动相应应用程序所需配置文件；即所述配置终端2000可用于接收各用户终端发送的加载请求，并根据各加载请求从所述服务终端4000中获取相应的配置文件，其中，所述配置文件是指应用程序启动时，会用到一些基本的参数，例如：应用程序日志级别、数据库用户名，数据库密码等。因此，所述配置终端2000可获取与各请求分别对应的第一类配置文件和与所述第一类配置文件具有映射关系的第二类配置文件。随后，所述配置终端2000可以将获取到的各第一类配置文件与其对应的第二类配置文件进行融合，得到与各加载请求分别对应的目标配置信息，并将各目标配置信息作为与各加载请求所对应的响应信息返回至相应的用户终端，以使各用户终端在获得各目标配置信息时，可以对其进行加载，以完成对各应用程序的启动。

其中，当一个应用程序启动时，可同时启动多个项目系统下的待配置文件，这些待配置文件中大多携带有相同的服务配置信息和项目配置信息。因此，为对各待配置文件进行集中管理，可将同一项目系统(即目标项目)下的各待配置文件中的相同数据提取出来，以对各待配置文件中的配置信息(即数据)进行分类管理，以避免数据的冗余。于是，所述配置终端2000可将各待配置文件拆分为第一类配置文件和第二类配置文件。

其中，所述第一类配置文件可以为私有配置文件，即每个实例(即进程)启动时对应加载本实例的配置信息，例如，本实例的端口信息。可选的，所述第一类配置文件还可以为服务配置文件，即同一微服务在启动多个实例的时候都会去加载的配置信息，例如，数据库连接配置。其中，所述微服务是指可以将与某个应用程序关联的服务分解成更小的、松散耦合的实例的一种服务。

其中，所述配置终端2000还可以包括配置中心2000a和Web终端2000b；所述配置中心2000a可以与所述用户终端3000a、用户终端3000b、…、用户终端3000n进行网络连接，以接收各用户终端发送的加载请求。此外，测试用户、运维用户以及开发用户可在登录所述Web终端2000b后，进一步通过该Web终端2000b中的配置界面对所述配置中心2000a所获取到的配置文件进行编辑(比如，可创建与所述加载请求对应的各配置文件之间的映射关系)。

比如，以与配置终端2000相连的用户终端分别为用户终端3000a，用户终端3000b和用户终端3000c为例。所述配置终端2000可接收这三个用户终端分别发送的加载请求，即所述配置终端2000可接收用户终端3000a发送的加载请求a，接收用户终端3000b发送的加载请求b，接收用户终端3000c发送的加载请求c。随后，所述配置终端2000可以根据加载请求a，加载请求b以及加载请求c从图1所示的服务终端4000中拉取与各加载请求对应的配置文件，比如，所述配置终端2000可以拉取与加载请求a对应的配置文件1和配置文件2，且所述配置文件2与所述配置文件1之间存在映射关系，即配置文件1中的数据不同于配置文件2中的数据并将各配置文件。同理，所述配置终端2000也可以拉取与加载请求b对应的配置文件3和配置文件4，且所述配置文件4与所述配置文件3之间存在映射关系，即配置文件3中的数据不同于配置文件4中的数据。同理，所述配置终端2000还可以拉取与加载请求c对应的配置文件5和配置文件6，且所述配置文件6与所述配置文件5之间存在映射关系，即配置文件5中的数据不同于配置文件6中的数据。随后，所述配置终端2000可将配置文件1中的数据与配置文件2中的数据进行融合，得到与加载请求a对应的目标配置信息。此外，所述配置终端2000还可将配置文件3中的数据与配置文件4中的数据进行融合，以得到与加载请求b对应的目标配置信息；以及将配置文件5中的数据与配置文件6中的数据进行融合，以得到与加载请求c对应的目标配置信息。因此，所述用户终端3000a，用户终端3000b和用户终端3000c可将与各自加载请求对应的目标配置信息加载至本地，以完成对各自终端中相应的应用程序的启动。

其中，配置文件1和配置文件3以及配置文件5可以为与各加载请求对应的第一类配置文件，配置文件2和配置文件4以及配置文件6可以为与各第一类配置文件分别对应的第二类配置文件。

其中，所述配置终端2000获取所述第一类配置文件和所述第二类配置文件，以及得到所述目标配置信息的具体过程可以参见如下图2至图4对应的实施例。

请参见图2，是本发明实施例提供的一种配置数据处理方法的流程示意图。如图2所示，所述方法至少包括：

步骤S101，获取与目标配置信息对应的加载请求；

具体的，配置终端可接收目标终端发送的加载请求，所述加载请求中携带与目标配置信息相关的配置关键字，所述配置关键字可以包括用于访问该配置终端中的配置界面的地址(即该地址可为各目标终端提供访问该配置终端的入口)，此外，该配置关键字还可以包括配置规则中的配置参数(比如，项目编码)，以便于该配置终端基于该配置参数进一步查找与所述目标配置信息相关的多个配置文件，因此，所述配置终端通过该配置关键字可从服务终端(例如，本地服务器)中获取与所述目标配置信息关联的多个携带不同数据内容的配置文件，以对该配置终端中同一项目所对应的应用程序下的各配置文件进行分目录管理。

其中，所述配置终端可为上述图1所对应实施例中的配置终端2000；所述目标终端可为上述图1所对应实施例中的用户终端3000a。应当理解，所述目标终端还可以为上述图1所对应实施例中的其他用户终端，因此，这里将不对所述目标终端的具体存在形式进行限定。

其中，所述目标配置信息为将具有映射关系的多个配置文件中的数据进行融合后所得的配置信息，应当理解，此时，这些具有映射关系的多个配置文件分别携带不同的数据内容，即第一类配置文件中的数据内容不同于第二类配置文件中的数据内容。比如，对于应用程序A而言，与该应用程序A所对应的多个实例(比如，实例1，实例2和实例3)的待配置文件会被全部提取到与该配置终端，并通过该配置终端将各待配置文件中的数据内容进行划分，以得到与该应用程序A对应的私有配置文件和公有配置文件(即项目公共配置文件和服务公共配置文件)，并分别将该私有配置文件和公有配置文件分别存储在与该配置终端具有数据连接关系的服务终端中，以对该应用程序A所对应的各配置文件进行集中管理，以便于进行统一维护，即此时，在分别部署有实例1和实例2以及实例3的各用户终端(即各机器)上将不存在有多个待配置文件。因此，当各用户终端中的某个用户终端(即目标终端)需要加载相应实例对应的配置信息时，需通过该配置终端从服务终端中获取响应的目标配置信息(即融合后所得的配置信息)。

其中，所述配置关键字可用于在该配置终端的配置界面中进一步查找与所述目标配置信息相关的多个配置文件，即所述配置关键字可以和这些配置文件之间存在预设的包依赖关系，即通过该配置关键字可对应的找到这些配置文件所存储的文件路径。比如，对于分目录管理的第一类配置文件和第二类配置文件而言，可先找到第一类配置文件的文件路径，再找到第二类配置文件的文件路径，以便于进一步执行步骤S102。

其中，各配置文件是由所述配置终端，对同一项目下运行在不同机器上的多个实例的待配置文件中的数据进行分离而形成的文件，且各待配置文件中的数据均按照预设的配置规则进行设置，即按照项目编码、配置环境、版本号、服务名称和实例名等配置参数行设置，因此，为避免数据冗余，可对各待配置文件中的相同数据内容进行提取和分离，以得到具有不同映射关系的多个配置文件。所以，所述配置终端可以通过该配置关键字(即应用项目编码、应用配置环境、应用服务版本号、应用服务名称和应用服务实例名等信息)，查找到与该配置关键字具有关联关系的某个实例的目标融合信息。

例如，对于网上商城项目而言，该网上商城项目(项目编码：mall)可以由两个应用程序(服务)组成，即支付服务(服务名称：pay)和订单服务(服务名称：order)，此时，这两个服务下部署有两个实例(这两个实例分别对应着不同数据内容的私有配置文件)。比如，以支付服务对应着实例1(实例名：instance01)和实例2(实例名：instance02)为例，实例1和实例2在开发环境(dev)和版本(0.0.1)时，分别对应的配置文件的文件名可以为：

mall-dev-0.0.1-pay-instance01.properties；

mall-dev-0.0.1-pay-instance02.properties；

可见，这两个私有配置文件的文件名具有唯一性，故而可通过配置关键字查找到与各实例相关联的多个配置文件，从而可得到各实例启动时所需的目标配置信息。

因此，配置人员可在访问目标项目时，通过所述配置终端对具有相同项目编码的不同待配置文件中的数据进行分离，即所述配置终端可根据该预设的配置规则，预先将具有相同服务配置信息的待配置文件添加至同一服务配置集合，并在每个服务配置集合中，从各待配置文件中分离出具有相同服务配置信息的数据作为服务配置信息。紧接着，所述配置终端可从各服务配置信息中分离出相同的项目配置信息，并创建与所述项目配置信息对应的项目公共配置文件，并创建与分离后的服务配置信息对应的服务公共配置文件，最后，将分离后的各待配置文件中所剩余的数据作为私有配置信息，创建对应的私有配置文件。

其中，将各待配置文件中的数据内容进行拆分后的各配置文件的分布可参见下述图3所对应实施例中的对各配置文件的分布架构的描述。

其中，在一个服务配置集合中，可以包括一个服务公共配置文件与至少一个与所述服务公共配置文件具有映射关系的私有配置文件。此外，所述一个项目公共配置文件可与至少一个服务公共配置文件具有映射关系。

其中，一个应用程序可以对应至少一个业务系统，且每个业务系统可对应一个项目，且各项目下可有多个待配置文件(例如，多个携带相同配置数据，且运行在不同机器上的进程文件)。因此，可选的，所述配置终端还可在同一时间接收多个用户终端(即不同机器)分别发送的加载请求，并根据各加载请求进一步执行步骤S102-步骤S103；可选的，所述配置终端还可以接收各用户终端在不同时间所发送的加载请求，并按照接收时间的先后顺序依次执行步骤S102-步骤S103。

为便于更好的理解本方案，本发明实施例仅以该配置终端启动一个进程(即一个实例)所需的目标配置信息为例，即该配置终端可用于获取与所述目标配置信息的加载请求，并可根据所述加载请求执行步骤S102-步骤S103，以得到与该进程对应的目标配置信息。当然，当存在与多个进程分别对应的加载请求时，可参考本发明实施例中的对获取所述目标配置信息的具体过程描述。因此，在本发明实施例中，将不对该配置终端对应的进程的数量进行限制。

步骤S102，获取与所述加载请求对应的第一类配置文件，并获取与所述第一类配置文件具有映射关系的第二类配置文件；

其中，所述第二类配置文件与多个第一类配置文件具有映射关系；

若所述第一类配置文件为私有配置文件，则所述配置终端可获取与所述私有配置文件具有映射关系的所述服务公共配置文件，并进一步获取与所述服务公共配置文件具有映射关系的所述项目公共配置文件，即此时，所述第二类配置文件将包含服务公共配置文件和项目公共配置文件。

其中，所述私有配置文件可根据上述步骤S101中预设的配置规则进行命名，即所述配置终端可根据项目编码+配置环境+版本号+服务名称+实例名等信息对所述私有配置文件进行命名，并根据该配置规则动态的生成存储该私有配置文件的文件路径。

其中，所述服务公共配置文件可根据上述步骤S101中的配置规则进行命名，即所述配置终端可根据项目编码+配置环境+版本号+服务名称等信息对所述服务公共配置文件进行命名，并根据该配置规则动态的生成存储该服务公共配置文件的文件路径。

其中，所述项目公共配置文件可根据上述步骤S101中的配置规则进行命名，即所述配置终端可根据项目编码+配置环境+版本号等信息对所述项目公共配置文件进行命名，并根据该配置规则动态的生成存储该项目公共配置文件的文件路径。

进一步的，请参见图3，是本发明实施例提供的一种各配置文件的分布架构图。比如，在一个项目A下同时存在4个实例(实例C1、实例C2、实例C3和实例C4)所对应的待配置文件，这4个待配置文件分别部署在4台机器上，为便于对这些待配置文件中的数据进行集中管理，可以对这4待配置文件中数据内容进行提取，并在对数据内调进行提取之后，这4台机器的本地服务器上将不存在与各实例对应的待配置文件，此时，当某个实例需要启动时，需要通过配置终端从服务终端中找到与该实例相关联的第一类配置文件和第二类配置文件。因此，如图3所示，所述箭头方向代表所述配置终端可对各待配置文件中数据内容进行提取后的数据流向。可见，在该项目A下，可同时存在两个不同的微服务(比如，服务B1和服务B2)，且服务B1下部署有两个携带不同数据内容的实例(比如，实例C1和实例C2)，此外，服务B2下部署有两个携带不同数据内容的实例(比如，实例C3和实例C4)。其中，实例C1、实例C2、实例C3和实例C4对应的配置文件为私有配置文件，服务B1和服务B2对应的配置文件为服务公共配置文件，项目A对应的配置文件为项目公共配置文件。此时，若所述加载请求为实例C1启动时的配置获取请求，则所述配置终端将加载C1对应的私有配置文件，并加载与该私有配置文件具有映射关系的服务B1所对应的服务公共配置文件，并加载与该服务公共配置文件具有映射关系的项目A所对应的项目公共配置文件。

同理，在该一个项目A下的其他实例启动时，也可对应的加载其自身对应的私有配置文件，并再加载与该私有配置文件具有映射关系的服务公共配置文件，以及与该服务公共配置文件具有映射关系的项目公共配置文件。即是有配置文件的加载等级高于服务公共配置文件的加载等级，且所述服务公共配置文件的加载等级高于所述项目公共配置文件的加载等级。

可选的，若所述第一类配置文件为所述服务公共配置文件，则获取与所述服务公共配置文件具有映射关系的所述项目公共配置文件。此时，所第二类配置文件为与该服务公共配置文件具有映射关系的项目公共配置文件。

因此，仍以上述项目A为例，若所述加载请求为服务B1启动时的配置获取请求，则所述配置终端将首先加载B1对应的服务公共配置文件，再进一步加载与该服务公共配置文件具有映射关系的项目A所对应的项目公共配置文件。当然，若所述加载请求为服务B2启动时的配置获取请求，则所述配置终端可以首先加载B2对应的服务公共配置文件，再加载与该服务公共配置文件具有映射关系的项目A所对应的项目公共配置文件。即此时，服务B1和服务B2分别对应的服务公共配置文件的加载等级高于项目A对应的项目配置文件的加载等级。

步骤S103，将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

具体的，所述配置终端在执行完步骤S102之后，可进一步将获取到的所述第一类配置文件中的数据与获取到的所述第二类配置文件中的数据进行融合，以得到融合处理后的目标配置信息，并将融合处理后的所述目标配置信息作为与所述加载请求对应的响应信息，并将该响应信息返回至用户终端。

其中，所述目标配置信息与所述加载请求之间具有一一对应关系，因此，所述配置终端可在所述用户终端中的应用程序在启动时，接收该用户终端发送的加载请求，并根据该加载请求中所携带的配置关键字进一步查找与所述目标配置信息关联的多个配置文件，以得到融合处理后的目标配置信息，进而可将该融合处理后的目标配置信息返回至该用户终端，以完成对该应用程序的启动。

本发明实施例通过获取与目标配置信息对应的加载请求；获取与所述加载请求对应的第一类配置文件，并获取与所述第一类配置文件具有映射关系的第二类配置文件；所述第二类配置文件与多个第一类配置文件具有映射关系；将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。由此可见，本发明在接收到加载请求时，可首先获取与所述加载请求对应的第一类配置文件，以得到所述第一类配置文件中的数据，然后，还可进一步获取与所述第一类配置文件具有映射关系的第二类配置文件，以得到所述第二类配置文件中的数据，进而可以动态的将各配置文件中的不同数据进行融合，以得到与所述加载请求对应的目标配置信息，从而实现对各配置文件的集中管理。此外，通过对配置文件进行分类，可以确保每个不同配置文件中的数据互不相同，以避免配置文件中数据的冗余。

进一步的，请参见图4，是本发明实施例提供的另一种配置数据处理方法的流程示意图。如图4所示，所述方法至少包括：

步骤S201，接收登录请求，并根据所述登录请求中所携带的目标用户信息，访问目标项目；

具体的，配置终端可接收项目配置人员在Web界面录入的目标用户信息，并生成携带所述目标用户信息的登录请求，以使后台服务器根据该登录请求将所述目标用户信息与预设用户信息进行匹配。当在匹配成功时，所述配置终端可访问与所述目标用户信息对应的目标项目。

其中，所述Web界面可以为上述图1所对应实施例中的Web终端2000a中的配置界面。

其中，所述后台服务器可以为上述图1所对应实施例中的配置中心2000a的本地服务器。

其中，一个目标用户信息可用于访问一个业务系统中的一个项目(即目标项目)。比如，用户信息A可用于访问与支付系统对应着支付项目，用户信息B可用于访问与审批系统对应着审批项目，用户信息C可用于访问与放款系统对应着放款项目，可见，通过给这些不同的项目分配不同的用户信息，可使这些项目之间彼此相互隔离。因此，项目配置人员若要访问某个目标项目，需在该配置终端的Web界面上录入与该目标项目对应的目标用户信息(比如，录入用户信息A中的登录账号和登录密码等信息)。因此，所述配置终端在执行步骤S201之前，还需预先为这些项目中的每个项目和与各项目对应的用户信息创建相应的访问关系，以根据各访问关系将多个不同项目进行权限隔离。

步骤S202，获取与所述目标项目对应的多个待配置文件，并根据预设的配置规则，将具有相同服务配置信息的待配置文件添加至同一服务配置集合；

其中，所述多个待配置文件分别运行在多个机器上，且这些待配置文件中大多携带有相同的服务配置信息和项目配置信息，因此，当一个应用程序启动时，可同时加载这些待配置文件，但是，为了对各待配置文件进行集中管理，可将这些待配置文件中的相同服务配置信息提取出来，其中，对各待配置文件中所述相同服务配置信息的提取是由各待配置文件中配置信息的配置规则所决定的，因此，所述配置终端可将同一项目下携带相同的服务配置信息和项目配置信息的待配置文件添加至同一服务配置集合，以便于该配置终端能对这些具有相同服务配置信息的待配置文件中的数据进行分类管理，从而避免数据的冗余。

其中，各待配置文件中的数据均按照项目编码、配置环境、版本号、服务名称和实例名等规则进行添加。因此，所述配置终端可以对各待配置文件进行拆分，以便于后续对拆分后所得到的各配置文件进行分目录管理，即对于一个待配置文件而言，在将该待配置文件中的数据内容进行拆分后，可为具有映射关系的各配置文件和配置关键字之间设置相应的包依赖关系，即所述配置终端可根据该配置关键字可进一步获取拆分后所得的各配置文件，即通过与配置关键字具有包依赖关系的各配置文件的文件路径可加载得到相应的配置文件。

比如，在一个业务系统中的项目B下，所述配置终端可获取与该项目对应的4个待配置文件(待配置文件X1，待配置文件X2，待配置文件X3和待配置文件X4，且这四个待配置文件分别运行在4个不同的用户终端(机器)上)。此时，所述配置终端可将具有相同服务配置信息的待配置文件添加至同一服务配置集合，例如，将待配置文件X1和待配置文件X2添加至服务配置集合A1，将待配置文件X3和待配置文件X4添加至服务配置集合A2，以便于进一步执行步骤S203。

步骤S203，在每个服务配置集合中，从各待配置文件中分离出相同的服务配置信息；

具体的，所述配置终端可根据预设的配置规则对每个服务配置集合中的待配置文件中的数据内容进行拆分，以从各待配置文件中分离出相同的服务配置信息，以便于进一步执行步骤S204和步骤S205，生成包含不同数据的配置文件。其中，私有配置文件的文件名可以根据预设的配置规则中的项目编码、配置环境、版本号、服务名称和实例名等格式自动进行生成；服务公共配置文件的文件名可以根据项目编码、配置环境、版本号、服务名称等格式自动进行生成；项目公共配置文件的文件名可以根据项目编码、配置环境、版本号等格式自动进行生成。

比如，在开发环境下，上述步骤S202所得的服务配置集合A1中存在具有相同服务配置信息的待配置文件X1和待配置文件X2。其中，待配置文件X1中的数据可以表示为：项目B+服务C1+实例1，待配置文件X2中的数据可以表示为：项目B+服务C1+实例D2，此时，待配置文件X1和待配置文件X2中相同的服务配置信息为：项目B+服务C1，因此，所述配置终端可对待配置文件X1，待配置文件X2中的相同数据进行分离。

其中，待配置文件X3中的数据可以表示为：项目B+服务C2+实例D3，待配置文件X4中的数据可以表示为：项目B+服务C2+实例D4，此时，待配置文件X3和待配置文件X4中相同的服务配置信息为：项目B+服务C2，因此，所述配置终端可对待配置文件X3，待配置文件X4中的相同数据进行分离。

可选的，所述配置终端在执行完步骤S201之后，还可获取与所述目标项目对应的多个待配置文件，并根据预设的配置规则，直接从各待配置文件中分离出相同的服务配置信息，并得到分离后的各待配置文件中所剩余的私有配置信息，以便于进一步执行步骤S204。

步骤S204，从各服务配置信息中分离出相同的项目配置信息，并创建与所述项目配置信息对应的项目公共配置文件；

在执行完上述步骤S203之后，所述配置终端可进一步从各服务配置信息中分离出相同的项目配置信息，即所述配置终端可从服务配置信息为项目B+服务C2和服务配置信息为项目B+服务C1的配置信息中分离出相同的项目配置信息(即数据内容为:项目B)，并创建该项目配置信息对应的项目公共配置文件，例如，projectB-dev-1.0.0.properties。

步骤S205，创建与分离后的服务配置信息对应的服务公共配置文件，并为分离后的各待配置文件中所剩余的私有配置信息，创建对应的私有配置文件；

在执行完步骤S204之后，所述配置终端可进一步为分离后的服务配置信息(即服务C1和服务C2)创建服务公共配置文件。例如，与服务C1对应的服务公共配置文件为projectB-dev-1.0.0-serviceC1.properties，与服务C2对应的服务公共配置文件为projectB-dev-1.0.0-serviceC2.properties。

与此同时，所述配置终端还可为分离后的各待配置文件中所剩余的私有配置信息(即实例D1，实例D2，实例D3和实例D4)创建对应的私有配置文件。例如，与实例D1对应的私有配置文件为：

projectB-dev-1.0.0-serviceC1-instanceD1.properties；

与实例D2对应的私有配置文件为：

projectB-dev-1.0.0-serviceC1-instanceD2.properties；

与实例D3对应的私有配置文件为：

projectB-dev-1.0.0-serviceC2-instanceD3.properties；

与实例D4对应的私有配置文件为：

projectB-dev-1.0.0-serviceC2-instanceD4properties。

步骤S206，为各服务公共配置文件分别创建与所述项目配置文件之间的映射关系，并为各私有配置文件分别创建与所述服务公共配置文件之间的映射关系；一个服务配置集合中，包括一个服务公共配置文件与至少一个与所述服务公共配置文件具有映射关系的私有配置文件。

其中，所述配置终端通过给各服务公共配置文件创建与所述项目配置文件之间的映射关系，可以在某个服务公共配置文件所对应的服务数据(即微服务的进程数据)需要被加载时，可对应的加载该微服务对应的服务公共配置文件和项目公共配置文件。此外，在一个服务配置集合中，所述配置终端通过为各私有配置文件分别创建与所述服务公共配置文件之间的映射关系，可以在某个实例(进程)启动时，对应的加载与该实例对应的私有配置文件和与该私有配置文件具有映射关系的服务公共配置文件，以及与该服务公共配置文件具有映射关系的项目公共配置文件。

比如，仍以上述开发环境下的项目B为例，在服务配置集合A1中，与服务公共配置文件(projectB-dev-1.0.0-serviceC1.properties)具有映射关系的私有配置文件有两个，分别为：projectB-dev-1.0.0-serviceC1-instanceD1.properties；projectB-dev-1.0.0-serviceC1-instanceD2.properties；

在服务配置集合A2中，与服务公共配置文件(projectB-dev-1.0.0-serviceC2.properties)具有映射关系的私有配置文件也有两个，这两个私有配置文件分别为：

projectB-dev-1.0.0-serviceC2-instanceD3.properties；

projectB-dev-1.0.0-serviceC2-instanceD4.properties。

步骤S207，获取与目标配置信息对应的加载请求；

步骤S208，获取与所述加载请求对应的第一类配置文件；

步骤S209，若所述第一类配置文件为所述服务公共配置文件，则获取与所述服务公共配置文件具有映射关系的项目公共配置文件；

步骤S210，将获取到的所述服务公共配置文件与获取到的所述项目公共配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

其中，所述步骤S207-步骤S210的具体实现方式可参见上述图2所对应实施例中对步骤S101-步骤S103的描述，这里不再赘述。

可选的，在执行完步骤S208之后，所述配置终端还可进一步执行步骤S211，即若所述第一类配置文件为私有配置文件，则获取与所述私有配置文件具有映射关系的服务公共配置文件，并进一步获取与所述服务公共配置文件具有映射关系的项目公共配置文件；

此时，获取各配置文件(私有配置文件，服务公共配置文件和项目公共配置文件)的具体过程可参见上述图2所对应实施例中对步骤S102的描述，这里不再赘述。

步骤S212，将获取到的所述私有配置文件中、获取到的所述服务公共配置文件以及获取到的所述项目公共配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

可见，在步骤S212中，所述目标终端中的实例所对应的待配置文件，在提取到配置终端之后，被进行了三级划分，即被划分为携带不同数据内容的私有配置文件、服务公共配置文件以及项目公共配置文件。于是，采用这种方法，可以将该目标终端(例如，用户终端A)中应用程序的实例(例如，实例1)和该实例所对应的待配置文件进行分离，以便于后期测试人员可以通过配置终端对多个用户终端中的待配置文件进行集中管理。此时，用户终端A中的应用程序的实例在启动的，将不再从本地加载待配置文件，而是，通过与该用户终端A具有数据连接关系(网络连接关系)的配置终端来获取与该实例1对应的目标配置信息。因此，当每个用户终端中的实例分别需要获取相应的目标配置信息时，可以向该配置终端发送携带配置关键字(此时，该配置关键字可以理解为与)的加载请求，并根据该配置关键字查找与各实例具有关联关系的各配置文件，以得到与各实例分别对应的目标配置信息。

其中，所述步骤S212的具体实现方式可参见上述图2所对应实施例中对步骤S103的描述，这里不再赘述。

可选的，所述配置终端还用于监控系统信息参数或应用信息参数是否发生变化，若所述系统信息参数或所述应用信息参数发生变化，则获取与所述系统信息参数或所述应用信息参数关联的目标配置文件，并根据变化后的系统信息参数或所述应用信息参数，更新所述目标配置文件；

其中，所述目标配置文件为私有配置文件，服务公共配置文件、项目公共配置文件中的至少一种配置文件；

其中，所述系统信息参数指项目环境信息，该项目环境信息可以为开发环境、测试环境和运维环境等环境信息；所述应用信息参数指用户终端中的应用程序的版本信息。

比如，仍以上述开发环境下的项目B为例，当所述配置终端检测到该项目B由开发环境迁移至生产环境(即系统信息参数发生变化)时，所述配置终端可获取与该开发环境关联的目标配置文件(即项目B对应的项目公共配置文件)。随后，所述配置终端将根据预设的配置规则自动将开发环境下的项目公共配置文件projectB-dev-1.0.0.properties修改为生产环境下的项目公共配置文件：projectB-product-1.0.0.properties。此时，与该项目公共配置文件具有映射关系的其他配置文件的文件名，以及其中的数据可以自动进行修改，而无需到每台机器中重复对每个待配置文件中的数据内容进行修改，以实现对各配置文件的集中管理。可选的，测试人员也可以手动在配置文件被创建时，即将开发环境下项目B的配置文件复制到生产环境下，然后手动对该复制后的配置文件中的数据内容按照预设的配置规则(或配置关键字)进行手动编辑，比如，可以手动将开发环境下的该项目B下的某个实例对应的私有配置文件中的IP地址A修改为生产环境下的IP地址B，以对该生产环境下项目B的目标配置文件中的配置信息进行更新。从而在所述配置终端获取到与目标配置信息对应的加载请求时，可以得到与该加载请求对应的更新后的目标配置信息。

本发明实施例通过获取与目标配置信息对应的加载请求；获取与所述加载请求对应的第一类配置文件，并获取与所述第一类配置文件具有映射关系的第二类配置文件；所述第二类配置文件与多个第一类配置文件具有映射关系；将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。由此可见，本发明在接收到加载请求时，可首先获取与所述加载请求对应的第一类配置文件，以得到所述第一类配置文件中的数据，然后，还可进一步获取与所述第一类配置文件具有映射关系的第二类配置文件，以得到所述第二类配置文件中的数据，进而可以动态的将各配置文件中的不同数据进行融合，以得到与所述加载请求对应的目标配置信息，从而实现对各配置文件的集中管理。此外，通过对配置文件进行分类，可以确保每个不同配置文件中的数据互不相同，以避免配置文件中数据的冗余。

进一步的，请参见图5，是本发明实施例提供的一种配置数据处理装置的结构示意图，如图5所示，所述配置数据处理装置1可以为上述图1所对应实施例中的配置终端2000，所述配置数据处理装置1可以包括加载请求获取模块10，第一获取模块20，第二获取模块30和配置信息返回模块40，进一步的，所述配置数据处理装置1还可以包括目标项目访问模块50，配置文件添加模块60，服务分离模块70，项目分离模块80，第一创建模块90，第二创建模块100，参数监控模块110，目标文件获取模块120和文件更新模块130；

所述加载请求获取模块10，用于获取与目标配置信息对应的加载请求；

所述第一获取模块20，用于获取与所述加载请求对应的第一类配置文件；

所述第二获取模块30，用于获取与所述第一类配置文件具有映射关系的第二类配置文件；所述第二类配置文件与多个第一类配置文件具有映射关系；

所述配置信息返回模块40，用于将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

其中，所述加载请求获取模块10，第一获取模块20，第二获取模块30和配置信息返回模块40的具体实现方式可参见上述图2所对应实施例中对步骤S101-步骤S103的描述，这里不再赘述。

所述目标项目访问模块50，用于接收登录请求，并根据所述登录请求中所携带的目标用户信息，访问目标项目；

所述配置文件添加模块60，用于获取与所述目标项目对应的多个待配置文件，并根据预设的配置规则，将具有相同服务配置信息的待配置文件添加至同一服务配置集合；

所述服务分离模块70，用于在每个服务配置集合中，从各待配置文件中分离出相同的服务配置信息；

所述项目分离模块80，用于从各服务配置信息中分离出相同的项目配置信息，并创建与所述项目配置信息对应的项目公共配置文件；

所述第一创建模块90，用于创建与分离后的服务配置信息对应的服务公共配置文件，并为分离后的各待配置文件中所剩余的私有配置信息，创建对应的私有配置文件；

所述第二创建模块100，用于为各服务公共配置文件分别创建与所述项目配置文件之间的映射关系，并为各私有配置文件分别创建与所述服务公共配置文件之间的映射关系；一个服务配置集合中，包括一个服务公共配置文件与至少一个与所述服务公共配置文件具有映射关系的私有配置文件。

其中，所述目标项目访问模块50，配置文件添加模块60，服务分离模块70，项目分离模块80，第一创建模块90，第二创建模块100的具体实现方式可参见上述图4所对应实施例中对步骤S201-步骤S206的描述，这里不再赘述。

所述参数监控模块110，用于监控系统信息参数是否发生变化；

所述目标文件获取模块120，用于若所述系统信息参数发生变化，则获取与所述系统信息参数关联的目标配置文件；其中，所述目标配置文件为所述私有配置文件，所述服务公共配置文件、所述项目公共配置文件中的至少一种配置文件；

所述文件更新模块130，用于根据变化后的系统信息参数或所述应用信息参数，更新所述目标配置文件。

其中，所述参数监控模块110，目标文件获取模块120和文件更新模块130的具体实现方式可参见上述图4所对应实施例中对变后的系统信息参数的描述，这里不再赘述。

本发明实施例通过获取与目标配置信息对应的加载请求；获取与所述加载请求对应的第一类配置文件，并获取与所述第一类配置文件具有映射关系的第二类配置文件；所述第二类配置文件与多个第一类配置文件具有映射关系；将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。由此可见，本发明在接收到加载请求时，可首先获取与所述加载请求对应的第一类配置文件，以得到所述第一类配置文件中的数据，然后，还可进一步获取与所述第一类配置文件具有映射关系的第二类配置文件，以得到所述第二类配置文件中的数据，进而可以动态的将各配置文件中的不同数据进行融合，以得到与所述加载请求对应的目标配置信息，从而实现对各配置文件的集中管理。此外，通过对配置文件进行分类，可以确保每个不同配置文件中的数据互不相同，以避免配置文件中数据的冗余。

进一步地，请参见图6，是本发明实施例提供的另一种配置数据处理装置的结构示意图。如图6所示，所述配置数据处理装置1000可以应用于上述图1对应实施例中的配置终端2000，所述配置数据处理装置1000可以包括：处理器1001，网络接口1004和存储器1005，此外，所述配置数据处理装置1000还可以包括：用户接口1003，和至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。其中，用户接口1003可以包括显示屏(Display)、键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1004可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器1004可选的还可以是至少一个位于远离前述处理器1001的存储装置。如图6所示，作为一种计算机存储介质的存储器1004中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。

在图6所示的配置数据处理装置1000中，网络接口1004可提供网络通讯功能；而用户接口1003主要用于为用户提供输入的接口，即接收当前用户输入的待测试信息；而处理器1001可以用于调用存储器1004中存储的设备控制应用程序，以实现：

获取与目标配置信息对应的加载请求；

获取与所述加载请求对应的第一类配置文件，并获取与所述第一类配置文件具有映射关系的第二类配置文件；所述第二类配置文件与多个第一类配置文件具有映射关系；

将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

应当理解，本发明实施例中所描述的配置数据处理装置1000可执行前文图1或图4所对应实施例中对所述配置数据处理方法的描述，也可执行前文图5所对应实施例中对所述配置数据处理装置1的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

此外，这里需要指出的是：本发明实施例还提供了一种计算机存储介质，且所述计算机存储介质中存储有前文提及的配置数据处理装置1所执行的计算机程序，且所述计算机程序包括程序指令，当所述处理器执行所述程序指令时，能够执行前文图1或图4所对应实施例中对所述配置数据处理方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本发明所涉及的计算机存储介质实施例中未披露的技术细节，请参照本发明方法实施例的描述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。

以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。

Claims (10)

1.一种配置数据处理方法，其特征在于，包括：

获取与目标配置信息对应的加载请求；

获取与所述加载请求对应的第一类配置文件，并获取与所述第一类配置文件具有映射关系的第二类配置文件；所述第二类配置文件与多个第一类配置文件具有映射关系；

将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

2.根据权利要求1所述的方法，其特征在于，还包括：

接收登录请求，并根据所述登录请求中所携带的目标用户信息，访问目标项目；

获取与所述目标项目对应的多个待配置文件，并根据预设的配置规则，将具有相同服务配置信息的待配置文件添加至同一服务配置集合；

在每个服务配置集合中，从各待配置文件中分离出相同的服务配置信息；

从各服务配置信息中分离出相同的项目配置信息，并创建与所述项目配置信息对应的项目公共配置文件；

创建与分离后的服务配置信息对应的服务公共配置文件，并为分离后的各待配置文件中所剩余的私有配置信息，创建对应的私有配置文件；

为各服务公共配置文件分别创建与所述项目配置文件之间的映射关系，并为各私有配置文件分别创建与所述服务公共配置文件之间的映射关系；一个服务配置集合中，包括一个服务公共配置文件与至少一个与所述服务公共配置文件具有映射关系的私有配置文件。

3.根据权利要求2所述的方法，其特征在于，所述获取与所述第一类配置文件具有映射关系的第二类配置文件，包括：

若所述第一类配置文件为所述服务公共配置文件，则获取与所述服务公共配置文件具有映射关系的所述项目公共配置文件；

则所述将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息，包括：

将获取到的所述服务公共配置文件与获取到的所述项目公共配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

4.根据权利要求2所述的方法，其特征在于，所述获取与所述第一类配置文件具有映射关系的第二类配置文件，包括：

若所述第一类配置文件为所述私有配置文件，则获取与所述私有配置文件具有映射关系的所述服务公共配置文件，并进一步获取与所述服务公共配置文件具有映射关系的所述项目公共配置文件；

则所述将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息，包括：

将获取到的所述私有配置文件中、获取到的所述服务公共配置文件以及获取到的所述项目公共配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

5.根据权利要求2所述的方法，其特征在于，还包括：

监控系统信息参数或应用信息参数是否发生变化；

若所述系统信息参数或所述应用信息参数发生变化，则获取与所述系统信息参数或所述应用信息参数关联的目标配置文件；其中，所述目标配置文件为所述私有配置文件，所述服务公共配置文件、所述项目公共配置文件中的至少一种配置文件；

根据变化后的系统信息参数或所述应用信息参数，更新所述目标配置文件。

6.一种配置数据处理装置，其特征在于，包括：

加载请求获取模块，用于获取与目标配置信息对应的加载请求；

第一获取模块，用于获取与所述加载请求对应的第一类配置文件；

第二获取模块，用于获取与所述第一类配置文件具有映射关系的第二类配置文件；所述第二类配置文件与多个第一类配置文件具有映射关系；

配置信息返回模块，用于将获取到的所述第一类配置文件与获取到的所述第二类配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息。

7.根据权利要求6所述的装置，其特征在于，还包括：

目标项目访问模块，用于接收登录请求，并根据所述登录请求中所携带的目标用户信息，访问目标项目；

配置文件添加模块，用于获取与所述目标项目对应的多个待配置文件，并根据预设的配置规则，将具有相同服务配置信息的待配置文件添加至同一服务配置集合；

服务分离模块，用于在每个服务配置集合中，从各待配置文件中分离出相同的服务配置信息；

项目分离模块，用于从各服务配置信息中分离出相同的项目配置信息，并创建与所述项目配置信息对应的项目公共配置文件；

第一创建模块，用于创建与分离后的服务配置信息对应的服务公共配置文件，并为分离后的各待配置文件中所剩余的私有配置信息，创建对应的私有配置文件；

第二创建模块，用于为各服务公共配置文件分别创建与所述项目配置文件之间的映射关系，并为各私有配置文件分别创建与所述服务公共配置文件之间的映射关系；一个服务配置集合中，包括一个服务公共配置文件与至少一个与所述服务公共配置文件具有映射关系的私有配置文件。

8.根据权利要求7所述的装置，其特征在于，

所述第二获取模块，具体用于若所述第一类配置文件为所述服务公共配置文件，则获取与所述服务公共配置文件具有映射关系的所述项目公共配置文件；

则所述配置信息返回模块，具体用于将获取到的所述服务公共配置文件与获取到的所述项目公共配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息至用户终端。

9.根据权利要求7所述的装置，其特征在于，

所述第二获取模块，具体用于若所述第一类配置文件为所述私有配置文件，则获取与所述私有配置文件具有映射关系的所述服务公共配置文件，并进一步获取与所述服务公共配置文件具有映射关系的所述项目公共配置文件；

则所述配置信息返回模块，具体用于将获取到的所述私有配置文件中、获取到的所述服务公共配置文件以及获取到的所述项目公共配置文件进行融合，得到与所述加载请求对应的目标配置信息，并返回所述目标配置信息至用户终端。

10.一种配置数据处理装置，其特征在于，包括：处理器、存储器、网络接口；

所述处理器分别与网络接口、存储器相连，其中，所述网络接口用于提供网络通讯功能，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，以执行如权利要求1-5任一项所述的方法。