系统配置管理系列之二：配置方式的选择

配置方式的是由开发人员决定的，但选择配置方式时需要考虑多个因素，包括开发人员角度的和用户/运维人员角度的。本篇将探讨通常需要考虑的因素，并对上篇提到的几种配置方式进行评估。

影响配置方式选择的因素

读取方式

从开发人员的角度，方便读取配置值的配置方式可以简化程序的代码。最好的读取方式就是能用读取变量的方式读取配置项。显然，命令行参数是最简单的，几乎所有的语言都能将命令行参数作为参数传递给程序。而其他的配置方式都需要特定的访问接口来读取配置项。而大多数的配置方式还需要程序启动的初始化代码对配置环境进行初始化或加载。例如，配置文件需要加载文件，而数据库和服务器则需要连接。这都会增加代码的复杂度和出错的几率。

部署

部署要考虑的问题是，在软件安装，升级和打补丁时，如何获取和设置配置项的值。在第一次安装时，配置项的值从哪来。有的是软件中预设好的，有的则需要从安装环境或安装过程中用户的输入获取。而在升级和打补丁时主要考虑的是如何合并新版本中新增或修改了预设值的配置项和已安装系统中用户设置了新值的配置项。如果简单的使用新版本的配置项值，那每次系统升级或打补丁都会导致用户现有的配置丢失。

常见软件安装工具（如installshield，rpm）都会配置文件进行特殊的处理，如比较修改日期或checksum已判断用户是否做了修改。如果有，则在考新文件前对其进行备份。如果需要更精细的动作（文件内容合并），则需要开发人员写代码（通常是安装脚本）进行处理。这种方式在installshield中也可应用在注册表更新中。

在分布式系统中，情况会更复杂（后面讨论）。

用户接口

用户怎么修改配置值。除非是面向计算机专业人员的软件，所有用户可以修改的配置都应该有相应的UI来完成。但即使是这种面向普通用户的软件并配有相应的UI，能够不使用UI就能方便地修改（至少对开发人员而言）配置也是很重要的，因为这会对程序的调试产生很大的帮助。因为除了用户可以修改的配置，通常程序还有一些隐藏的配置在需要的时候可以通过直接修改来调整系统行为，一个常见的例子就是log的级别设置。正常情况log可能不开或者只开Error级别，以减少产生的log量和对磁盘的压力。但当需要调试时，可能就需要把所有log都打开了。

命令行参数和环境变量是属于操作系统定义的标准的配置方式，本身可以看作是一种UI。配置文件可视为另一种UI。

程序同步

程序同步是指在用户更新配置值后，这个更新如何才能反映到系统的行为上，也就是说程序在什么时候，通过什么方式获取更新后的值并使之生效。如果更改配置的UI和使用配置的程序是同一个进程，那程序获取配置更新会相对容易。但除了获取更新值外，还要把更新反映到系统行为上。无论使用哪种配置方式，都需要应用程序的配合才能做到。例如，如果一个应用程序有一个配置用来设置Server的地址并一直保持与Server的连接，那在该配置项发生变化时，就需要断开现有连接并与新的Server建立连接。

对于配置的修改是在应用程序以外的进程中发生的情况，则需要在应用程序中设置相关的更新通知机制以便及时获知对配置的更改。当然，这也只有在相应的配置能提供通知时才可能。例如，如果使用的是环境变量，应用程序是没有办法获取相应的更改的。

上述是比较理想的情况，现实中很多应用都只是在启动是读取配置，而并不试图同步对配置的更新。要将更新反映到应用程序中，只有重启应用。但重启需要中断应用程序，这在某些情况下是不允许的。

分布式支持

在分布式系统中，多个节点作为一个整体形成一个完整的系统，不同的节点可能作为不同的角色，也可能同一个角色由多个节点承担。从配置的角度来看，就是不同的服务器需要有不同的配置项，也可能不同的服务器需要相同的配置项。除了前面几个因素外，这时还需要考略集中式管理的问题。集中式管理的本质就是用户在一个地方更改了配置后，系统应该将它应用到所有该配置项适用的地方，而无需用户到各个节点上重复设置，以减少工作量和出错的几率。实现集中式管理需要考虑一些问题，将在下一篇文章中探讨。

对几种配置方式的评估

根据上述讨论，下表给出了对上一篇中给出的各种配置方式的粗略评估，比较了各配置方式对不同评估因素的支持程度（高H，中M，低L）。

	读写方式	部署	用户接口	程序同步	分布式支持
命令行参数	H	H	H	L	L
环境变量	H	H	H	L	L
配置文件	M	L	M	M	M
数据库	M	M	L	M	H
配置服务器	L	M	L	H	H

说明：

1. 读写方式主要从程序读取的难易程度和接口的标准化程度进行评估。配置服务器还没有相关的标准或通用方式。
2. 部署主要考虑部署时需要的配置相关的安装脚本的复杂程度。
3. 用户接口主要考虑修改接口是否标准，直接修改是否容易等。

下一篇将详细探讨分布式系统中的配置管理。