360如何用如何用QConf搞定搞定2W+服务器的配置管理服务器的配置管理
设计初衷
在分布式环境中，出于负载、容错等种种需要，几乎所有的服务都会在不同的机器节点上部署多个实例。而业务项目中又总少
不了各种类型的配置文件。因此，我们常常会遇到这样的问题，仅仅是一个配置内容的修改，便需要重新进行代码提交
SVN/Git、打包、分发上线的全部流程。当部署的机器有很多时，分发上线本身就是一个很繁杂的工作。何况，配置文件的修
改频率又远远大于代码本身。
追本溯源，我们认为麻烦的根源是日常管理和发布过程中不加区分配置和代码造成的。配置本身源于代码，是我们为了提高代
码的灵活性而提取出来的一些经常变化的或需要定制的内容，而正是配置的这种天生的变化特征给我们带了巨大的麻烦。
因此，我们开发了分布式配置管理系统QConf，并依托QConf在360内部提供了一整套配置管理服务，QConf致力于将配置内
容从代码中完全分离出来，及时可靠高效地提供配置访问和更新服务。
整体认识
为了让大家对之后的内容有个直观的认识，先来介绍一下如果你要在自己的项目中使用QConf应该怎么做：
首先，需要在自己的机器上部署QConf，QConf采用cmake构建，非常容易。
mkdir build && cd build
cmake ..
make
make install
其次，通过Zookeeper客户端或QConf管理界面在Zookeeper上建立自己的节点结构，节点完整路径便是QConf的key值，以
360公司内部QConf管理界面为例：
最后，选择自己项目的语言版本的QConf库，并在需要需要获得配置内容的位置，直接调用类似于get_conf(key)这样的接口，
并放心每次取得的都是最新鲜出炉的配置。以shell命令为例：
需要说明的是，使用QConf后已经没有所谓的配置文件的概念，你要做的就是在你需要的地方获取正确的内容。我们认为，这
才是你真正想要的。
架构介绍
了解了QConf的设计初衷和对其有了整体认识之后，相信大家已经有一个对QConf实现的猜想。在介绍架构之前，还需要向大
家申明一下我们对配置信息的定位，因为这个定位直接决定了我们的结构设计和组件选择。
1、单条数据量小
2、更新频繁（较代码而言）
3、配置总数可能巨大，但单台机器关心配置数有限
4、读多写少
进入主题，开始介绍QConf的架构实现，下图展示的是QConf的基本结构，从角色上划分主要包括QConf客户端，QConf服务
端，QConf管理端。
剩余6页未读，继续阅读
资源评论
