XXOps持續發布和部署是怎樣的

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

為什么要先做持續發布和部署？

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

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

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

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

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

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

好的，接下來我們就開始做發布系統了，提煉一下，發布做的事情就是，將提交后的應用代碼，進行編譯打包，然后發布到應用對應IP主機的指定目錄下，并且做到應用服務的優雅上下線（或者叫做優雅啟停）。

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

下面就分階段詳細描述三個主要環節：

代碼提交環節（分支合并管理）

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

描述如下：

1、master分支，跟線上應用代碼保持同步，也就是說隨時可以發布到線上進行部署運行。

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

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

4、從預發進入線上時，會以當前預發環境的發布分支release_pre_xxxx為基線創建一個release_online分支，作為線上的發布分支，線上發布結束后會把release_online分支合并到master中，這也就保證了發布到線上的代碼最終一定會跟master的代碼保持一致。

編譯構建環節

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

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

1、首先準備好JDK的編譯鏡像，這個鏡像環境與線上環境保持一致，當有新的構建任務進來時，就創建一個對應的Docker實例進行代碼編譯；

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

3、對于Java應用，在這個Docker實例環境中，就可以執行mvn package命令打包了，最終會生成一個可發布xxx.war的軟件包；

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

5、構建完成后，Docker實例銷毀；

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

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

部署環節

以上，代碼提交和編譯構建完成后，就該進入發布到線上的部署環節了，也就是將代碼發布到應用對應IP主機的指定目錄下，并且能夠優雅的上下線應用服務，貌似很簡單，但是，看下圖：

這個過程的環節還是比較多的，這些環節內部又會有很多的細節，所以整個部署環節是很復雜的，下面將整體思路介紹一下：

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

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

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

3、將監控關閉，以免服務下線和停止產生誤告警；

4、優雅下線，包含RPC服務從LB下線或Web服務從Nginx下線（如果不提供http服務就不涉及），下線動作均通過API接口調用方式實現；

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

6、優雅上線，進行健康監測，檢查進程和應用狀態是否正常，如果全部監測通過，開始上線服務，開啟監控；

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

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

1、基于場景入手，將業務流程梳理細致，做到細分環節，每步自動化，流程串聯

2、CMDB和應用配置管理的內容，在這一部分無時無處不在發揮著基礎的作用

以上就是XXOps持續發布和部署是怎樣的，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。