本文介紹了如何利用開(kāi)源軟件快速搭建一套微服務(wù)的持續(xù)交付系統(tǒng)。本文假設(shè)的環(huán)境是Linux操作系統(tǒng)，用到的軟件包括Git、Jenkins、Salt、ZooKeeper、Apache等。開(kāi)始之前，我先簡(jiǎn)單介紹下持續(xù)交付和微服務(wù)的概念，以便大家更好的理解本文的精華。

[[274435]]

什么是持續(xù)交付?我們先舉個(gè)物流的例子，現(xiàn)在各大電商都非常重視物流的自動(dòng)化建設(shè)，在實(shí)現(xiàn)包括運(yùn)輸、裝卸、包裝、分揀、識(shí)別等作業(yè)過(guò)程的設(shè)備和設(shè)施自動(dòng)化的同時(shí)，更在研究無(wú)人機(jī)和自動(dòng)駕駛汽車送貨，達(dá)到物流的全自動(dòng)。

那么軟件開(kāi)發(fā)呢，從開(kāi)發(fā)人員check in代碼到代碼倉(cāng)庫(kù)，到代碼的構(gòu)建、部署、測(cè)試、發(fā)布，我們可以形象地把這個(gè)過(guò)程稱為“軟件物流”，現(xiàn)實(shí)世界的物流實(shí)現(xiàn)了相當(dāng)?shù)淖詣?dòng)化，“軟件物流”也應(yīng)如是，實(shí)現(xiàn)從開(kāi)發(fā)人員check in代碼(客戶下單)到生產(chǎn)系統(tǒng)上線(送貨上門(mén))的自動(dòng)化。

說(shuō)到這里，我們可以給持續(xù)交付下一個(gè)“非專業(yè)”的定義，持續(xù)交付就是實(shí)現(xiàn)“軟件物流”的自動(dòng)化。

圖1.持續(xù)交付流水線

圖1摘自《持續(xù)交付：發(fā)布可靠軟件的系統(tǒng)方法》，展示了持續(xù)交付具體包括的內(nèi)容。本文重點(diǎn)討論如何實(shí)現(xiàn)微服務(wù)的持續(xù)交付流程，所以會(huì)忽略掉整個(gè)流程的一些細(xì)節(jié)(如代碼分析、單元測(cè)試等等)。

那什么是微服務(wù)呢?微服務(wù)的概念最初由Martin Fowler與James Lewis于2014年共同提出，微服務(wù)架構(gòu)風(fēng)格是一種使用一套小服務(wù)來(lái)開(kāi)發(fā)單個(gè)應(yīng)用的方式途徑，每個(gè)服務(wù)運(yùn)行在自己的進(jìn)程中，并使用輕量級(jí)機(jī)制通信，通常是HTTP API，這些服務(wù)基于業(yè)務(wù)能力構(gòu)建，并能夠通過(guò)自動(dòng)化部署機(jī)制來(lái)獨(dú)立部署，這些服務(wù)使用不同的編程語(yǔ)言書(shū)寫(xiě)，以及不同數(shù)據(jù)存儲(chǔ)技術(shù)，并保持最低限度的集中式管理。目前微服務(wù)的主流實(shí)現(xiàn)方式有兩種：RESTful API和消息隊(duì)列。

圖2 RESTful微服務(wù)

圖3 message queue微服務(wù)

圖2、圖3是兩種典型微服務(wù)架構(gòu)的簡(jiǎn)略圖。當(dāng)然現(xiàn)實(shí)中的系統(tǒng)會(huì)復(fù)雜的多，比如會(huì)有微服務(wù)聚合，多級(jí)緩存，注冊(cè)中心等。

微服務(wù)相對(duì)單體式應(yīng)用來(lái)說(shuō)有明顯的好處：

1. 解決了單體式應(yīng)用的復(fù)雜性問(wèn)題，單個(gè)微服務(wù)很容易開(kāi)發(fā)、理解和維護(hù)。
2. 每個(gè)微服務(wù)都可以由獨(dú)立的團(tuán)隊(duì)來(lái)開(kāi)發(fā)，可以自由選擇開(kāi)發(fā)語(yǔ)言。
3. 每個(gè)微服務(wù)可以獨(dú)立部署，系統(tǒng)可以快速演進(jìn)。
4. 可以對(duì)每個(gè)微服務(wù)進(jìn)行獨(dú)立擴(kuò)展，極大的提高系統(tǒng)伸縮性及資源利用率。

