CN107294750B

CN107294750B - 一种云集群能自识别的分布配置管理方法和装置

Info

Publication number: CN107294750B
Application number: CN201610203220.3A
Authority: CN
Inventors: 许凌; 杨俊华
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2016-04-01
Filing date: 2016-04-01
Publication date: 2020-10-30
Anticipated expiration: 2036-04-01
Also published as: CN107294750A

Abstract

本申请实施例提供了一种配置管理方法和装置，涉及互联网云计算技术领域。所述方法包括：接收配置模板；根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数；以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的第一配置文件。本申请将配置文件的创建所需内容按照运维人员与研发人员分离，运维人员和研发人员的沟通代价大大减少，还可以实现各个服务器管理自身的配置文件，不依赖第三方系统去创建完整的配置文件，配置文件实现了分布式管理，提高了容灾能力，降低了人工参与度，服务器具备自我识别能力，可以自动生成配置文件。

Description

一种云集群能自识别的分布配置管理方法和装置

技术领域

本申请涉及互联网云计算技术领域，特别是涉及一种云集群能自识别的分布配置管理方法和装置。

背景技术

在运维管理中，重要的一个环节是配置文件的管理，尤其在云集群中配置文件定义了各云服务器应该使用什么地方的资源、使用相应功能时能够调用何种服务、从哪儿调用，有什么限制等。配置文件如果出现问题，会对影响系统的稳定性。其中，运维可以理解为运营维护。

在先技术中，运维中对配置文件的管理经历了一系列的发展，其各种方案的配置文件的创建都需要运维人员与研发人员进行大量沟通，创建后再由运维人员将相应的配置文件存储至一个统一的第三方系统中，由运维人员对其进行管理。每次修改都需要研发人员跟运维人员沟通如何对配置文件进行修改，然后让运维人员对配置文件进行维护。

因此，在先技术的运维管理方案中，运维人员与研发人员对配置文件的创建过程耦合度高；配置文件的管理集中在一个第三方系统中，第三方系统如一个单独的配置服务器、svn(Subversion是一个开放源代码的版本控制系统)或者git(Git是一款免费、开源的分布式版本控制系统)、cmdb(Configuration Management Database，配置管理数据库)，导致运维的容灾效果差；配置文件的管理过程人工参与度高，系统的自我识别能力差，配置文件的管理效率低。

发明内容

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种配置管理方法和相应的一种配置管理装置。

为了解决上述问题，本申请公开了一种配置管理方法，包括：

接收配置模板；

根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数；

以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的第一配置文件。

本申请还公开了一种配置管理方法，包括：

模板接收模块，用于接收配置模板；

配置参数获取模块，用于根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数；所述功能配置文件对应的配置参数控制当前服务器需求的各个功能；

配置文件生成模块，用于以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的第一配置文件。

本申请实施例包括以下优点：

本申请实施例，可以将集群的配置文件的创建按运维与开发两方的参与度，分为了由运维人员管理的定位配置文件和功能配置文件、由开发人员管理的资源配置文件和配置模板。该定位配置文件提供了该服务器所处位置的配置参数，功能配置文件提供了指示服务器是否需要某项功能的配置参数，对于每项功能本申请为其设置了相应的资源配置文件，该资源配置文件中提供了各种服务器在所处位置所需求的资源的配置参数；该配置模板以完整的配置文件为基础，将其中与所有变量相关的部分采用锚点进行标记。因此本申请对于配置模板，可以分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数，然后基于获取到的配置参数生成完全状态的第一配置文件。服务器在使用时则可以直接读取该第一配置文件执行相应的功能。

因此，首先：本申请将配置文件的创建所需内容按照运维人员与研发人员分离，运维人员和研发人员的沟通代价大大减少，在定位配置文件和功能配置文件不需要变更的情况下，研发人员甚至不需要和运维人员沟通即可通过更新配置模板实现系统的升级。

其次，本申请可以由集群中的服务器自身实现完全状态的第一配置文件的生成过程，因此，可以实现各个服务器管理自身的配置文件，不依赖第三方系统去创建完整的配置文件，配置文件实现了分布式管理，集群中的一个服务器崩溃，并不影响其他服务器的配置文件的管理，提高了容灾能力。

再次，本申请只需要定位配置文件、功能配置文件和资源配置文件三者分发到该服务器中，就可以根据配置模板自动生成配置文件。因此，本申请的配置文件的生成过程，降低了人工参与度，服务器具备自我识别能力，可以自动生成配置文件。

附图说明

图1是本申请的一种云集群能自识别的分布配置管理方法实施例的步骤流程图；

