CN106406949B

CN106406949B - 配置文件的处理方法及装置

Info

Publication number: CN106406949B
Application number: CN201610829849.9A
Authority: CN
Inventors: 石子夜; 陈科
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2016-09-18
Filing date: 2016-09-18
Publication date: 2020-01-21
Anticipated expiration: 2036-09-18
Also published as: CN106406949A

Abstract

本发明提供一种配置文件的处理方法及装置。其中所述方法包括：根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识复杂系统中的其它模块的各环境对应的标签；根据配置文件模板中标识的标签和配置文件模板，生成待部署模块在当前环境的目标配置文件。通过采用本发明的技术方案，仅仅根据复杂系统中待部署模块在当前环境所依赖的服务信息和配置文件模板，便可以生成待部署模块在当前环境的目标配置文件。与现有的配置文件的确定方式相比，本发明的技术方案中，仅需要维护一套配置文件模板即可，大大地简化了配置文件的生成方式。

Description

配置文件的处理方法及装置

【技术领域】

本发明涉及软件处理技术领域，尤其涉及一种配置文件的处理方法及装置。

【背景技术】

现有技术中，在云平台等复杂系统中，通常采用多个软件模块构成。每个模块可以部署在多套环境中，例如模块M₁有n₁套环境，模块M₂有n₂套环境……，模块M_k有n_k套环境。每个模块的每一种环境可以互相组合，这样整个复杂系统最多有

种配置文件。

现有技术中，复杂系统的配置文件的确定方法，具体可以包括如下方式：第一种为多配置文件方法，该方法中按需要维护多套配置组合，至多有

种套配置组合。第二种为常规模板方法，模板方法一般都有个模板解析器，也可以称之为模板引擎，配置文件里按照模板引擎的规则，书写配置文件，复杂系统部署的时候，模板引擎根据该模块所依赖模块的环境，解析当前将要部署模块的配置文件，生成当前要部署模块最终的配置文件。

但是，现有技术的配置文件的确定过程较为复杂，例如多配置文件的方法中，容易造成组合爆炸，需要维护多套配置文件；常规模板方法中，引入需要学习的新语言，生成方式比较复杂，且破坏原有配置文件语法。

【发明内容】

本发明提供了一种配置文件的处理方法及装置，用于简化配置文件生成方式。

本发明提供一种配置文件的处理方法，所述方法包括：

根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识所述复杂系统中的其它模块的各环境对应的标签；所述配置文件模板中包括所述复杂系统中所有模块的配置文件；

根据所述配置文件模板中标识的所述标签和所述配置文件模板，生成所述待部署模块在所述当前环境的目标配置文件。

进一步可选地，如上所述的方法中，根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识所述复杂系统中的其它模块的各环境对应的标签，具体包括：

根据所述复杂系统中所述待部署模块在所述当前环境所依赖的服务信息，在所述配置文件模板中标识所述待部署模块在所述当前环境依赖第一模块在第一环境下的存在标签；

根据所述复杂系统中所述待部署模块在所述当前环境所依赖的服务信息，在所述配置文件模板中标识所述待部署模块在所述当前环境不依赖第二模块在第二环境下的不存在标签。

进一步可选地，如上所述的方法中，根据所述配置文件模板中标识的所述标签和所述配置文件模板，生成所述待部署模块在所述当前环境的目标配置文件，具体包括：

删除所述配置文件模板中所述不存在标签所在的行；

删掉所述配置文件模板中的所述存在标签；

根据删除之后的所述配置文件模板，生成所述待部署模块在所述当前环境的目标配置文件。

进一步可选地，如上所述的方法中，根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识所述复杂系统中的其它模块的各环境对应的标签之前，还包括：

生成所述配置文件模板。

进一步可选地，如上所述的方法中，所述配置文件模板采用json格式、javaproperties格式或者ini格式。

进一步可选地，如上所述的方法中，所述环境包括线上、预上线、测试以及本地环境。

本发明还提供一种配置文件的处理装置，所述装置包括：

标识模块，用于根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识所述复杂系统中的其它模块的各环境的标签；所述配置文件模板中包括所述复杂系统中所有模块的配置文件；

生成模块，用于根据所述配置文件模板中标识的所述标签和所述配置文件模板，生成所述待部署模块在所述当前环境的目标配置文件。

进一步可选地，如上所述的装置中，所述标识模块，具体用于：

进一步可选地，如上所述的装置中，所述生成模块，具体包括：

删除单元，用于删除所述配置文件模板中所述不存在标签所在的行；

