嘉賓介紹

[[162182]]

　　徐桂林，當(dāng)前在FIT2CLOUD負(fù)責(zé)公司的技術(shù)布道和生態(tài)合作。在此之前先后供職于意法半導(dǎo)體、Autodesk和阿里云。徐桂林熱衷于云計算(尤其是公有云IaaS平臺)，有過多年AWS的生產(chǎn)環(huán)境工作經(jīng)歷，是較早在國內(nèi)分享AWS上實踐經(jīng)驗的作者之一。

　　一、前言

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

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

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

　　部署的內(nèi)容包括什么?

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

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

　　二、增量部署

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

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

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

　　3.分發(fā)和部署增量部署包到已經(jīng)運行上一版本的目標(biāo)環(huán)境，完成系統(tǒng)的版本升級。

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

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

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

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

　　三、增量部署與全量部署

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

　　1.部署操作次數(shù)多。持續(xù)交付已經(jīng)成為企業(yè)的普遍追求，也是企業(yè)IT服務(wù)能力最核心的指標(biāo)。當(dāng)部署次數(shù)多起來，每次部署的可預(yù)測性和可回滾性則是最基礎(chǔ)的保障，不然很難實現(xiàn)頻繁的部署上線。

　　2.部署環(huán)境變化多。企業(yè)IT基礎(chǔ)設(shè)施的云化和動態(tài)化，部署環(huán)境已經(jīng)不僅僅面臨著傳統(tǒng)的開發(fā)、測試、預(yù)發(fā)和生產(chǎn)(DTAP)這四類環(huán)境遷移的挑戰(zhàn)，而且每個環(huán)境內(nèi)部基礎(chǔ)設(shè)施的變化頻繁得多(增量和全量部署的場景都會頻繁出現(xiàn)和切換)。這對于部署可重復(fù)性提出了非常高的要求。

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

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

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

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

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

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

　　3.增量部署無法直接滿足從頭部署***系統(tǒng)的日常需求。

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

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

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

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

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

　　四、如何選擇部署模式?

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

　　總結(jié)來說，對于現(xiàn)代系統(tǒng)中絕大部分狀態(tài)無關(guān)的部署單元(應(yīng)用、模塊，微服務(wù)等)，全量部署一般應(yīng)是***的選擇。而狀態(tài)相關(guān)的部署單元(數(shù)據(jù)庫等)則依然適合增量部署邏輯。