图2是本申请的另一种云集群能自识别的分布配置管理方法实施例的步骤流程图；

图3是本申请的一种云集群能自识别的分布配置管理装置实施例的结构框图；

图4是本申请的另一种云集群能自识别的分布配置管理装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

本申请实施例的核心构思之一在于，可以将集群的配置文件的创建按运维与开发两方的参与度，分为了由运维人员管理的定位配置文件和功能配置文件、由开发人员管理的资源配置文件和配置模板。该定位配置文件提供了该服务器所处位置的配置参数，功能配置文件提供了指示服务器是否需要某项功能的配置参数，对于每项功能本申请为其设置了相应的资源配置文件，该资源配置文件中提供了各种服务器在所处位置所需求的资源的配置参数；该配置模板以完整的配置文件为基础，将其中与所有变量相关的部分采用锚点进行标记。因此本申请对于配置模板，可以分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数，然后基于获取到的配置参数生成完全状态的第一配置文件。服务器在使用时则可以直接读取该第一配置文件执行相应的功能。由此，可以大大降低运维人员和研发人员的沟通代价；并且集群中的各个服务器自动生成自己的配置文件，可以实现分布式文件管理，从而提高了容灾能力；还降低了管理配置文件的人工参与度，使服务器对配置文件具备了自我识别能力。

实施例一

参照图1，示出了本申请的一种云集群能自识别的分布配置管理方法实施例的步骤流程图，具体可以包括如下步骤：

步骤110，接收配置模板；

本申请接收配置模板的可以为集群中的各台服务器。当然服务器可以从调度服务器接收配置模板，集群研发人员将配置文件发送至调度服务器，然后调度服务器将该配置模板分发至集群中的各台服务器。当然，还可以有其他方式将配置模板发送至集群的各台服务器，本申请不对其加以限制。

需要说明的是，在各台服务器接收配置模板之前还包括：

步骤A1，获取定位配置文件、功能配置文件以及各资源配置文件，并将其存储至指定存储位置。在本申请实施例中，可以对于一个云集群，预先根据该集群的需求配置定位配置文件、功能配置文件，以及为各个云集群设定全局的资源配置文件，每个功能对应一个资源配置文件。然后将上述三个配置文件发送至集群中的各个服务器中。

在本申请实施例中，可以在集群服务器的系统环境初始化时，创建该定位配置文件、功能配置文件，因为定位配置文件、功能配置文件属于该集群的个性化的配置文件，其一般不会变化。然后对于开发人员创建的各种资源配置文件，则分发到各个集群的各服务器中。

然后，本申请实施例的各个服务器则可以进入配置文件自动管理过程，该过程包括步骤110-130。

在本申请实施例中，可以预先统一规范化各功能下各资源的命名，运维人员和研发人员则基于该统一的资源的命名，编辑自己负责的文件。比如对于一个集群，该集群需要的各功能下的资源的资源地址的名称，根据该集群的定位标识命名。比如一个集群的定位标识为“hangzhou”，该集群需求的各功能的资源的资源地址统一根据“hangzhou”命名。进一步的，“hangzhou”集群需要eat功能的“.com”资源，则可以将eat功能下该集群需要的资源的资源地址命名为“hangzhou_eat.com”。

然后将定位配置文件的名称和其中的固定字段、功能配置文件的名称和其中固定字段通知给各方，各方即可独立的编辑自己负责的文件。互相之间不需要再次沟通如何配置，沟通内容少，沟通代价低。

优选的，在本申请另一优选的实施例中步骤110之前，还包括：

步骤100，获取各资源配置文件，以及属于当前云服务器所在集群的定位配置文件、功能配置文件；其中，每个资源配置文件中的各资源地址与各集群的定位配置文件中的定位标识作为关键字段；所述功能配置文件中的功能关键字段采用各资源配置文件的名称。

基于上述规范化的命名，本申请的配置文件可以如下述例子：

(1)定位配置文件

本申请实施例统一定位配置文件的命名，各个集群该配置文件的命名可以相同。比如都用who命名，然后在其中设置关键字段和关键值，关键字段是固定的字段，比如cluster_name，关键值是该服务器所在集群的定位标识，不同集群定位标识不同。然后即可基于上述规定生成配置文件who.config，其配置文件的伪代码示例如下：

其中，who和cluster_name可以根据需要或者说习惯命名，运维和研发侧统一即可。定位配置文件存储集群名称，使多个集群在功能、定位和资源上通过集群名加以区分。

(2)功能配置文件，

