应用配置管理强调的是，应用运行时依赖的配置管理，不同于项目的静态配置。本文是实际开发过程中的一些总结，以供大家参考，也欢迎交流。
1. 关于配置管理
1.1 名称解释
- 配置项
一个 key=value 组合
- 配置集
一组配置项的集合，key1=value, key2=value2
- 配置实例
一份完整的，可供应用程序直接使用的配置项的集合。
1.2 配置管理的功能
- 版本控制
对所创建的配置项、配置集、配置实例进行版本跟踪，支持回滚等操作。
- 变更控制
对配置的变更进行控制、操作、分类、记录。
- 配置审计
审查配置的一致性、规范性、正确性。
1.3 配置管理的难点
在开发迭代的过程中，随时随地随人都可以对配置进行变更。在不同的时间、应用的不同拓扑层级、不同的人，都有可能会对配置项、配置集、配置实例进行修改。我们需要一种灵活的方式，以支持这些复杂的场景。
配置具有复杂、敏感、影响大的特点。一个配置实例可能有上百个配置项，其中还会包含一些账户、密码等敏感信息，而错误的配置可能导致整个服务不可用。
配置管理的灵活与对配置实例的约束是配置管理产品需要平衡的地方。如何在满足各种使用场景的情况下，通过一定的约束规避一些错误发生，是配置管理的难点。
2. 常见的配置管理模型
2.1 CICO 模型
CICO 模型主要关注的是单个文件的版本控制，文件被版本化并存储到库中。
- 用户必须 checkout 文件以存取
- 修改后的文件被 checkin 到库中产生新版本
2.2 组织模型
组织模型下的配置由两部分组成:
- 系统模型，列出了组成系统的所有构件
- 版本选择规则，指出了组成配置的每个构件的版本
2.3 长事务模型
长事务模型将配置管理当做是开发人员对配置的事务操作。一系列的变更结果生成一些列的配置版本，称之为开发路径。
2.4 变更集模型
变更集模型将配置描述为基线和一组变更集组成。基线可以理解为里程碑版本，也就是一个迭代的结束点、下一个迭代的起始点。
3. 新的配置管理模型
3.1 遇到的问题
CICO 等模型是一些比较老的论文、书籍中提到的，但是在开发 PaaS 平台管理配置时，却无法直接套用。
比如，CICO 模型，用 SVN、GIT 管理文件，并没有强调配置存储于文件，这个文件到底是指的什么。而组织模型，更像是对一个大型的 PaaS 平台进行配置管理，由若干个子模块组成，每个模块都有独立的配置，适用于一组微服务的应用配置管理形态。
3.2 组装模型
古老的模型无法满足 PaaS 平台的场景。但是却能给予一定的启发，将实物构件泛化为要素，组织模型可以演化出组装模型。如下图：
配置实例 = 默认配置集 + 环境配置集 + 集群配置集
利用应用拓扑的定义，根据应用所属的层级，通过定义一定的优先级关系，将各个层级定义的配置集，合并在一起形成一份配置实例。
组装模型通过组装若干要素的方式得到配置实例，但是同一个应用的不同配置实例包含的 Key 集合可能不一样。这种差异会增加配置管理的成本，也会增加配置错误导致的风险，无法直接满足对配置完整性的约束。
3.3 模板模型
基于对完整性的要求，在变更集模型的启发下，可以得到模板模型。如下图:
模板模型需要定义配置实例的模板，根据应用拓扑的结构，形成若干个变更集，对配置实例模板进行覆盖，得到最终的配置实例。
模板模型增强了对配置实例 Key 的约束，保证了强的一致性，可以避免漏配 Key 导致的事故。
但是强一致性约束，也导致了灵活性受损，需要配合配置项、配置集的发布状态进行使用。
