转载

架构设计--配置信息管理

配置信息特指程序启动时对程序进行配置的信息，常见的如服务端口、数据库连接信息、线程池信息等。

在系统启动时，程序会通过不同的配置方案，主动获取配置信息，以完成系统的初始化工作。

因此，配置信息的管理是一件非常重要的事情。

您的配置信息是怎么管理的呢？让我们一起见证下配置信息管理的不同方案。

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. 集中式配置

在分布式环境中，系统往往都是采用集群部署的，那么集群环境中的每一个节点都持有同一份配置文件，一旦配置信息发生改变，就意味着集群环境中的所有配置文件都需要做出相应的调整。而随着系统拆分的粒度越来越细，维护成本将会大大提升，并且配置出错的可能性也随之增加，因此需要一种集中式配置管理形式，以让所有的集群节点共享同一份配置信息。

架构设计--配置信息管理