XXOps持續(xù)發(fā)布和部署是怎樣的

本篇文章給大家分享的是有關(guān)XXOps持續(xù)發(fā)布和部署是怎樣的，小編覺得挺實用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

為什么要先做持續(xù)發(fā)布和部署？

首先，根本原因還是為了提升代碼的交付效率（好像是句正確的廢話），從技術(shù)上，主要原因還是因為從單體工程拆分成了服務(wù)化的應(yīng)用。

單體工程的歷史原因也很好理解，在創(chuàng)業(yè)初期，技術(shù)人員有限的情況下，為了快速找到正確的業(yè)務(wù)發(fā)展方向，技術(shù)人員必定會把全部的精力放到業(yè)務(wù)需求的實現(xiàn)上，這時技術(shù)或架構(gòu)層面的事情是次要的，且在創(chuàng)業(yè)早期，用戶量和業(yè)務(wù)模型也沒有這么復(fù)雜，也沒有必要搞復(fù)雜的架構(gòu)出來，LNMP足矣，從我們的實踐來看這樣的技術(shù)選擇是無比正確的。

但是，隨著業(yè)務(wù)量和業(yè)務(wù)復(fù)雜度的增加（如電商的用戶、商家、店鋪、商品、交易和支付體系），業(yè)務(wù)服務(wù)質(zhì)量要求變得越來越苛刻（低時延、高可用），需求的交付周期卻要求越來越短（腦補下產(chǎn)品經(jīng)理站在程序員身后的場景），同時工程師數(shù)量也已經(jīng)到了幾百人規(guī)模，這時單體工程就暴露出很多問題，比如代碼邏輯耦合嚴(yán)重、底層公共方法不敢動，代碼量巨大已經(jīng)沒有任何一個人能對整個工程代碼熟悉，上百個工程師同時向同一個工程提交代碼，代碼維護(hù)耗費的精力非常大。最終一張圖看下當(dāng)時的場景：

所以，解決方案向著Java服務(wù)化的方向演進(jìn)（具體原因就不解釋了），簡單示意如下：

單體應(yīng)用拆分成服務(wù)化應(yīng)用后，應(yīng)用的情況就變成了許許多多、大大小小的應(yīng)用模式，下圖示意：

這個時候遇到的最棘手的問題，就是發(fā)布問題，這么多的應(yīng)用對應(yīng)的代碼都是不同的，且Java服務(wù)化之后涉及編譯構(gòu)建、服務(wù)優(yōu)雅上下線等一系列等問題，環(huán)節(jié)也多了很多（后面會看到），這些環(huán)節(jié)單純的靠手工執(zhí)行腳本和人為的串聯(lián)已經(jīng)成為不可能的事情，這個直接影響到開發(fā)、測試和運維整個研發(fā)體系的效率，所以是擺在面前必須要首要解決的。

好的，接下來我們就開始做發(fā)布系統(tǒng)了，提煉一下，發(fā)布做的事情就是，將提交后的應(yīng)用代碼，進(jìn)行編譯打包，然后發(fā)布到應(yīng)用對應(yīng)IP主機(jī)的指定目錄下，并且做到應(yīng)用服務(wù)的優(yōu)雅上下線（或者叫做優(yōu)雅啟停）。

理解起來不復(fù)雜，其實我們可以抽象出發(fā)布的最重要的三步，我們也是始終圍繞著這三步在不斷的完善，如下：

下面就分階段詳細(xì)描述三個主要環(huán)節(jié)：

代碼提交環(huán)節(jié)（分支合并管理）

代碼管理工具是Gitlab，代碼提交過程中最重要的就是對于分支合并的管理（這里又涉及到標(biāo)準(zhǔn)規(guī)范的制定），我們的策略示意大致如下：

描述如下：

1、master分支，跟線上應(yīng)用代碼保持同步，也就是說隨時可以發(fā)布到線上進(jìn)行部署運行。

2、開發(fā)分支，通常以feature/defect來表示，比如開發(fā)一個新的需求，就會以當(dāng)前master為基線，拉一個feature分支出來進(jìn)行開發(fā)，同一個應(yīng)用可以同時存在多個feature分支并行開發(fā)。

3、發(fā)布分支，以release表示，在發(fā)布時會將所有提交集成的代碼commit合并，形成release_環(huán)境_時間戳為分支名稱，比如release_dev_01_29_20_52_10 就代表該分支是在1月29號20:52:10在dev環(huán)境發(fā)布時創(chuàng)建的臨時發(fā)布分支。

4、從預(yù)發(fā)進(jìn)入線上時，會以當(dāng)前預(yù)發(fā)環(huán)境的發(fā)布分支release_pre_xxxx為基線創(chuàng)建一個release_online分支，作為線上的發(fā)布分支，線上發(fā)布結(jié)束后會把release_online分支合并到master中，這也就保證了發(fā)布到線上的代碼最終一定會跟master的代碼保持一致。

編譯構(gòu)建環(huán)節(jié)

上面講完了代碼提交環(huán)節(jié)，下一個環(huán)節(jié)就是要構(gòu)建了，以Java為例，構(gòu)建我們用到了兩個工具，Docker和Maven。Docker主要用來提供一個干凈獨立的編譯環(huán)境，Maven作為我們的依賴管理和打包工具。整個構(gòu)建過程如下：

以Java為例，簡單描述如下：