本申请实施例统一功能配置文件的命名，各个集群该功能配置文件的命名可以相同。比如都用switch命名，然后在该功能配置文件中对各功能设置多个关键字段以及相应的关键值，其关键字段为功能开关字段，关键值为功能开关标识。如eat功能，其功能开关字段为is_eat，功能开关标识为yes或no，yes表示该服务器可以使用该功能，no表该服务器不能使用该功能。然后即可基于上述规定生成配置文件switch.conf，其配置文件的伪代码示例如下：

上述配置文件中设置了四个功能eat、s leep的功能开关字段，以及相应的功能开关标识。

(3)资源配置文件

本申请实施例统一资源配置文件的命名，资源配置文件是全局的，各个集群的服务器均使用相同的资源配置文件。每个资源配置文件对应一个功能。在实际应用中，基于功能名构建资源配置文件，即可以结合额外字符与功能名组合成资源配置文件的名称，避免字段过少导致名称冲突。比如在功能名前添加统一的功能名前缀“res_”,对于eat功能，其资源配置文件的名称可以为res_eat，其他功能配置文件的名称类似，其结构都为res_*，其中“*”用功能名称替代即可。然后在该功能配置文件中设置多个关键字段和关键值，其关键字段为各个集群的定位标识，关键值为资源地址。其资源地址则可以根据相应集群的定位标识命名，比如一该集群的定位标识为区别量，其他字段使用该资源的固有字符。然后即可基于上述规定生成配置文件res_eat.config，其配置文件的伪代码示例如下：

其中，存在集群“beijing”需要的资源地址“beij ing_eat.com”，和“hangzhou”需要的资源地址“hangzhou:hangzhou_eat.com”。

类似上述例子，对于sleep功能，其配置文件的伪代码示例如下：

如上，每个资源配置文件中的各资源地址与各集群的定位配置文件中的定位标识作为关键字段；上述功能配置文件中的功能关键字段采用各资源配置文件的名称。

可以理解的是，在混合云集群中，上述功能为云集群执行各种操作所需的各种服务，如身份验证服务。其中的资源可以理解为为该集群提供的服务调用位置接口，比如对于身份验证服务来说，资源某个区域的身份验证服务接口。

在本申请实施例中，各服务器获取所在集群自己的定位配置文件、功能配置文件存储在指定位置。同时可以获取所有集群公用的资源配置文件存储在指定位置。

需要说明的是，在本申请实施例中，在接收配置模板后，实际上可以从各配置文件的指定存储位置加载配置文件到内存中，然后执行步骤120。

当然，本申请实施例的服务器在接收到配置模板之后，可以将其导入到预先设置的模板解析引擎中，然后由模板解析引擎去加载上述几个配置文件，然后执行步骤120。

步骤120，根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数；

在本申请实施例中，接收到配置模板之后，可以由预置的模板解析引擎解析该配置模板，解析时，查找配置模板中的锚点，然后根据锚点位置的提取参数，从分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数。

在本申请实施例中，由于前述命名的统一化，因此定位配置文件以及功能配置文件与各资源配置文件实际上是关联的。而配置模板需要的配置参数可以从上述三个配置文件中读取。当然，可以如上述在配置模板中针对需求的各配置文件中的配置参数设置锚点，从而可以读取相应的锚点。

在本申请实施例中，配置模板可以采用.tpl格式文件构建，tpl是template的缩写，是一种文件格式。本申请实施例中，研发人员可以基于完全状态的第一配置文件中的关键字段，将关键字段中需要上述几个配置文件的配置参数的关键值设置锚点，然后即可根据锚点从上述几个配置文件中读取配置参数。

在本申请一优选的实施例中，所述配置模板包括：

各功能的功能开关关键字段、功能名称关键字段、功能资源关键字段；其中，所述定位锚点在功能名称关键字段的关键值中以及资源锚点中，所述功能锚点在所述功能开关字段的关键值中，所述资源锚点在所述功能资源关键字段的关键值中。

锚点是一种迅速定位器一样的标记，通过锚点标识的指向和定位一个新的对象，导入或读取所需要的对象。在本申请中，锚点指向的对象是各配置文件相关的参数。

其中，配置模板的伪代码示例如下：

module.tpl

{

is_eat:${switch:is_eat},

eat_name:${who:cluster_name}_eat,

eat_cpu:1,

eat_res:${res_eat:${who:cluster_name}},

is_sleep:${switch:is_sleep},

sleep_name:${who:cluster_name}_sleep,

sleep_res:${res_sleep:${who:cluster_name}},

sleep_cpu:1,

}