但在一個(gè)單體式應(yīng)用拆分成數(shù)十個(gè)乃至上百個(gè)微服務(wù)，由于服務(wù)數(shù)量的增加，以及微服務(wù)支持多種編程語(yǔ)言的特性，對(duì)軟件的構(gòu)建，部署，測(cè)試，監(jiān)控都帶來(lái)了全新的挑戰(zhàn)。本文將討論如何通過(guò)持續(xù)交付來(lái)降低微服務(wù)構(gòu)建，部署的復(fù)雜度。

微服務(wù)的持續(xù)交付：統(tǒng)一方法

由于微服務(wù)的特性，微服務(wù)的持續(xù)交付會(huì)比單體式應(yīng)用的持續(xù)交付復(fù)雜的多。本節(jié)列出了為了降低微服務(wù)持續(xù)交付的復(fù)雜度，我們遵循的一些原則：

1. 統(tǒng)一方法。這里有兩個(gè)層面的含義，第一是流程的統(tǒng)一，有很多公司對(duì)運(yùn)維自動(dòng)化非常重視，但在開(kāi)發(fā)，測(cè)試階段沒(méi)有采用自動(dòng)化的方法。隨著DevOPS運(yùn)動(dòng)的興起，大家逐漸意識(shí)到需要在開(kāi)發(fā)，測(cè)試階段采用與生產(chǎn)環(huán)境相同的交付方法，這樣在系統(tǒng)部署到生產(chǎn)環(huán)境的時(shí)候，這一交付流程已經(jīng)經(jīng)過(guò)多次的檢驗(yàn)，出錯(cuò)的概率大大降低了。第二層含義與微服務(wù)相關(guān)，各個(gè)微服務(wù)可能用不同的語(yǔ)言實(shí)現(xiàn)，如Java、Python、C++、Golang、純前端(JavaScript)，我們要對(duì)采用不同語(yǔ)言實(shí)現(xiàn)的微服務(wù)使用統(tǒng)一的交付方法。
2. 在版本控制系統(tǒng)中，每個(gè)微服務(wù)應(yīng)該對(duì)應(yīng)一個(gè)獨(dú)立的倉(cāng)庫(kù)。以Git為例，一個(gè)Project下面，每個(gè)微服務(wù)對(duì)應(yīng)一個(gè)獨(dú)立Repository。這樣各個(gè)微服務(wù)可以獨(dú)立check in代碼，而不會(huì)在持續(xù)構(gòu)建的時(shí)候互相影響。
3. 設(shè)計(jì)持續(xù)交付系統(tǒng)時(shí)要考慮實(shí)現(xiàn)軟件交付的全自動(dòng)化，雖然在現(xiàn)實(shí)中，會(huì)存在提交測(cè)試，生產(chǎn)變更審核等人工環(huán)節(jié)。但在理想情況下，開(kāi)發(fā)人員check in 代碼之后，能夠自動(dòng)觸發(fā)構(gòu)建，多套環(huán)境的部署及測(cè)試。
4. 支持單個(gè)微服務(wù)升降級(jí)，這要求持續(xù)交付系統(tǒng)，對(duì)每個(gè)可部署的單元(微服務(wù))要有獨(dú)立的版本號(hào)。
5. 程序與配置分離。要支持一套程序(可執(zhí)行包+配置文件包)多處部署，這里強(qiáng)調(diào)了一套程序，是指在開(kāi)發(fā)人員check in代碼后，構(gòu)建系統(tǒng)只生成一份程序(可執(zhí)行包+配置文件包)。不管是部署到開(kāi)發(fā)環(huán)境，測(cè)試環(huán)境，還是生產(chǎn)環(huán)境我們要用同一套程序，而不是對(duì)每個(gè)環(huán)境單獨(dú)打包。我們知道Java war包會(huì)要求把配置文件包含在里面，這會(huì)造成不同的環(huán)境要求提供不同的war包，這就違反了我們說(shuō)的這個(gè)原則，后面我們會(huì)討論如何處理這個(gè)問(wèn)題。
6. 在應(yīng)用程序部署時(shí)，不得依賴外網(wǎng)資源。我們把部署過(guò)程獨(dú)立為兩個(gè)階段：環(huán)境準(zhǔn)備階段和應(yīng)用程序部署階段。環(huán)境準(zhǔn)備包括操作系統(tǒng)，JDK或其他語(yǔ)言運(yùn)行時(shí)系統(tǒng)級(jí)依賴庫(kù)的安裝，得益于IaaS的相對(duì)成熟，我們把這一階段獨(dú)立出來(lái)。而應(yīng)用的部署需要定制化，也是本文討論的部分。在部署應(yīng)用時(shí)，要求所有的資源從內(nèi)網(wǎng)獲得，這樣可以保證應(yīng)用部署過(guò)程的快速、穩(wěn)定、可重復(fù)。

