说说用xml做配置文件的优劣
最近收到客户的一个需求，要求我们将产品的系统配置数据和业务配置数据定期导出备份，以防万一数据库宕掉后可以用来"救火"。产品从起初0.1版本就一直延续着一种"section-key-value"的配置文件方式，同时我们也有可复用的库来完成配置数据的读取，可是在长期的使用过程中我们发现的不少问题，特别是在存储多样化的业务数据的时候，这样的配置方式带来维护上的很大不便。
"section-key-value"这样的配置文件方式或者类似于环境变量似的配置文件方式用来做系统自己的配置可以说既简单又实用，像著名的Apache服务器、版本控制系统svn等都是采用这种方式。在我们产品的初期，那时的业务相对简单，采用这样的一种配置方式还算是合适的。但随着业务复杂度的上升，种类繁多的业务数据的出现，这种配置方式的弊端渐渐显现。
最大的弊端就是"同步"问题。每当我们的产品升级时，我们一般都会先升级数据库的配置，然后再同步文档，最后同步配置文件以及相关读取代码。如果工作量较大，升级工期较紧的时候，常常忽略了将新增或修改的配置同步到配置文件；这样累积到一定时间之后，除了花费大力气去"补"，别无它法。另外一个弊端就是上面提到的那个问题：从数据库导出配置文件始终是那么"别扭"，曾经尝试过使用脚本导出、Java程序导出，但是始终不能让人很满意，挖掘一下深层原因：配置文件和数据库表设计"不搭调"。业务数据千变万化，导致从数据库导出配置文件的逻辑甚是复杂，维护起来十分不便；而且像"section-key-value"这样的结构，数据库中由于没有section的字串，导致这些section必须"写死"在代码中。
不错，我们在寻找替代品，目标锁定在xml。曾经在2005年做的一个项目中尝试过使用xml作为配置数据，取得了很好的效果。记得当时参考Ant的build.xml的配置方式，顺利解决了一个"自动化处理"的配置设计，那应该是部门第一次采用xml做为后台C实现的系统的配置文件。也是自那以后，我感受到了xml的强大描述能力。xml在Java世界可以说占据了大部江山，从DB导出数据到xml可以说轻而易举，这又恰好解决了本篇所提到的"同步"难题。
坐在公司的Bus上，大致想出了如下xml作为配置文件的好处：
1) 与DB表几乎无缝转换，方便导入导出；
2) 作为元语言，其描述能力毋庸置疑；
3) 在Java世界几乎是配置文件的首选或者说是标准也不过分，选择标准的，总会被支持的很好；
4) 诸多开源工具支持对XML的读写甚至支持加密；
5) 文本形式，方便浏览和信息查找(grep or find均可派得上用场)，这也符合Unix编程艺术(TAOUP)作者在书中阐述的一个原则-尽量文本化。
6) DTD或schema验证，自动验证格式是否OK。
… …
当然缺点也是有的：
1) 如果不加密，是明文，保存账户、密码等数据时要小心，当然这也是文本配置的通病；
2) 如果设计不当，会导致"xml地狱"，xml太多也太烦，很多Java世界的产品就有此弊病。
大致在心里估算了一下，读取xml承载的配置与读取传统的配置的代码量没有太大出入，但是如果xml设计的足够精致，后期的维护工作将大为减少。xml配置改造工作看来势在必行了。
评论