如上，配置模板统一设置了eat功能和sleep功能，其实际的配置文件中药使用这几个功能需要包括相应的关键字段，如is_eat、eat_name、eat_cpu、eat_res、is_sleep、sleep_name、sleep_res、sleep_cpu。其中，is_eat和is_sleep为功能开关字段。其中eat_name、sleep_name为功能名称关键字段。其中，eat_res和sleep_res功能资源关键字段。其中，eat_cpu和sleep_cpu是由研发自己负责规定，与前述配置文件没有关系，而剩余的关键字段的关键值都可以分别从前述三个配置文件中获取。因此可以设置相应的锚点。

在本申请实施例中，锚点分为定位锚点、功能锚点和资源锚点。其中定位锚点在功能名称关键字段的关键值中，如上述例子中定位锚点${who:cluster_name}在功能名称字段eat_name的关键值中和资源锚点${res_eat:${who:cluster_name}}中。功能锚点${switch:is_eat}在功能开关字段is_eat中。资源锚点${res_eat:${who:cluster_name}}在功能资源关键字段eat_res中。

上述示例中$标识的是锚点标识，锚点标识后的范围标识{}标示要读取的对应配置文件名称和配置文件中对应的关键字段名。$、{}及其中的字符组合成了锚点，其表示从{}中对应的配置文件中提取关键值为配置参数。

可以理解的是锚点标识、范围标识不限于上述示例中的情况，本申请不对其加以限制。

在本申请一优选的实施例中，所述步骤120，包括子步骤121-123：

子步骤121，根据所述配置模板中的定位锚点从定位配置文件获取定位标识；

在模板中定位锚点语句${who:cluster_name}_eat,对应的是定位配置文件：

who.conf

{

cluster_name:hangzhou

}

其首先根据who查找到who.conf文件，然后根据cluster_name从该配置文件中匹配，读取cluster_name下的关键值，得到定位标识“hanghzhou”。

其他定位锚点类似。

子步骤122，根据所述配置模板中的功能锚点从功能配置文件中获取功能开关标识；

在模板中的功能开关锚点语句${switch:is_eat},对应的是功能开关配置文件：

其首先根据switch查找到switch.conf文件，然后根据is_eat读取该关键字段下的关键值，得到功能开关标识为“yes”。类似的，${switch:is_sleep}读取得到的功能开关标识为“no”。

子步骤123，根据所述配置模板中的资源锚点以及定位标识从资源配置文件中获取资源地址；所述资源锚点中包括定位锚点。

模板中的资源锚点语句${res_eat:${who:cluster_name}}和${res_sleep:${who:cluster_name}},其首先将${who:cluster_name}替换为子步骤121中得到的定位标识“hanghzhou”，从而得到${res_eat:hanghzhou}和${res_sleep:hanghzhou}。

然后对于${res_eat:hanghzhou}对于的资源配置文件：

首先根据res_eat查找到res_eat.conf文件，然后根据hangzhou读取相应字段下的关键值得到资源地址hangzhou_eat.com。

类似的，{res_sleep:hanghzhou}从配置文件

中读取到资源地址hangzhou_sleep.com。

步骤130，以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的第一配置文件。

因为由配置模板中的锚点分别从上述定位配置文件、功能配置文件以及各资源配置文件中读取了相应的配置参数，那么本申请实施例中将相应的配置参数替换相应的锚点，然后调用配置文件生成逻辑，即可有上述.tpl格式的文件生成.config格式的第一配置文件。

在本申请另一优选的实施例中，步骤130包括子步骤131：

子步骤131，以所述配置文件为基础，在定位锚点代入定位标识、在功能锚点代入功能开关标识、在资源锚点代入资源地址，以生成完全状态的第一配置文件。

根据步骤120中得到的配置文件，配置模版中在锚点位置读取相应配置文件中的参数值，如下例所示：

module.tpl

{

is_eat:yes,

eat_name:hangzhou_eat,

eat_cpu:1,

eat_res:hangzhou_eat.com,

is_sleep:no,

sleep_name:hangzhou_sleep,

sleep_res:hangzhou_sleep.com,

}

然后基于上述替换完锚点的模板生成第一配置文件如下示例

module.config

{

is_eat:yes,

eat_name:hangzhou_eat,

eat_cpu:1,

eat_res:hangzhou_eat.com,

is_sleep:no,

sleep_name:hangzhou_sleep,

sleep_res:hangzhou_sleep.com,

sleep_cpu:1

}

该配置文件则为一个完全状态的配置文件，服务器可以根据该配置文件运行相应的程序。

实施例二

参照图2，示出了本申请的一种配置管理方法实施例的步骤流程图，具体可以包括如下步骤：

