0. 配置信息
配置信息特指程序启动时对程序进行配置的信息，常见的如服务端口、数据库连贯信息、线程池信息等。
在系统启动时，程序会通过不同的配置计划，被动获取配置信息，以实现零碎的初始化工作。
因而，配置信息的治理是一件十分重要的事件。
您的配置信息是怎么治理的呢？让咱们一起见证下配置信息管理的不同计划。
1. 将配置信息写死在业务代码中
在业务代码中写死配置信息相对是大部分老手常干的事件。
该策略有以下几个特点：
- 配置信息与源码揉在一起，没有进行拆散；
- 在编译前须要手工批改源码；
- 不同环境所应用的 class 文件不同；
- 不同环境所部署的 war 包不同；
因为零碎可能会被部署在不同的环境中(如开发环境、测试环境、生产环境等)，但不同环境之间存在的差异性 (如各个环境的 URL 不同、账号 / 明码不同、单机所容许申请的最大连接数不同等)，会使开发人员每次都只能通过批改业务代码的形式进行适应。
在一些比较简单的单元测试场景中，咱们能够将配置信息写死在测试代码中。
2. 将配置信息配置到配置文件中
批改源码会毁坏零碎的稳定性，在大部分状况下，咱们都会抉择将相干配置信息配置在配置文件中，当系统启动时，会从指定文件进行加载，通过配置文件中的配置信息来实现环境的初始化工作。
此计划存在以下特色：
- 实现配置信息与源码的拆散；
- 不同环境应用雷同的 class 文件；
- 在打包前，须要对配置信息进行批改；
- 不同环境所应用的 war 包不同（class 文件雷同，但配置文件不同）；
采纳配置文件，咱们能够很好地将可变的配置信息与业务代码进行解耦。
该计划有个缺点，就是在公布前须要手工批改配置信息。对此，能够借助构建工具的一些性能进行简化，比方 Maven 的 Filter 性能。
3. 应用 Maven 的 Profile 性能
Maven 的 Profile 性能，能够在打包前实现配置文件的批改。
绝对之前计划，只是应用构建工具把手工批改降级为主动配置，对整体计划影响不大。
置信，这应该是应用最广泛的一种配置管理策略。但该计划存在一个问题，每个环境应用不同的部署包，后果便是测试应用的部署包与线上应用的并非 100% 雷同。
4. 全环境打包联合运行时配置
如何对立各环境应用的部署包呢?
咱们能够应用全环境包联合运行时配置的形式达到对立。
该策略的特色如下：
- 将所有环境的配置文件全副打包到公布包中；
- 依据启动参数主动加载对应环境的配置信息；
通常的做法是在系统启动时，通过 JVM 的启动参数设置零碎属性 (如 java -Denv=”dev”)，当零碎运行时通过 System 的 getProperty (String Key) 办法获取指定的零碎属性值来主动匹配以后环境，并加载配置文件中对应的配置信息，从而防止手动切换。
倡议大家在配置文件中事后定义好不同环境所需的配置信息项，并由零碎在运行时主动进行匹配和加载。这样一来，从版本提测到最终测试通过，运维人员便能够间接将测试通过后的版本公布到生产环境中。
5. 集中式配置
在分布式环境中，零碎往往都是采纳集群部署的，那么集群环境中的每一个节点都持有同一份配置文件，一旦配置信息产生扭转，就意味着集群环境中的所有配置文件都须要做出相应的调整。而随着零碎拆分的粒度越来越细，保护老本将会大大晋升，并且配置出错的可能性也随之减少，因而须要一种集中式配置管理模式，以让所有的集群节点共享同一份配置信息。
该策略有如下几个特色：
- 配置信息存储于 git 中，以此借助其弱小的版本治理性能；
- 由配置服务对立为零碎提供配置信息；
- 各环境通过环境变量指定配置服务的地址；
除此以外，配置服务还提供了很多劣势：
- 配置信息对立治理
- 动静获取 / 更新配置信息
- 升高运维人员的保护老本
- 升高配置出错率
这个计划应该是微服务的标配，当初越来越风行开来。
6. 全环境打包联合集中配置
当然，各种配置管理策略并不是水火不容，咱们能够将多种策略联合应用，如将环境打包和集中配置联合应用。
这样，咱们能够将敏感信息（数据库连贯地址、用户名、明码等）存储在 git 中，进行对立治理；将利用配置存储与配置文件中，由开发人员进行保护。
7. 小结
配置信息管理是零碎安稳运行不可或缺的重要组成部分，不同的管理策略，适应于不同的场景，咱们须要熟知各种策略的优缺点，依据本身的状况进行抉择。
切记，没有最好的计划，只有最适宜的计划。