所述删除单元，还用于删掉所述配置文件模板中的所述存在标签；

生成单元，用于根据删除之后的所述配置文件模板，生成所述待部署模块在所述当前环境的目标配置文件。

进一步可选地，如上所述的装置中，所述装置还包括：

生成模块，用于生成所述配置文件模板。

进一步可选地，如上所述的装置中，所述配置文件模板采用json格式、javaproperties格式或者ini格式。

进一步可选地，如上所述的装置中，所述环境包括线上、预上线、测试以及本地环境。

本发明的配置文件的处理方法及装置，通过根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识复杂系统中的其它模块的各环境对应的标签；根据配置文件模板中标识的标签和配置文件模板，生成待部署模块在当前环境的目标配置文件。通过采用本发明的技术方案，仅仅根据复杂系统中待部署模块在当前环境所依赖的服务信息和配置文件模板，便可以生成待部署模块在当前环境的目标配置文件。与现有的配置文件的确定方式相比，本发明的技术方案中，仅需要维护一套配置文件模板即可，大大地简化了配置文件的生成方式，且不会存在组合爆炸的情况，也不需要学习新的语言去生成配置文件，即不会破坏原有配置文件的语法，因此，本发明生成的配置文件具有更广泛的适用性和更强的兼容性。

【附图说明】

图1为本发明的配置文件的处理方法实施例的流程图。

图2为本发明的配置文件的处理装置实施例一的结构图。

图3为本发明的配置文件的处理装置实施例二的结构图。

【具体实施方式】

为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。

图1为本发明的配置文件的处理方法实施例的流程图。如图1所示，本实施例的配置文件的处理方法，具体可以包括如下步骤：

100、根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识复杂系统中的其它模块的各环境对应的标签；

本实施例的配置文件模板中包括复杂系统中所有模块的配置文件。也就是说本实施例的配置文件模板不是一个真正的配置文件，而是一个包括该复杂系统的所有的模块在所有环境下的配置信息的模板文件。在进行模块部署时，可以根据复杂系统中当前的待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识复杂系统中的其它模块的各环境对应的标签。其中待部署模块所依赖的服务信息具体可以包括待部署模块在当前环境下所依赖的模块在特定环境下的信息。对于该待部署模块在当前环境下不依赖的特定环境下的模块，不再服务信息中体现。即服务信息中没有包括的环境以及对应的模块，表示该待部署模块在当前环境的运行不依赖于该模块的该环境。

例如本实施例中该步骤100标识的标签可以包括两种标签：存在标签和不存在标签。其中存在标签标识过程如下：根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识待部署模块在当前环境依赖第一模块在第一环境下的存在标签。

不存在标签的标识过程如下：根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识待部署模块在当前环境不依赖第二模块在第二环境下的不存在标签。

本实施例中的上述第一模块可以与第二模块相同，第一环境可以与第二环境相同，但是不可能同时依赖于同一模块的同一环境，同时又不依赖于同一模块的同一环境，因此前后两者不能同时相同。本实施例中的环境可为线上online、预上线、测试test环境以及本地环境。

也就是说，根据复杂系统中待部署模块在当前环境所依赖的服务信息，可以知道该待部署模块在当前环境依赖哪个模块的哪个环境，在配置文件模板中，标识所依赖那个模块的那个环境对应的配置文件的标签为存在标签，TAG_EXIST。而对于服务信息中没有体现的模块及对应的环境，即为该待部署模块在当前环境不依赖的那个模块以及对应的那个环境。对应在配置文件模板中，标识不依赖那个模块的那个环境对应的配置文件的标签为不存在标签TAG_NOT_EXIST。

101、根据配置文件模板中标识的标签和配置文件模板，生成待部署模块在当前环境的目标配置文件。

本实施例中，经过上述步骤标识的标签实际上相当于对配置文件模板中各个模块以及对应的环境做注释，解释待部署模块在当前环境依赖哪个模块的哪个环境，不依赖哪个模块的哪个环境。例如，该步骤具体可以包括如下步骤：

(a1)删除配置文件模板中不存在标签所在的行；

(a2)删掉配置文件模板中的存在标签；

(a3)根据删除之后的配置文件模板，生成待部署模块在当前环境的目标配置文件。