步骤210，获取各资源配置文件，以及属于当前云服务器所在集群的定位配置文件、功能配置文件；其中，每个资源配置文件中的各资源地址与各集群的定位配置文件中的定位标识作为关键字段；所述功能配置文件中的功能关键字段采用各资源配置文件的名称；

本申请实施例可以应用于混合云集群的环境下。该种情况下，由于存在多个集群，而实际上每个集群都有自己的定位标识，个性化的功能需求，而在新建集群时，定位标识和个性化功能需求都已经确定，那么运维只需要设定该集群的定位配置文件和功能配置文件，然后分发到该集群即可。

在实际应用中，运维人员可以对定位配置文件和功能配置文件与集群地址绑定，然后将其上传至调度服务器。调度服务器则根据该地址，将该定位配置文件和功能配置文件传输至该地址相应的集群的各台服务器中。

当然，实际应用中，功能配置文件中可以将混合云集群的所有功能的关键字段进行配置，然后对于当前集群，需要的功能则将其关键值设置为yes，不需要的功能关键值设置为no。

另外，对于混合云集群，其功能是对所有集群开放的。因此对于资源配置文件，可以全局发送到各个集群的服务器中。

其中资源配置文件，定位配置文件、功能配置文件的具体原理类似前述实施例一的步骤100中的描述，在此不再赘叙。

步骤220，接收由调度服务器向各集群分发的配置模板；其中，分发给各集群的配置模板相同；

对于研发人员来说，由于运维在功能配置文件中设置了各个各集群自身需要的功能的功能开关，因此研发人员的配置模板可以使用同一个配置模板，将其上传至调度服务器。各集群的服务器接收调度服务器分发的配置模板后，各服务器根据功能配置文件中的配置打开或者关闭相应功能。

步骤220是实施例一的步骤110的优选的步骤。

步骤230，根据所述配置模板中的定位锚点从定位配置文件获取定位标识；

步骤240，根据所述配置模板中的功能锚点从功能配置文件中获取功能开关标识；

步骤250，根据所述配置模板中的资源锚点以及定位标识从资源配置文件中获取资源地址；所述资源锚点中包括定位锚点；

步骤220-步骤250是实施例一的步骤120的优选的步骤。

步骤260，以所述配置文件为基础，在定位锚点代入定位标识、在功能锚点代入功能开关标识、在资源锚点代入资源地址，以生成完全状态的第一配置文件。

步骤260是实施例一的步骤130的优选的步骤。

步骤270，调用所述第一配置文件时，若检查到第一配置文件中的任一功能的功能开关字段的功能开关标识表示禁止使用，则停止执行所述功能的相关逻辑。

如实施例一中最后得到的第一配置文件：

module.config

{

is_eat:yes,

eat_name:hangzhou_eat,

eat_cpu:1,

eat_res:hangzhou_eat.com,

is_sleep:no,

sleep_name:hangzhou_sleep,

sleep_res:hangzhou_sleep.com,

sleep_cpu:1,

}

服务器启用程序后，加载第一配置文件后解析，如果某个功能的功能开关字段的关键值为yes，则该服务器可以调用该功能，从相应的资源地址调用相应的资源执行。而如果某个功能的功能开关字段的关键值为no，则禁止该服务器使用该功能，则与该功能相关的代码，服务器可以忽略。

比如上述示例中，eat功能的is_eat为yes，那么服务器可以执行eat的后续代码：

eat_name:hangzhou_eat,

eat_cpu:1,

eat_res:hangzhou_eat.com，

而sleep功能的is_sleep为no，那么服务器则不再执行sleep相关的代码：

sleep_name:hangzhou_sleep,

sleep_res:hangzhou_sleep.com,

sleep_cpu:1

在本申请一优选的实施例中，在步骤260之后，还包括步骤S11-S12：

步骤S11，判断功能配置文件是否更新；

步骤S12，如果功能配置文件更新，则进入根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数的步骤。

在本申请实施例中，如果某个集群需要在原功能不变的情况下，也即各资源文件名不变的情况下，增加新的功能，那么可以由运维对功能配置文件进行修改，将相应功能的功能开关关键字段修改为yes。或者在原功能不变的情况下，删减某些功能，那么可以由运维对功能配置文件进行修改，将相应功能的功能开关关键字段修改为no。

然后本申请实施例的运维人员则可以通知该集群进行升级，那么该集群中的服务器则判断功能配置文件是否更新，如果功能配置文件更新，则进入步骤230，可以重新执行第一配置文件的生成的步骤。

