說到系統部署工具，大的網際網路公司基本上是自己研發，一鍵自動部署到數百臺到數千臺伺服器,比如twitter開源的Murder。小的公司可能使用一些開源工具，比如Jenkins、Puppet、Ansible結合一些指令碼進行。
開源的部署工具有Capistrano、瓦力等，線上部署的有http://dploy.io/。其中瓦力是國人開發的一個系統部署工具。
貝聊之前也使用了瓦力來部署web服務和dubbo服務，在使用的過程中遇到一些問題：
- 對運維規範支援不夠
- 不能在介面顯示部署失敗的原因
- 讀取tags列表非常慢，經常要多次重新整理，導致部署過程很長
- 如果專案下有N個模組，每次部署此專案下所有的模組，要重複編譯此專案N次（Java專案），很耗時間
- 業務系統多的時候專案列表眼花繚亂
- 不能只部署一部分伺服器
為了解決使用瓦力遇到的問題，我們決定自己研發一個部署工具。
部署工具主要有以下內容：
- 規範和約定
- 專案配置
- 伺服器管理
- 檔案傳輸
- 提高部署效率
- 部署過程的日誌收集
下面分別就上面的內容做詳細說明。
規範和約定
所有使用部署系統的專案，必須遵循同樣的規範，比如部署的檔案統一放在：
/data/project/專案名稱/模組名稱
包括業務日誌目錄、埠範圍、配置檔案等等。
對於一些基礎的JVM引數，部署系統自動檢測並加上，比如gc相關的引數。
專案配置
專案配置包括專案名稱、管理員、專案成員、SVN/Git地址、帳號、服務啟動的shell、自定義指令碼、不同環境的JVM配置、web容器配置等等。
對於web應用，運維在部署系統配置好埠、域名等引數，部署系統自動生成相應的容器配置（Tomcat/Resin等），減少運維的容器配置管理工作，也便於運維規範的執行。
伺服器管理
伺服器管理，在一些公司有CMDB系統來進行管理，功能很複雜。我們的伺服器管理和阿里雲結合，通過它的API讀取伺服器列表，這樣就簡單了。
通過定義伺服器組，可以把不同作用的伺服器分組，方便在部署的時候區分，並且也可以只部署一部分伺服器：
檔案傳輸
伺服器之間的檔案傳輸，常見的方式有scp和rsync。其中scp用於簡單的檔案傳輸，而rsync常用於增量檔案同步。
而同時傳輸檔案到多個伺服器，可以用Puppet、Ansible或類似功能的軟體。我們選擇了Ansible，通過ssh的方式拷貝檔案。如果有多個檔案，先打包成一個檔案，發到目標伺服器再進行解壓，減少網路傳輸的次數。
提交部署效率
為了提高部署的效率，我們做了很多小優化。
- 減少Ansible執行命令次數
Ansible執行命令的速度有點慢，儘量減少Ansible執行命令的次數，比如有多個檔案需要傳送到目標伺服器，打包成一個檔案後再進行傳輸。
- 儲存編譯結果
由於Java程式碼編譯很耗CPU，我們把編譯的工作放到獨立的伺服器，把編譯結果（jar/war檔案）儲存到阿里雲的NAS，方便跨ECS讀取檔案。
為什麼要把編譯結果儲存到NAS？如果一個專案有N個模組，部署新版本的時候，建立類似這樣的部署記錄：
如圖中所示，對於同一個分支，要編譯N次。
假設每次編譯需要30秒，如果不儲存編譯的結果，部署N個模組光是編譯就要 N x 30 秒。儲存編譯結果有利於提高部署的效率。
日誌收集
我們的系統收集Java專案的編譯日誌、執行shell的日誌、業務日誌等。收集這些日誌的目的是為了在web介面上直觀地看到部署過程中的問題。
收集日誌通常使用agent的方式，比如常見的filebeat。
我們使用python實現了agent，每個伺服器上啟動一個，如下圖：
由於只收集部署時的日誌，agent並不需要一直常駐記憶體，在部署的時候啟動agent即可。當agent遇到退出指令，或超過120s沒有日誌的時候自動退出，下次需要再啟動。
如果一次部署幾百臺、幾千臺伺服器的時候，上傳的日誌的TPS是很高的，每個agent可以批量上傳日誌，降低TPS，並且使用NoSQL資料庫(比如Redis)儲存日誌。
日誌展示的效果圖：
跨IDC的處理
貝聊的服務全部部署在阿里雲，阿里雲有經典網路和VPC專有網路，如果所有IDC使用VPC專有網路+高速通道，則比較簡單，因為全部使用內網進行通訊。
如果已經使用了阿里雲經典網路，建議轉換到VPC網路，可以降低跨IDC的應用架構設計的難度。
總體技術架構
業務模型
目前我們的系統只支援Java專案的部署，以後會支援多種語言，並且我們考慮在今年年底把它開源。