快速搭建微服務(wù)的持續(xù)交付：持續(xù)構(gòu)建

下面我們結(jié)合一個(gè)虛構(gòu)的項(xiàng)目來(lái)介紹持續(xù)交付的實(shí)現(xiàn)細(xì)節(jié)，假設(shè)我們有一個(gè)項(xiàng)目BetaCat，由ms1、ms2…msN，n個(gè)微服務(wù)構(gòu)成。下面我們重點(diǎn)介紹ms1微服務(wù)如何實(shí)現(xiàn)持續(xù)交付，其它微服務(wù)可以類推。

本節(jié)討論下如何實(shí)現(xiàn)持續(xù)構(gòu)建，下一節(jié)會(huì)探討持續(xù)部署。

圖4 Jenkins處理倉(cāng)庫(kù)代碼流程

如圖4所示，開(kāi)發(fā)人員check in 代碼到Git倉(cāng)庫(kù)后，Jenkins會(huì)自動(dòng)地進(jìn)行構(gòu)建工作，并把打好的包上傳到Repo server上。

圖5 配置文件示例

作為統(tǒng)一方法的一部分，我們?cè)诿總€(gè)微服務(wù)倉(cāng)庫(kù)上創(chuàng)建了CI目錄，用于配置文件的打包，在CI目錄里，只放入需要參數(shù)化的配置文件，執(zhí)行腳本等，并會(huì)嚴(yán)格遵循原有系統(tǒng)的目錄結(jié)構(gòu)，如圖5所示，我們要求有start.sh、stop.sh及service(用于Linux的init啟停該微服務(wù))。

圖5中配置文件參數(shù)化內(nèi)容，參數(shù)部分用”{{“與”}}”包圍起來(lái)，在持續(xù)部署的時(shí)候會(huì)根據(jù)傳入的參數(shù)替換為特定的值。

我們還定義了持續(xù)構(gòu)建的統(tǒng)一輸出，對(duì)每個(gè)微服務(wù)采用tgz的打包格式，微服務(wù)ms1持續(xù)構(gòu)建的輸出文件示例如下:

• ms1-1.0.7.tgz (可執(zhí)行包)
• ms1_config-1.0.7.tgz(配置文件包)

在可執(zhí)行包里面要求把所有的依賴庫(kù)(除了系統(tǒng)lib庫(kù))都包含在里面，對(duì)不同編程語(yǔ)言的微服務(wù)的構(gòu)建工具沒(méi)有強(qiáng)制要求，統(tǒng)一由Jenkins調(diào)用。C/C++我們推薦使用CMake，Java一般用Maven，Python直接打包。

配置文件包就是前面GIT倉(cāng)庫(kù)的CI目錄直接打包而成。

圖6 Bundle示例

同時(shí)為了在部署時(shí)不用具體指定每個(gè)微服務(wù)的版本號(hào)，我們引入了bundle的概念，如圖6。在任何一個(gè)微服務(wù)構(gòu)建之后，會(huì)觸發(fā)bundle，sha512校驗(yàn)文件生成，并上傳到Repo Server。

最后讓我們看下持續(xù)交付上傳到Repo Server的目錄結(jié)構(gòu)：

圖7 目錄結(jié)構(gòu)

這樣持續(xù)構(gòu)建的工作就完成了，接下來(lái)就需要進(jìn)行持續(xù)部署了。

快速搭建微服務(wù)的持續(xù)交付：持續(xù)部署

在開(kāi)始持續(xù)部署的討論之前，我們先描述一下軟件運(yùn)行注入配置的三個(gè)時(shí)點(diǎn)：

圖8 配置注入的三個(gè)時(shí)間點(diǎn)打包時(shí)點(diǎn)，典型的是Java的war包，會(huì)把配置文件打包在一起。部署時(shí)點(diǎn)，在部署的時(shí)候利用專門(mén)的部署工具更新配置文件，這也是我們采用的方法;運(yùn)行時(shí)點(diǎn)，程序運(yùn)行時(shí)通過(guò)環(huán)境變量或注冊(cè)中心/配置中心獲得配置信息，如用Docker部署微服務(wù)時(shí)就要考慮通過(guò)這種方法來(lái)獲得所需要的配置信息。

圖9 采用salt進(jìn)行部署