当然，在实施例一中，如果功能配置文件更新则进入步骤120。

在本申请一优选的实施例，在步骤260之后，还包括步骤S21-步骤S22；

步骤S21，判断所述配置模板是否更新；

步骤S22，如果所述配置模板更新，则进入根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数的步骤。

在本申请实施例中，一般情况下，各个集群的定位配置文件不会改变，功能配置文件也基本不变。而如果研发人员对原有的某些功能进行升级，比如对于身份验证服务的功能，研发人员要添加验证次数、时限等对该功能更丰富的执行条件。由于其调用的该功能的资源地址不变。因此研发人员只需要修改配置模板，然后将配置模板上传至调度服务器，由调度服务器分发至各集群。或者直接将配置模板单独上传至其指定的集群，然后研发人员可以通知集群升级。

相应集群的服务器在判断配置模板被更新后，则可以进入步骤230，可以重新执行第一配置文件的生成的步骤。

当然，在实施例一中，如果配置模板被更新，则进入步骤120。

在本申请一优选的实施例，在在步骤260之后之后，还包括步骤S31-S32：

步骤S31，判断所述功能配置文件记录的各功能所对应资源配置文件是否更新；

步骤S32，如果所述功能配置文件记录的各功能所对应资源配置文件更新，则进入根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数的步骤。

对于一种功能，如果其名称不变，而其对应的资源地址变更，研发人员则可以修改相应的资源配置文件。然后将修改后的资源配置文件全局覆盖所有集群服务器中原来的资源配置文件。

那么服务器判断该资源配置文件被更新，则可以进入步骤230，可以重新执行第一配置文件的生成的步骤。当然，在实施例一中，如果配置模板被更新，则进入步骤120。

当然，上述功能配置文件、配置模板、资源配置文件可以根据需要同时更新、或者更新任意一个或几个，如果判断其中任意一个更新，则可以进入步骤230，可以重新执行第一配置文件的生成的步骤。当然，在实施例一中，如果配置模板被更新，则进入步骤120。如果判断全部未更新，则不进行任何操作。

当然，在本申请实施例中，各个服务器可以在本地记录各种版本的定位配置文件、功能配置文件以及各资源配置文件、以及配置模板，方便出现错误时核查。

在大规模混合云运维中，最复杂的就是配置文件管理，其复杂在于，每一个集群都有自己的特殊标志，比如其需求的功能和定位标识，使用的资源也是各不相同，所以如果有n个集群，每个集群最多有m种特殊标志，然后每个集群特殊标志的组合可以有C(m，2)种。而所有的这些信息都存储在配置文件里面，也就是配置文件的复杂度为n*m*c(m,2)，而其中任何一个出问题都会导致致命的故障，所以无论新建集群还是升级做方案的时候，都要考虑到这种复杂度。除了配置本身复杂，还有一个问题就是运维和研发的沟通成本问题，配置混合在一起，复杂度又高，造成了极大的运维研发沟通成本，所以降低复杂度就成为迫在眉睫的问题了。

而在先技术中使用的三种第三方系统：一个单独的配置服务器、svn(Subversion是一个开放源代码的版本控制系统)或者git(Git是一款免费、开源的分布式版本控制系统)、cmdb(Configuration Management Database，配置管理数据库)，其都存在运维人员与研发人员对配置文件的创建过程耦合度高；配置文件的管理集中在一个第三方系统中、导致运维的容灾效果差；配置文件的管理过程人工参与度高，系统的自我识别能力差，配置文件的管理效率低等问题。

而本申请实施例首先：本申请将配置文件的创建所需内容按照运维人员与研发人员分离，运维人员和研发人员的沟通代价大大减少，在定位配置文件和功能配置文件不需要变更的情况下，研发人员甚至不需要和运维人员沟通即可通过更新配置模板实现系统的升级。

比如对于某个功能的资源开发者，其开发了新的资源，则只需要将新的资源写入相应功能的资源配置文件即可，无需运维的参与。

如果研发人员想要升级某个功能，只需要修改配置模板module.tpl、和/或者和res_*.conf即可，其中res_*.conf表示各种功能的资源配置文件，也无需运维的参与。

比如前述如果研发人员想要升级某个功能，其修改配置模板module.tpl、和/或者和res_*.conf即可，那么服务器会自动抓取其中的who.conf和switch.conf的信息，然后结合module.tpl和res_*.conf，自动生成真正的第一配置文件，实现了在低人工参与度的情况下，集群自动升级过程。

