嘉賓介紹

徐桂林，當前在FIT2CLOUD負責公司的技術布道和生態合作。在此之前先后供職于意法半導體、Autodesk和阿里云。徐桂林熱衷于云計算(尤其是公有云IaaS平臺)，有過多年AWS的生產環境工作經歷，是較早在國內分享AWS上實踐經驗的作者之一。

一、前言

應用部署是工程人員(包括開發、測試和運維)每日面對的重要問題之一。尤其是在應用交付頻率越來越高的當下，工程人員經常需要花費巨大的成本和心血來完成頻繁的應用部署工作。在過去半年里面，我們接觸了大量的企業客戶，他們來自不同的行業，有著不同的規模，但我們發現他們在應用部署上面都有一個類似的困惑，即是應該選擇增量部署還是全量部署。這里，我們希望展開闡述一下我們的觀點。在開始討論這個問題前，讓我們首先重新明確兩個問題。

部署(deployment)還是發布(release)?

部署一般指把應用或者服務“安裝”到目標環境(開發、測試或者生產)中，而發布則應指把應用或者服務交付給最終用戶使用。盡管這兩個動作(尤其是在生產環境中)經常是同時發生的，但它們理應是兩個完全不同的階段。實際上一個好的持續交付流程恰恰應該把“部署”和“發布”解耦，變成兩個可以獨立控制的階段。

部署的內容包括什么?

無論是增量部署還是全量部署，都需要關注其部署的內容是什么，尤其是在廣泛討論微服務的今天。如果從部署角度看，我們把任何可以獨立部署的內容稱為一個“部署單元”。一個部署單元可以是一個模塊，幾個模塊的聯合體或者一個完整的應用，而如何劃分則要視具體場景來定。一般來說，劃分部署單元的最佳實踐為一個可以獨立演化、部署且和應用其他部分松耦合的集合。

在明確完上面兩個問題之后，我們可以把這里要討論的主題更準確的表述為“對一個部署單元應該采用增量還是全量方式進行部署?”

二、增量部署

增量部署一般指在每次部署過程中，首先提取當前版本和即將部署版本之間的增量(包括代碼、可執行文件或者配置等)，并在部署過程中僅更新增量部分。這種部署方式的常見部署流程如下：

1.利用代碼管理工具(SVN、GIT等)提取兩個版本之間的增量，并結合其他方面的增量變化。

2.按照增量部分制定具體的部署方式，編寫部署腳本，并準備增量部署包(包括混淆代碼等)。

3.分發和部署增量部署包到已經運行上一版本的目標環境，完成系統的版本升級。

目前，這種部署方式在不少企業內部使用，尤其是在以動態語言(如PHP、Python、JavaScript等)為主的團隊中使用得更為廣泛。團隊選擇這種部署方式的主要原因可以總結如下：

1.部署速度快。增量部署每次僅對增量部分進行更新，無論是文件分發還是配置更新的內容都會更少，部署需要的時間也就相對較短。

2.減少變化量。增量部署可以減少對于整個系統的變化幅度，很多已經完成的配置工作不需要每次重復設置。從而可以避免誤操作，降低部署失敗率。

3.提高安全性。增量部署每次只會涉及到增量代碼部分，不會直接暴露系統的整個代碼部分更新，避免系統代碼泄露的風險。

三、增量部署與全量部署

在仔細比較這兩種部署方式之前，我們有必要思考一下對一個部署操作來說，哪些考量是最為重要和核心的，也是我們應該優先保證的。在我們看來，一個部署操作最為重要的考量應該是部署操作的“可重復性(repeatable)、可預測性(predictable)和可回滾性(undoable)”，其次才是考慮部署的效率和安全性。之所以這么定義優先級的最主要原因是當下系統部署普遍面臨著下面“三多”挑戰：

1.部署操作次數多。持續交付已經成為企業的普遍追求，也是企業IT服務能力最核心的指標。當部署次數多起來，每次部署的可預測性和可回滾性則是最基礎的保障，不然很難實現頻繁的部署上線。

2.部署環境變化多。企業IT基礎設施的云化和動態化，部署環境已經不僅僅面臨著傳統的開發、測試、預發和生產(DTAP)這四類環境遷移的挑戰，而且每個環境內部基礎設施的變化頻繁得多(增量和全量部署的場景都會頻繁出現和切換)。這對于部署可重復性提出了非常高的要求。

3.部署操作人員多。隨著自動化部署和持續交付的普及，越來越多的人需要有執行部署操作的能力。這不僅包括傳統的開發、測試和運維人員，還包括公司管理人員，甚至市場及銷售人員都需要有自己快速部署一套系統(用于演示或者其他目的)的需求。這也要求部署操作有很好的可預測性和可重復性。

如果對照如上要求，我們會發現“增量部署”在滿足這些需求上有不少的挑戰，具體可以如下分析：

1.增量部署對于任何部署外的更新非常敏感，降低了部署流程的可預期性。

在日常工作中，經常會出現為修復一個問題而臨時修改運行環境的部署外更新，一旦這些部署外更新未及時考慮到增量計算中，非常容易導致之后的增量部署失敗。全量部署過程則會完整執行完整個環境的配置、初始化以及部署工作，對于這些部署外更新有更好的容錯性。

2.增量部署讓回滾操作變得非常不容易。

每次回滾都需要逆向計算增量部分，然后做回滾操作。及時的備份策略有機會降低這個難道，但是如果需要回滾多個版本仍然是一個巨大的挑戰。

3.增量部署無法直接滿足從頭部署最新系統的日常需求。

在云環境中資源的動態變化(尤其是虛機的增加和減少)逐漸會成為一個常態，用戶時刻都可能面對兩種場景的部署要求：從上個版本升級到最新版本，或者從零重新部署最新版本應用。顯然，這兩種部署需求一個增量更新，另一個則是全量更新。

如果團隊以“增量部署”作為日常部署方法，就必然需要面臨維護兩種部署模式，增量部署和全量部署。而如果統一使用“全量部署”則可以避免這個問題，一套部署流程統一兩種不同部署需求，增強部署的可重復性。

如上這些挑戰都讓增量部署模式越來越難滿足高頻部署的工程需求，越來越多的自動化部署系統及工具都選擇了全量部署模式。當然，在選擇全量部署模式時，前面提到的全量部署模式弊端也需要認真考慮。簡單來說，我們可以通過下面這些策略解決或者緩解這些弊端：

1.提前在本地準備好全量部署所需要的所有材料(部署包、配置文件等)后再開始部署操作。這樣可以讓部署操作都變成本地操作，大大提升部署的效率和速度。

2.使用如灰度發布或者負載均衡等方法降低全量部署對于應用可用性影響。同時還能夠有效解耦部署和發布兩個階段，提高應用發布的靈活性。

四、如何選擇部署模式?

如前所述，越來越多的部署系統或者工具都選擇全量部署模式，但這并不意味著增量部署沒有用武之地。相反，很多狀態相關的部署單元(例如數據庫)基本還無法采用全量部署模式，其中最為典型就是“數據庫Schema”的更新操作。對于這里部署需求，工程人員基本只能采取增量部署，并需要小心設計部署的流程、腳本及回滾策略。

總結來說，對于現代系統中絕大部分狀態無關的部署單元(應用、模塊，微服務等)，全量部署一般應是最優的選擇。而狀態相關的部署單元(數據庫等)則依然適合增量部署邏輯。

【編輯推薦】