1、首先準(zhǔn)備好JDK的編譯鏡像，這個鏡像環(huán)境與線上環(huán)境保持一致，當(dāng)有新的構(gòu)建任務(wù)進(jìn)來時，就創(chuàng)建一個對應(yīng)的Docker實例進(jìn)行代碼編譯；

2、構(gòu)建任務(wù)會根據(jù)應(yīng)用配置管理中的Git地址，將代碼clone下來放到指定的編譯目錄，Docker實例啟動后，將編譯目錄掛在到Docker實例中；

3、對于Java應(yīng)用，在這個Docker實例環(huán)境中，就可以執(zhí)行mvn package命令打包了，最終會生成一個可發(fā)布xxx.war的軟件包；

4、同樣的，對于C++，Go、NodeJs，也會準(zhǔn)備好類似的編譯鏡像，不同的是打包時，對于C++是cmake&make，Go就是go install等等，最終也會生成一個可發(fā)布的軟件包；

5、構(gòu)建完成后，Docker實例銷毀；

這里面Docker發(fā)揮了一個很大的作用，就是提供了干凈的，互不干擾的編譯環(huán)境，且對于并發(fā)打包的情況，Docker快速創(chuàng)建多個并行的實例出來提供編譯環(huán)境，使用完銷毀，這個效率上的優(yōu)勢也是非常大的。

6、關(guān)于配置管理，當(dāng)時設(shè)計時考慮比較簡單，我們的做法是同時做三個配置文件出來，dev_pom.xml，pre_pom.xml，online_pom.xml，分別對應(yīng)開發(fā)、預(yù)發(fā)和線上三個不同的環(huán)境，根據(jù)發(fā)布的環(huán)境不同，將不同的配置文件替換上去。這樣做其實可擴(kuò)展性不夠，對于多機(jī)房、多分組的情況會有更多的配置文件創(chuàng)建出來，且對于有敏感信息的配置項保密也不夠（不過這些配置都已經(jīng)加密挪到中間件的配置中心了），更好的辦法可以考慮采用阿里早已開源的auto-config方案，這里就不細(xì)講了。

部署環(huán)節(jié)

以上，代碼提交和編譯構(gòu)建完成后，就該進(jìn)入發(fā)布到線上的部署環(huán)節(jié)了，也就是將代碼發(fā)布到應(yīng)用對應(yīng)IP主機(jī)的指定目錄下，并且能夠優(yōu)雅的上下線應(yīng)用服務(wù)，貌似很簡單，但是，看下圖：

這個過程的環(huán)節(jié)還是比較多的，這些環(huán)節(jié)內(nèi)部又會有很多的細(xì)節(jié)，所以整個部署環(huán)節(jié)是很復(fù)雜的，下面將整體思路介紹一下：

0、從CMDB中，拿到應(yīng)用-主機(jī)IP對應(yīng)關(guān)系，然后再從1開始做，后面的過程可以是針對單臺機(jī)器做，也可以是分批或分組多臺機(jī)器同時做。（從第0步開始，原因就是我們上一篇文章里面說的CMDB和應(yīng)用配置管理的基礎(chǔ)要先打好，這個基礎(chǔ)沒有，下面的環(huán)節(jié)就無法順暢地執(zhí)行）；

1、檢查每臺機(jī)器上的服務(wù)是否正常運行的，如果是正常服務(wù)的，說明可以發(fā)布，但是服務(wù)本身異常，就要記錄或跳過了；

2、下載war包到指定目錄（應(yīng)用的目錄信息，應(yīng)用配置管理又發(fā)揮作用了）；

3、將監(jiān)控關(guān)閉，以免服務(wù)下線和停止產(chǎn)生誤告警；

4、優(yōu)雅下線，包含RPC服務(wù)從LB下線或Web服務(wù)從Nginx下線（如果不提供http服務(wù)就不涉及），下線動作均通過API接口調(diào)用方式實現(xiàn)；

5、下線后自動檢測無新的流量進(jìn)入，停止應(yīng)用，發(fā)布代碼，然后啟動應(yīng)用（這時應(yīng)用配置管理里面，啟停命令等等就又發(fā)揮作用了）；

6、優(yōu)雅上線，進(jìn)行健康監(jiān)測，檢查進(jìn)程和應(yīng)用狀態(tài)是否正常，如果全部監(jiān)測通過，開始上線服務(wù)，開啟監(jiān)控；

7、分批發(fā)布，這里簡單提一下，假設(shè)我們一個應(yīng)用有100臺主機(jī)，這個時候做發(fā)布不可能全部一把停掉，這樣服務(wù)會中斷，但是也不能一臺臺的做，這樣效率又太低，所以我們可以折中分批發(fā)，比如可以分5批，每批20臺，也可以分10批，每批10臺，這樣既可以保證在線升級，也可以保證效率能夠跟的上。當(dāng)然復(fù)雜一點，還有分組分批，或者按步長分批，第一批5臺，第二批10臺，后面每批20臺等等。示例如下：

整個過程下來我們可以看到：

1、基于場景入手，將業(yè)務(wù)流程梳理細(xì)致，做到細(xì)分環(huán)節(jié)，每步自動化，流程串聯(lián)

2、CMDB和應(yīng)用配置管理的內(nèi)容，在這一部分無時無處不在發(fā)揮著基礎(chǔ)的作用

以上就是XXOps持續(xù)發(fā)布和部署是怎樣的，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降摹ＯＭ隳芡ㄟ^這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。