最后，由于使用了功能配置文件switch.config，新增了功能开关，通过功能使各个集群可以配置不同的功能，从而使用同一份配置模板，可以供各个集群使用，降低了配置模板的数量，无需为每个集群创建一份模板。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

实施例三

参照图3，示出了本申请的一种云集群能自识别的分布配置管理装置实施例的结构框图，具体可以包括如下模块：

模板接收模块310，用于接收配置模板；

配置参数获取模块320，用于根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数；

配置文件生成模块330，用于以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的第一配置文件。

在本申请一优选的实施例中，所述配置参数获取模块320，包括：

定位标识获取子模块，用于根据所述配置模板中的定位锚点从定位配置文件获取定位标识；

开关标识获取子模块，用于根据所述配置模板中的功能锚点从功能配置文件中获取功能开关标识；

资源地址获取子模块，用于根据所述配置模板中的资源锚点以及定位标识从资源配置文件中获取资源地址；所述资源锚点中包括定位锚点。

在本申请一优选的实施例中，所述配置文件生成模块330，包括：

第一配置文件生成子模块，用于以所述配置文件为基础，在定位锚点代入定位标识、在功能锚点代入功能开关标识、在资源锚点代入资源地址，以生成完全状态的第一配置文件。

在本申请一优选的实施例中，所述配置模板包括：

在本申请一优选的实施例中，在模板接收模块310之前，还包括：

配置文件获取模块，用于获取各资源配置文件，以及属于当前云服务器所在集群的定位配置文件、功能配置文件；其中，每个资源配置文件中的各资源地址与各集群的定位配置文件中的定位标识作为关键字段；所述功能配置文件中的功能关键字段采用各资源配置文件的名称。

实施例四

参照图4，示出了本申请的一种云集群能自识别的分布配置管理装置实施例的结构框图，具体可以包括如下模块：

配置文件获取模块400，用于获取各资源配置文件，以及属于当前云服务器所在集群的定位配置文件、功能配置文件；其中，每个资源配置文件中的各资源地址与各集群的定位配置文件中的定位标识作为关键字段；所述功能配置文件中的功能关键字段采用各资源配置文件的名称。

模板接收模块410，用于接收配置模板，具体包括：

第一模板接收模块411，用于接收由调度服务器向各集群分发的配置模板；其中，分发给各集群的配置模板相同

配置参数获取模块420，用于配置参数获取模块，用于根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数，具体包括：

定位标识获取子模块421，用于根据所述配置模板中的定位锚点从定位配置文件获取定位标识；

开关标识获取子模块422，用于根据所述配置模板中的功能锚点从功能配置文件中获取功能开关标识；

资源地址获取子模块423，用于根据所述配置模板中的资源锚点以及定位标识从资源配置文件中获取资源地址；所述资源锚点中包括定位锚点。

配置文件生成模块430，用于以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的第一配置文件，具体包括：

第一配置文件生成子模块431，用于以所述配置文件为基础，在定位锚点代入定位标识、在功能锚点代入功能开关标识、在资源锚点代入资源地址，以生成完全状态的第一配置文件。

调用模块440，用于调用所述第一配置文件时，若检查到第一配置文件中的任一功能的功能开关字段的功能开关标识表示禁止使用，则停止执行所述功能的相关逻辑。

在本申请一优选的实施例中，在配置文件生成模块430之后，还包括：

功能配置文件检测更新模块，用于判断功能配置文件是否更新；如果功能配置文件更新，则进入配置参数获取模块420。

检测配置模板更新模块，用于判断所述配置模板是否更新；如果所述配置模板更新，则进入配置参数获取模块420。

资源配置文件检测更新模块，用于判断所述功能配置文件记录的各功能所对应资源配置文件是否更新；如果所述功能配置文件记录的各功能所对应资源配置文件更新，则进入配置参数获取模块420。

本申请实施例首先：本申请将配置文件的创建所需内容按照运维人员与研发人员分离，运维人员和研发人员的沟通代价大大减少，在定位配置文件和功能配置文件不需要变更的情况下，研发人员甚至不需要和运维人员沟通即可通过更新配置模板实现系统的升级。

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

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

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种配置管理方法和一种配置管理装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种配置管理方法，应用于云集群中的服务器，其特征在于，包括：

接收配置模板；

以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的第一配置文件；

其中，所述定位配置文件和功能配置文件由运维人员管理，所述资源配置文件和配置模板由开发人员管理；

其中，所述资源配置文件为全局的配置文件，所述服务器使用的定位配置文件、功能配置文件为针对所述服务器所在集群的配置文件；其中，各云集群使用的配置模板相同。

2.根据权利要求1所述的方法，其特征在于，所述根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数的步骤，包括：

