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

[[274435]]

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

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

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

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

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

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

圖2 RESTful微服務(wù)

圖3 message queue微服務(wù)

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

微服務(wù)相對單體式應(yīng)用來說有明顯的好處：

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

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

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

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

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

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

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

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

圖4 Jenkins處理倉庫代碼流程

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

圖5 配置文件示例

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

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

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

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

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

配置文件包就是前面GIT倉庫的CI目錄直接打包而成。

圖6 Bundle示例

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

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

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

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

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

在開始持續(xù)部署的討論之前，我們先描述一下軟件運行注入配置的三個時點：

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

圖9 采用salt進行部署

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

圖10 foreman web界面以及Salt格式

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

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

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

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

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

配置注入部分，讀取配置文件包，通過salt master轉(zhuǎn)換后下發(fā)給目標機。這里用紅框標出了設(shè)計的核心。通過salt的file.recurse和之前持續(xù)部署中打好的配置程序包，并把所有的配置項傳入。可以做到不用對多個配置文件單獨編寫部署邏輯，完全參數(shù)化。

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

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

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

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

圖14 引入ZooKeeper后的流程

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