然后根据在配置文件模板中标识的复杂系统中的其它模块的各环境对应的存在标签或者不存在标签，删除配置文件模板中不存在标签所在的行，即由于当前待部署模块在当前环境下不依赖不存在标签标识的该模块的该环境，则删除该行标识的模块在该环境下的配置信息。而对于存在标签，由于待部署模块在当前环境下依赖该存在标签标识的该模块的该环境，则删除该存在标签，而保留该模块以及该环境对应的配置信息，这样，配置文件模板中最终保留的配置信息，便构成了待部署模块在当前环境的目标配置文件。例如，在通过上述删除之后，只需要运行简单的脚本，就会生成待部署模块在当前环境的目标配置文件。

本实施例中的配置文件模板采用json格式、java properties格式或者ini格式，具体地，目标配置文件的格式与配置文件模板的格式相同，也可以为json格式、javaproperties格式或者ini格式。实际应用中，配置文件模板和目标配置文件还可以采用其他格式的配置文件，在此不再一一举例说明。

可选地，在上述实施例的步骤100之前，还可以包括生成配置文件模板；具体地，首先获取各个模块的各个环境的配置信息，然后将各个模块对应的各个环境的配置信息综合在一起，生成配置文件模板。

本实施例的配置文件的处理方法，通过根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识复杂系统中的其它模块的各环境对应的标签；根据配置文件模板中标识的标签和配置文件模板，生成待部署模块在当前环境的目标配置文件。通过采用本实施例的技术方案，仅仅根据复杂系统中待部署模块在当前环境所依赖的服务信息和配置文件模板，便可以生成待部署模块在当前环境的目标配置文件。与现有的配置文件的确定方式相比，本实施例的技术方案中，仅需要维护一套配置文件模板即可，大大地简化了配置文件的生成方式，且不会存在组合爆炸的情况，也不需要学习新的语言去生成配置文件，即不会破坏原有配置文件的语法，因此，本实施例生成的配置文件具有更广泛的适用性和更强的兼容性。

基于以上所述，本实施例的配置文件的处理方法，在根据复杂系统中待部署模块在当前环境所依赖的服务信息标识标签的过程中，类似于打开依赖的模块以及对应环境的开关，而关闭不依赖的模块以及对应环境的开关，因此，也可以称为多开关自适应配置文件的处理方法。

本实施例的技术方案，在某定程度上可以分为配置文件的书写和配置文件的替换。

首先、配置文件的书写。

在保持模块当前配置文件的结构基础上，引入当前配置文件支持的语法结构，对配置文件打特定的标签(即注释)。不管依赖模块的环境有多少种，只需要维护特定的一套配置文件模板。对配置文件模板的书写需要三个要素：一，引入配置文件支持的语法标记，如json配置文件的/**/；二，标记名，可以根据个人喜好起标记名，如判断某种服务存在的标记TAG_EXIST等等；三，Feature名，该模块依赖feature的名字。

下面举个例子来说明配置书写的方法：

假设A模块依赖于模块B，A的配置文件是常见的json格式，A的线上配置文件(依赖线上B模块)如下：

{

“module-B.address”:“online”

}

A的本地测试环境配置文件(依赖测试环境B模块)如下：

{

“module-B.address”:“test”

}

首先引入json支持的语法结构/**/,对A的配置文件进行改造。A模块自适应配置文件如下：

其次、配置文件的替换。

对配置文件模板改造即打标签之后，在模块部署之前，只需要运行简单的脚本就会生成模块在当前环境的目标配置文件。模块A的配置文件是module-A.properties,根据feature来选择具体的配置信息，打的标签如下：/*TAG_EXIST$feature*/和/*TAG_NOT_EXITS$feature*/。遍历当前部署模块所依赖的模块feature，如果当前环境有这个feature，则删除/*TAG_EXIST$feature*/标记，同时删除/*TAG_NOT_EXIST$feature*/所在的行；最后删除/*TAG_NOT_EXIST.**/标记，同时删除/*TAG_EXIST.**/所在的行。简单脚本如下：

for feature in features

do

sed-i"s#/\*TAG_EXIST$feature\*/##g"module-A.properties

sed-i"\#/*TAG_NOT_EXIST$feature\*/#d”module-A.properties

done

sed-i"s#/\*TAG_NOT_EXIST.*\*/##g"module-A.properties

sed-i"\#/*TAG_EXIST.*\*/#d"module-A.properties

对于上面的例子，要自动化部署各个模块的时候，如果模块A强依赖于模块B，这时候必须先部署模块B。通过模块部署的顺序图获得的feature信息。部署模块A之前，执行上文的脚本，一旦发现本地环境已经有模块B提供的服务即B_service，直接删掉/*TAG_EXISTbservice*/标签，并保留“module-B.address”:“test”，同时删掉配置TAG_NOT_EXIST这一行。同理如果当前环境没有bservice，则A依赖于线上的模块B，保留含有TAG_NOT_EXIST这行的配置文件，删除含有TAG_EXIST行。