根据所述配置模板中的定位锚点从定位配置文件获取定位标识；

根据所述配置模板中的功能锚点从功能配置文件中获取功能开关标识；

根据所述配置模板中的资源锚点以及定位标识从资源配置文件中获取资源地址；所述资源锚点中包括定位锚点。

3.根据权利要求1所述的方法，其特征在于，所述以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的配置文件的步骤，包括：

以所述配置文件为基础，在定位锚点代入定位标识、在功能锚点代入功能开关标识、在资源锚点代入资源地址，以生成完全状态的第一配置文件。

4.根据权利要求2所述的方法，其特征在于，所述配置模板包括：

各功能的功能开关关键字段、功能名称关键字段、功能资源关键字段；其中，所述定位锚点在功能名称关键字段的关键值中以及资源锚点中，所述功能锚点在功能开关字段的关键值中，所述资源锚点在所述功能资源关键字段的关键值中。

5.根据权利要求1所述的方法，其特征在于，在接收配置模板之前，还包括：

获取各资源配置文件，以及属于当前云服务器所在集群的定位配置文件、功能配置文件；其中，每个资源配置文件中的各资源地址与各集群的定位配置文件中的定位标识作为关键字段；所述功能配置文件中的功能关键字段采用各资源配置文件的名称。

6.根据权利要求1-5其中之一所述的方法，其特征在于，在以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的第一配置文件的步骤之后，还包括：

调用所述第一配置文件时，若检查到第一配置文件中的任一功能的功能开关字段的功能开关标识表示禁止使用，则停止执行所述功能的相关逻辑。

7.根据权利要求6所述的方法，其特征在于，所述接收配置模板的步骤包括：

接收由调度服务器向各集群分发的配置模板；其中，分发给各集群的配置模板相同。

8.根据权利要求1-5其中之一所述的方法，其特征在于，在以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的第一配置文件的步骤之后，还包括：

判断功能配置文件是否更新；

如果功能配置文件更新，则进入根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数的步骤。

9.根据权利要求1-5其中之一所述的方法，其特征在于，在以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的第一配置文件的步骤之后，还包括：

判断所述配置模板是否更新；

如果所述配置模板更新，则进入根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数的步骤。

10.根据权利要求1-5其中之一所述的方法，其特征在于，在以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的第一配置文件的步骤之后，还包括：

判断所述功能配置文件记录的各功能所对应资源配置文件是否更新；

如果所述功能配置文件记录的各功能所对应资源配置文件更新，则进入根据所述配置模板的各锚点，分别从定位配置文件、功能配置文件以及各资源配置文件中读取与各锚点对应的配置参数的步骤。

11.一种配置管理装置，应用于云集群中的服务器，其特征在于，包括：

模板接收模块，用于接收配置模板；

配置文件生成模块，用于以所述配置文件为基础，在各锚点位置代入相应配置参数生成完全状态的第一配置文件；

12.根据权利要求11所述的装置，其特征在于，所述配置参数获取模块，包括：

13.根据权利要求11所述的装置，其特征在于，所述配置文件生成模块，包括：

14.根据权利要求12所述的装置，其特征在于，所述配置模板包括：

15.根据权利要求11所述的装置，其特征在于，在模板接收模块之前，还包括：

16.根据权利要求11-15其中之一所述的装置，其特征在于，在配置文件生成模块之后，还包括：

调用模块，用于调用所述第一配置文件时，若检查到第一配置文件中的任一功能的功能开关字段的功能开关标识表示禁止使用，则停止执行所述功能的相关逻辑。

17.根据权利要求16所述的装置，其特征在于，所述模板接收模块包括：

第一模板接收模块，用于接收由调度服务器向各集群分发的配置模板；其中，分发给各集群的配置模板相同。

18.根据权利要求11-15其中之一所述的装置，其特征在于，在配置文件生成模块之后，还包括：

功能配置文件更新判断模块，用于判断功能配置文件是否更新；如果功能配置文件更新，则进入配置参数获取模块。

19.根据权利要求11-15其中之一所述的装置，其特征在于，在配置文件生成模块之后，还包括：

配置模板更新判断模块，用于判断所述配置模板是否更新；如果所述配置模板更新，则进入配置参数获取模块。

20.根据权利要求11-15其中之一所述的装置，其特征在于，在配置文件生成模块之后，还包括：

资源配置文件判断模块，用于判断所述功能配置文件记录的各功能所对应资源配置文件是否更新；如果所述功能配置文件记录的各功能所对应资源配置文件更新，则进入配置参数获取模块。