嘉賓介紹

[[162182]]

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

　　一、前言

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

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

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

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

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

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

　　二、增量部署

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

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

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

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

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

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

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

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

　　三、增量部署與全量部署

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　四、如何選擇部署模式?

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

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