前言

今天早上一同事微信说奇虎360开源了一套配置管理系统。 地址在这： https://github.com/Qihoo360/QConf 。 正好我们之前也做了一套配管系统，于是点进去看了看，基于Zookeeper做的，恩，我们也是，所以我估计我们实现的方式和他们是一样的。

然后早上的时候和运维聊天，我说到这事，运维同事说希望我介绍下配置&发布系统，说不定会推广到其他部门。

这样，写这个内容就让我一举多得了。

配置&发布系统

我用了 配置 和 发布 两个词。在我们团队中，配置和发布是一个系统，但是，功能和职责是不一样的。

• 配置系统主要是负责配置文件管理，以及提供实时配置生效的功能。
• 发布系统则涉及到服务的部署，升级，日志查看等功能

为什么需要配置&发布系统

数据团队内部的系统其实是很多的，而且机器数也比较多，一般应用服务保证一定会部署在两台以上服务器，然后通过LVS或者Nginx做负载均衡。服务，服务器 一多，配置管理就很麻烦了。虽然内部用的统一的服务框架，目录规划的很好，某台服务器上所有的配置都会放在一个目录，以项目为文件夹构成，里面的配置文件也是统一的。虽然如此，我想没什么人愿意登到服务器上一台一台修改配置吧。

在这个快速迭代的年底，升级系统基本是每天都会进行的事情，天天登陆服务器也是繁琐了，有个发布系统提供Web端做这些事情，能很大的减少错误和人工成本。

配置系统

配置系统应该达到的标准：

1. 配置修改Web化。你可以在Web端界面修改任何一个项目的任何一个配置文件
2. 版本化。每次修改都会作为一个版本被记录下来
3. 兼容早期的以文件形式存在的配置
4. 服务如果使用配置系统的API(或SDK),则配置修改后可得到实时回调通知

另外，在我们的配置系统中，我们服务和机器也是通过配管系统进行关联的。 有一个好处是，你随意指定一个项目，我就知道这些服务被部署在了那些服务器。 这个主要是为了配合发布系统使用。

发布系统

发布系统目标很简单，就是为了简化上线流程。基本模式是根据源代码的tag进行升级或者降级。

我们所有的系统都会在提交代码后，没有问题后再编译打包后，然后统一纳入版本库，打上版本号。

通过发布系统，我们只要指定系统名，填写版本号，则进行相应的版本升级和降级。

为了环保，我们把配置&发布系统 简称为 CCADS (Conf Configure & Application Deploy System)

CCADS实现解析

CCADS需要三部分：

1. zookeeper集群
2. Agent
3. Master
4. SDK

采用Java开发。

关于 Agent 和 Master之间的通讯：

• 配置管理部分无需Agent-Master直接通讯，而是通过zookeeper进行通讯。
• 发布系统则需要Agent-Master 双向通讯。通讯协议采用Akka

SDK 主要是为了和Master 以及 Zookeeper通讯。

CCADS 配置功能大体如下：

1. Mater和Web界面主要是修改zookeeper里的配置内容
2. Agent通过和Zookeeper建立长连，并且会监听zookeeper配置文件的变更，从而更新服务器上对应的配置文件
3. Application(应用)如果使用Agent的SDK包，则也能够监听到zookeeper配置文件的变化

CCADS中初始化项目流程

1. 在部署了Agent的服务器上的一个指定目录(该目录可在启动Agent时指定)里，假设是 /data/auto-configuration，添加一个软链,假设我们添加的是推荐系统

   ls -s /data/configuration/recommend recommend

2. Agent 会定时扫描 /data/auto-configuration目录，如果发现新添加的软链接，则作为一个新的服务添加到zookeeper中，并且会识别recommend下的配置文件，作为zookeeper recommend节点的子节点

3. 接着你在Web端的服务列表中就可以看到新添加的recommend服务了。

CCADS 配置修改流程

1. 修改recommend 下的application.ml文件，填写版本和说明，提交
2. master会检查一些基本的格式问题
3. 通过检查则提交到zookeeper中
4. zookeeper会通知所有Agent这个更改，Agent会对相应的文件进行更新。

如何做到配置动态生效

传统的我们一般都是采用配置文件，如果进行了修改，需要重启服务。你也可以使用我们提供的SDK，通过SDK去订阅zookeeper里相应的节点，在节点变更的时候得到通知。

这个需要服务本身一开始就考虑了这种情况，允许程序得到配置动态更新后，动态更新内存中的属性。

如何实现版本升级&降级

注意，我们内部的系统源码一旦进行了更新，同时也会进行编译和打包，只有这两个动作都做了，才会打上版本号。所以一旦打上版本号，就已经是一个可以直接运行的程序了。

每个服务都在自己的bin目录里提供了 deploy.sh 脚本，该脚本可以重启，升级，停止，启动功能。

发布系统要做的事情就是执行相应的deploy.sh命令，并且将结果回显到Web端界面。

具体内部运作流程如下：

1. 在发布系统界面，从列表中选择recommend服务
2. 操作里点选升级
3. 填写版本号，点击执行
4. Web端会将该请求发送到Master节点上，其中Web端会同时把机器列表也带上
5. Master节点接受到后，会根据机器列表信息将升级指令分发到指定的机器上的Agent上
6. Agent 则执行相应的指令，执行重启任务。
7. Web端会定时不断向Master发起日志查看请求
8. Master则像Slave节点发起日志查看请求
9. Slave定时执行类似 tail 命令，将结果返回给Master
10. Master将日志返回个Web端，Web端展示各个Slave的日志

目前我们还需要能够分析日志来提供报警服务，从而知道那些服务器升级出现了问题。这个功能未来会添加上。

另外也可以通过监控系统来查看是否正常的升级了。比如某个节点里的服务没有被启动，监控系统是能够及时发现的，就不需要发布系统什么事情了。

未来的工作

主要有两个：

1. 优化Web端操作的体验，使得使用起来更舒服些
2. 添加权限管理 
3. 发布系统会加一些增强性功能，比如agent从master下载文件等

来自：http://weibo.com/p/1001603829764321371628