貝聊架構師林毅：一個可供參考的系統部署工具

阿新 • • 發佈：2018-12-27

說到系統部署工具，大的網際網路公司基本上是自己研發，一鍵自動部署到數百臺到數千臺伺服器, 比如 twitter 開源的 Murder。小的公司可能使用一些開源工具，比如 Jenkins、Puppet、Ansible 結合一些指令碼進行。

開源的部署工具有 Capistrano、瓦力等，線上部署的有 http://dploy.io/。其中瓦力是國人開發的一個系統部署工具。

貝聊之前也使用了瓦力來部署 web 服務和 dubbo 服務，在使用的過程中遇到一些問題：

為了解決使用瓦力遇到的問題，我們決定自己研發一個部署工具。部署工具主要有以下內容：

下面分別就上面的內容做詳細說明。

所有使用部署系統的專案，必須遵循同樣的規範，比如部署的檔案統一放在：

/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) 儲存日誌。

日誌展示的效果圖：

貝聊的服務全部部署在阿里雲，阿里雲有經典網路和 VPC 專有網路，如果所有 IDC 使用 VPC 專有網路 + 高速通道，則比較簡單，因為全部使用內網進行通訊。

如果已經使用了阿里雲經典網路，建議轉換到 VPC 網路，可以降低跨 IDC 的應用架構設計的難度。

目前我們的系統只支援 Java 專案的部署，以後會支援多種語言，並且我們考慮在今年年底把它開源。

作者介紹：林毅，貝聊架構師，10 年以上 Java 開發經驗，先後供職於網易、YY、貝聊等公司，精通分散式 web 系統開發。（原文來自微信公眾號：高效開發運維）