图2为本发明的配置文件的处理装置实施例一的结构图。如图2所示，本实施例的配置文件的处理装置，具体包括：标识模块10和生成模块11。

其中标识模块10用于根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识复杂系统中的其它模块的各环境的标签；配置文件模板中包括复杂系统中所有模块的配置文件；生成模块11用于根据标识模块10标识的配置文件模板中标识的标签和配置文件模板，生成待部署模块在当前环境的目标配置文件。

本实施例的配置文件的处理装置，通过采用上述模块实现配置文件处理的实现原理以及技术效果，与上述相关方法实施例的相同，详细可以参考上述相关方法实施例的记载，在此不再赘述。

图3为本发明的配置文件的处理装置实施例二的结构图。如图3所示，本实施例的配置文件的处理装置，在上述图2所示实施例的技术方案的基础上，进一步更加详细地介绍本发明的技术方案。

本实施例的配置文件的处理装置中，标识模块10具体用于：

根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识待部署模块在当前环境赖第一模块在第一环境下的存在标签；

根据复杂系统中待部署模块在当前环境所依赖的服务信息，在配置文件模板中标识待部署模块在当前环境不依赖第二模块在第二环境下的不存在标签。

进一步可选地，如图3所示，本实施例的配置文件的处理装置中，8生成模块11具体包括：

删除单元111用于根据标识模块10标识的标签，删除配置文件模板中不存在标签所在的行；删除单元111还用于根据标识模块10标识的标签，删掉配置文件模板中的存在标签；生成单元112用于根据删除单元111删除之后的配置文件模板，生成待部署模块在当前环境的目标配置文件。

进一步可选地，本实施例的配置文件的处理装置中配置文件模板采用json格式、java properties格式或者ini格式。

进一步可选地，本实施例的配置文件的处理装置中环境包括线上、预上线、测试以及本地环境。。

进一步可选地，如图3所示，本实施例的配置文件的处理装置中，还包括生成模块12用于生成配置文件模板。对应地，标识模块10用于根据复杂系统中待部署模块在当前环境所依赖的服务信息，在生成模块12生成的配置文件模板中标识复杂系统中的其它模块的各环境的标签。

在本发明所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims

1.一种配置文件的处理方法，其特征在于，所述方法包括：

根据复杂系统中待部署模块在当前环境所依赖的服务信息，所述服务信息包括待部署模块在当前环境下所依赖的模块在特定环境下的信息，在配置文件模板中标识所述待部署模块在所述当前环境所依赖的模块在所述特定环境下的存在标签，在配置文件模板中标识所述待部署模块在所述当前环境不依赖的模块在所述特定环境下的不存在标签；所述配置文件模板中包括所述复杂系统中所有模块的配置文件；

2.根据权利要求1所述的方法，其特征在于，根据所述配置文件模板中标识的所述标签和所述配置文件模板，生成所述待部署模块在所述当前环境的目标配置文件，具体包括：

删除所述配置文件模板中所述不存在标签所在的行；

删掉所述配置文件模板中的所述存在标签；

3.根据权利要求1所述的方法，其特征在于，在配置文件模板中进行标识之前，所述方法还包括：

生成所述配置文件模板。

4.根据权利要求1-3任一所述的方法，其特征在于，所述配置文件模板采用json格式、java properties格式或者ini格式。

5.根据权利要求1-3任一所述的方法，其特征在于，所述环境包括线上、预上线、测试以及本地环境。

6.一种配置文件的处理装置，其特征在于，所述装置包括：

标识模块，用于根据复杂系统中待部署模块在当前环境所依赖的服务信息，所述服务信息包括待部署模块在当前环境下所依赖的模块在特定环境下的信息，在配置文件模板中标识所述待部署模块在所述当前环境所依赖的模块在所述特定环境下的存在标签，在配置文件模板中标识所述待部署模块在所述当前环境不依赖的模块在所述特定环境下的不存在标签；所述配置文件模板中包括所述复杂系统中所有模块的配置文件；

7.根据权利要求6所述的装置，其特征在于，所述生成模块，具体包括：

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

生成模块，用于生成所述配置文件模板。

9.根据权利要求6-8任一所述的装置，其特征在于，所述配置文件模板采用json格式、java properties格式或者ini格式。

10.根据权利要求6-8任一所述的装置，其特征在于，所述环境包括线上、预上线、测试以及本地环境。