我们的程序常常有一些配置信息，例如连接的数据库配置、缓存大小、线程数等等。这些配置信息的管理一般有两种方式：
a. 配置信息放到文件中，程序启动时导入，或者在程序运行过程中监控文件的修改重新导入配置文件
b. 公司或者部门范围内构建统一的配置管理系统，应用通过API获取配置服务。
通过配置文件管理配置信息的方式存在一些问题，主要有：
1.部署和更新成本高
当前一个互联网服务常常部署在多台机器上，一个配置的修改，常常涉及到多台机器的修改，运维成本高
2.管理成本高
从开发到上线，我们常常有多个环境，例如开发、测试、预发、线上等。
不同的环境的切换，都需要人力手动修改，成本较高，特别涉及到多个team合作的时候，更容易出现问题，更有甚者将一些线下环境的配置带到线上。这种case也有遇到过。
为此，当公司的服务到达一定规模的时候，构建统一的配置管理系统显得很有必要！
一个配置信息管理系统应该具备的功能包括：
1.提供交互式的配置管理，允许用户对项目的配置进行增删改查。
2.提供统一的配置请求和监听API
当然，在此基础上，一个配置管理系统在稳定性和可靠性要求极高，毕竟，配置服务一旦出现问题，影响是灾难性的！
在此介绍两种不同的构建配置系统的思路
1. Diamond
diamond是淘宝内部使用的一个管理持久配置的系统，它的特点是简单、可靠、易用，目前淘宝内部绝大多数系统的配置，由diamond来进行统一管理。
diamond架构如图：
Diamond的架构非常简单，服务端采用本地文件+集中式mysql的方式保存配置信息，采用tomcat作为运行容器，nginx作为流量控制。
Diamond是典型的集中式设计思想，为保证可用性，其采取的策略包括：
1)diamond-server将配置数据存储在mysql和本地文件中，mysql中为绝对正确的数据，本地文件和mysql容忍一定程度的不一致。用户请求数据时，访问的是Server的本地文件。
2)client每次从server获取到数据后，都会将数据保存在本地文件系统，当整个Server集群不可用时，使用本地数据。
更多Dimond的信息可以参考reference。Dimond已经开源，地址是：http://code.taobao.org/p/diamond/src/
2.基于zookeeper构建
ZooKeeper是Apache Hadoop的一个子项目，其实现的功能与Google的Chubby基本一致，主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
基于zookeeper构建架构图如下所示：
Web UI:用户交互界面，用户可以进行配置的“增删改查”
Zookeeper：配置信息存储中心。负责管理配置数据，配置数据并更时通知相应观察者。
APP：具体应用，向zookeeper请求配置信息，监听配置信息变更
基于zookeeper构建配置管理系统由于zookeeper本身的特点有效的保证了一致性和可靠性！