圖9顯示了我們對(duì)不同的環(huán)境統(tǒng)一采用salt進(jìn)行部署。由于我們支持用戶只輸入bundle的版本信息來(lái)實(shí)現(xiàn)部署，這就要求在持續(xù)部署的時(shí)候，部署系統(tǒng)能自動(dòng)獲取每個(gè)微服務(wù)的版本號(hào)，為此我們對(duì)salt/foreman做了一點(diǎn)小改動(dòng)，修改后返回的pillar格式包含各個(gè)微服務(wù)的版本，同時(shí)下載并解壓對(duì)應(yīng)的配置文件包到salt master的相應(yīng)目錄，以及關(guān)閉salt master file_list緩存：fileserver_list_cache_time: 0。

圖10 foreman web界面以及Salt格式

圖10左邊表示我們?cè)趂oreman web界面上設(shè)置的參數(shù)，右邊表示通過(guò)salt pillar.items取得的格式，可以看到多了每個(gè)微服務(wù)的版本號(hào)信息。

下面我們按照部署三部曲(安裝、配置注入、服務(wù)運(yùn)行)來(lái)介紹部署規(guī)則文件(saltstate、sls文件)的編寫(xiě)：

1、betacat_ms1.sls 第一部分：安裝

在這一部分，檢查并創(chuàng)建安裝目錄，下載需要的可執(zhí)行包，并解壓到正確的位置，可執(zhí)行包直接從Repo Server獲取，并通過(guò)sha512驗(yàn)證文件的完整性。

2、betacat_ms1.sls 第二部分：配置注入

配置注入部分，讀取配置文件包，通過(guò)salt master轉(zhuǎn)換后下發(fā)給目標(biāo)機(jī)。這里用紅框標(biāo)出了設(shè)計(jì)的核心。通過(guò)salt的file.recurse和之前持續(xù)部署中打好的配置程序包，并把所有的配置項(xiàng)傳入?？梢宰龅讲挥脤?duì)多個(gè)配置文件單獨(dú)編寫(xiě)部署邏輯，完全參數(shù)化。

3、betacat_ms1.sls 第三部分：服務(wù)運(yùn)行

在這一部分，確保微服務(wù)在運(yùn)行狀態(tài)，并在必要的時(shí)候重啟。這里需要特別指出的一點(diǎn)，在整個(gè)sls文件中，對(duì)不同的微服務(wù)來(lái)說(shuō)，只有3個(gè)元參數(shù)：項(xiàng)目名稱(BeatCat)、微服務(wù)名稱(ms1)以及sig(ms1, 微服務(wù)進(jìn)程的唯一識(shí)別字符串)。那么我們可以通過(guò)簡(jiǎn)單的腳本來(lái)自動(dòng)生成sls文件，而不需要手工編寫(xiě)。大大降低持續(xù)部署的開(kāi)發(fā)維護(hù)成本。

快速搭建微服務(wù)的持續(xù)交付：全自動(dòng)化

為了支持持續(xù)交付流程的全自動(dòng)化，我們引入了ZooKeeper，如圖14。

圖14 引入ZooKeeper后的流程

1. 代碼check in 到Git后，觸發(fā)構(gòu)建，Jenkins會(huì)把打好的包上傳到Repository Server，并更新ZooKeeper的本次及l(fā)atest包版本信息。
2. 偵聽(tīng)到ZooKeeper的latest包版本信息變動(dòng)后，會(huì)觸發(fā)saltstack的部署命令向各個(gè)環(huán)境部署最新的程序。
3. 部署完畢，會(huì)更新ZooKeeper上的目標(biāo)機(jī)部署版本信息。
4. 偵聽(tīng)到ZooKeeper上的目標(biāo)機(jī)部署版本信息變動(dòng)后，會(huì)觸發(fā)一套或多套自動(dòng)化測(cè)試腳本的運(yùn)行。
5. 自動(dòng)化測(cè)試通過(guò)后，會(huì)更新ZooKeeper上的包版本的測(cè)試信息。
6. 通過(guò)測(cè)試的包，可以自動(dòng)上傳到生產(chǎn)環(huán)境的repo server，并更新生產(chǎn)環(huán)境ZooKeeper的包版本信息。
7. 生產(chǎn)環(huán)境，偵聽(tīng)到ZooKeeper的包版本信息變動(dòng)后，會(huì)觸發(fā)生產(chǎn)環(huán)境的部署。
8. 生產(chǎn)環(huán)境部署完畢，會(huì)更新ZooKeeper上的目標(biāo)機(jī)部署版本信息。