前言
应用程序在运行的时候往往需要依赖一些配置信息进行逻辑运算，而且这些配置基本上伴随着应用程序的整个生命周期。
一般来说配置是独立于程序代码的的只读变量。应用程序去读取配置来改变自己的行为，但是其不能改变配置，而是交由其他入口完成修改这一动作。
故配置需要进行管理，同一个应用在不同的部署环境（开发、测试、预生产、生产）经常需要不同的配置，所以需要有便捷、完善的配置管理流程去进行管理。
代码配置管理的演变
开端
最开始的配置是如何编写及放置的呢？
当然是代码写到哪里，配置就加到哪里，这是最早期和顺手的做法，如下图。
（图中的提示语其实就是一个配置项）
这种做法最大的弊端就是：1、不能复用，一次修改，处处修改；2、不能按照不同环境所需进行调整。所以，此处应当进行抽离。
分工
逻辑代码一类，配置项一类，把配置内容进行抽离，独立放置到一个文件中，就是我所说的分工。既然配置项独立出一个文件了，那么后面的按环境加载就好办了。
一般来说，会对不同环境的配置文件使用不同的前缀进行命名，然后相应环境机器上也会有相关的一个环境变量供程序读取，读取后依靠这个环境变量进行按需加载配置文件就好了。
优点：
1、与项目关联紧密；
缺点：
1、更新及发布麻烦，需要修改代码；
2、缺失权限管理，安全性低；
3、不同应用项目配置不能共用；
4、配置零散，分散在各个项目代码中；
分权
按照前一个（分工）配置管理的做法，做大的问题是什么呢？
那就是，安全性极低。
这种把所有环境的配置信息都直接记录在项目代码中的做法，意味着只要是该项目的开发人员或能获取到代码的人员，都能看到生产环境的配置信息。
而一般来说，配置信息都会包含有数据库账号，更甚者有支付配置、消息发送配置等信息。如果刚好这些连接配置又没有白名单管理，或者白名单覆盖了整个办公网络，那么就有可能被人为去进行一些恶意操作。
而分权做法则是，代码里面只保留开发环境下的配置文件，其他环境的配置文件则由专人（一般是更高一级人员，如：开发组长）负责修改。随后更新时，把文件交由给相关运维同事进行更新，直接放置到相应环境的机器共享配置文件目录上替换。
优点：
1、有一定的权限管理，权限转移到更高一级的开发人员及运维人员手中；
缺点：
1、更新及发布依旧麻烦；
2、可能存在沟通阻碍，毕竟配置更新方及确认方变为了两方人员；
3、不同应用项目配置不能共用；（原有缺陷）
4、配置零散，分散在各个项目代码中；（原有缺陷）
分层（级）
引入配置中心对各应用项目的配置进行管理，对各个应用、环境、文件、配置项分层，逐层进行管理，同时对于操作人员也要区分不同的操作权限，分为阅读、操作、审核、发布等层级，进行权限管理。
优点：
1、配置统一管理；
2、查看、修改及发布权限可管理；
3、配置文件可以在不同应用中进行复用，进一步可统一修改；
4、更新便捷，点击发布；
其中在github上进行开源可供使用的apollo项目则是一个很优秀的配置管理中心应用，满足了大多数情况下的配置管理需要，下面本文将对其一些配置层次划分结构做一个解析。
Apollo概念拆解
简介
Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
概念层级
其实对于配置中心功能点并不多，主要是提供WEB-UI读写配置、主动连接API（长连接）、拉取配置API等核心API，组成客户端接入配置中心及时获取新配置的操作。其主要分级概念如下：
应用：最顶层，表示一个个应用程序。
环境：为不同环境提供不同的配置读写，提供环境间的配置（命名空间）同步。
集群：假如相同环境中有多个不同集群，需要不同的配置内容，则支持直接新增集群（apollo的环境新增需要部署和接入），同样可以在集群间同步配置。
命名空间：命名为配置文件可能较为直观，有私有及公共两种，公共命名空间可共享给应用去使用，在原处修改后，其他地方同步修改。当然也可以修改覆盖部分项的值，以达到只使用部分配置项的目的。
以上便是apollo对于配置项设置管理的层次划分，由此可见，该层次结构符合多数应用落地部署场景，且较为灵活，能很好得帮助项目人员去对配置进行管理。
参考这个层次结构，和必要的API，其实能很容易地实现我们自身的配置中心平台（当然，直接使用apollo再进行专属改造也是可以的），帮助我们更好地管理应用配置信息。
来源：oschina
链接：https://my.oschina.net/u/3691309/blog/4942291