架构设计配置信息管理

26次阅读

共计 1733 个字符,预计需要花费 5 分钟才能阅读完成。

0. 配置信息

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

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

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

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

1. 将配置信息写死在业务代码中

在业务代码中写死配置信息绝对是大部分新手常干的事情。

该策略有以下几个特点:

  1. 配置信息与源码揉在一起,没有进行分离;
  2. 在编译前需要手工修改源码;
  3. 不同环境所使用的 class 文件不同;
  4. 不同环境所部署的 war 包不同;

由于系统可能会被部署在不同的环境中(如开发环境、测试环境、生产环境等),但不同环境之间存在的差异性 (如各个环境的 URL 不同、账号 / 密码不同、单机所允许申请的最大连接数不同等),会使开发人员每次都只能通过修改业务代码的方式进行适应。

在一些比较简单的单元测试场景中,我们可以将配置信息写死在测试代码中。

2. 将配置信息配置到配置文件中

修改源码会破坏系统的稳定性,在大部分情况下,我们都会选择将相关配置信息配置在配置文件中,当系统启动时,会从指定文件进行加载,通过配置文件中的配置信息来完成环境的初始化工作。

此方案存在以下特征:

  1. 完成配置信息与源码的分离;
  2. 不同环境使用相同的 class 文件;
  3. 在打包前,需要对配置信息进行修改;
  4. 不同环境所使用的 war 包不同(class 文件相同,但配置文件不同);

采用配置文件,我们可以很好地将可变的配置信息与业务代码进行解耦。

该方案有个缺陷,就是在发布前需要手工修改配置信息。对此,可以借助构建工具的一些功能进行简化,比如 Maven 的 Filter 功能。

3. 使用 Maven 的 Profile 功能

Maven 的 Profile 功能,可以在打包前完成配置文件的修改。

相对之前方案,只是使用构建工具把手工修改升级为自动配置,对整体方案影响不大。

相信,这应该是使用最普遍的一种配置管理策略。但该方案存在一个问题,每个环境使用不同的部署包,结果便是测试使用的部署包与线上使用的并非 100% 相同。

4. 全环境打包结合运行时配置

如何统一各环境使用的部署包呢?

我们可以使用全环境包结合运行时配置的方式达到统一。

该策略的特征如下:

  1. 将所有环境的配置文件全部打包到发布包中;
  2. 根据启动参数自动加载对应环境的配置信息;

通常的做法是在系统启动时,通过 JVM 的启动参数设置系统属性 (如 java -Denv=”dev”),当系统运行时通过 System 的 getProperty (String Key) 方法获取指定的系统属性值来自动匹配当前环境,并加载配置文件中对应的配置信息,从而避免手动切换。

建议大家在配置文件中预先定义好不同环境所需的配置信息项,并由系统在运行时自动进行匹配和加载。这样一来,从版本提测到最终测试通过,运维人员便可以直接将测试通过后的版本发布到生产环境中。

5. 集中式配置

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

该策略有如下几个特征:

  1. 配置信息存储于 git 中,以此借助其强大的版本管理功能;
  2. 由配置服务统一为系统提供配置信息;
  3. 各环境通过环境变量指定配置服务的地址;

除此以外,配置服务还提供了很多优势:

  1. 配置信息统一管理
  2. 动态获取 / 更新配置信息
  3. 降低运维人员的维护成本
  4. 降低配置出错率

这个方案应该是微服务的标配,现在越来越流行开来。

6. 全环境打包结合集中配置

当然,各种配置管理策略并不是水火不容,我们可以将多种策略结合使用,如将环境打包和集中配置结合使用。

这样,我们可以将敏感信息(数据库连接地址、用户名、密码等)存储在 git 中,进行统一管理;将应用配置存储与配置文件中,由开发人员进行维护。

7. 小结

配置信息管理是系统平稳运行不可或缺的重要组成部分,不同的管理策略,适应于不同的场景,我们需要熟知各种策略的优缺点,根据自身的情况进行选择。

切记,没有最好的方案,只有最适合的方案。

正文完
 0