大數據技術棧之配置&發布系統

前言

今天早上一同事微信說奇虎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