基于微服務的DevOps研究與實現

■ 河北移動 魏春來 付永振

編者按：微服務的應用將帶來大量問題，比如單體如何拆分成多個微服務，分布式事務問題，依賴管理變得復雜，測試更加困難，故障更難于定位等等，本文將探討適配企業客戶IT運維和開發現狀與環境的綜合解決方法。

基于微服務的DevOps研究意義

微服務能解決單體應用及SOA帶來的問題，但是微服務也會帶來問題。微服務所面對的問題需要一個適配企業客戶IT運維和開發現狀與環境的綜合解決方法。

基于微服務的DevOps運營體系，通過持續集成、持續交付和持續部署（CI/CD）的方法，梳理敏捷開發流程，將開代碼、構建、測試等環節由線下轉為線上，為企業提供軟件持續集成發布平臺。通過軟件持續集成發布平臺可提升企業軟件交付的效率。

基于微服務的DevOps功能實現

1.技術背景

（1）容器云下的微服務管控（CAAS）

圖1 微服務管控邏輯架構

雖然微服務不需要使用容器來實現，但同時使用微服務與容器這兩種技術是有益的。當使用容器時，軟件所需要的所有東西都被打包成獨立的、輕量級的捆綁包，使部署和操作更加容易。使用Kubernetes開源系統，用于自動化容器應用程序的部署、擴展和管理。微服務管控邏輯架構如圖1所示。

（2）CaaS在DevOps體系中所處位置

持續集成是一種軟件開發實踐，即團隊開發成員經常集成它們的工作，通過每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試）來驗證，從而盡早地發現集成錯誤。

持續部署是通過自動化的構建、測試和部署循環來快速交付高質量的產品。某種程度上代表了一個開發團隊工程化的程度，畢竟快速運轉的互聯網公司人力成本會高于機器，投資機器優化開發流程化也相對提高了人的效率。

持續集成、持續交付和持續部署提供了優秀的DevOps環境，而微服務管控是DevOps環境實現的基礎。微服務管控（CAAS）在DevOps體系中所處位置。

2.業務需求

按DevOps運營體系建設打造整體全面的平臺能力，主要包含環境管理、構建庫管理、集成管理、部署流水線、測試管理、自動化管理、調度管理、應用資源管理、發布監控管理和交付看板管理等內容。重點放在開發流水線、測試流水線和發布流水線等自動化能力。

3.業務實現

持續集成發布平臺應由五部分組成：CI模塊、CAAS模 塊、CSA模 塊、ATP模 塊和DevOps Dashboard。 其中CI模塊為持續集成模塊，內 部 由 Jenkins、SVN、GIT、Maven、Sornarqube等 構 件封裝而成，用于支持持續集成過程中的各項活動；CAAS模塊為持續發布模塊，主要基于Kubernetes及其它開源項目商業化封裝而成，用于支持持續交付過程中的各項活動，并且為測試環境、準發布環境提供基礎運行環境（容器云）；CSA模塊為持續部署模塊，主要基于Ansible商業封裝后構建而成，用于支持測試環境/準發布環境向生產環境（非容器環境）遷移部署過程中的活動；ATP模塊為自動化測試模塊，用于支持集成測試、自動化功能測試以及性能測試過程；最后DevOps Dashboard則是面向用戶使用設計的統一界面，通過該界面對其它平臺提供的功能進行能力封裝，使其具備流水線自由編排及調度的功能。CI/CD過程的業務執行邏輯如圖2所示。

圖2 CI/CD過程的業務執行邏輯

（1）流水線定義流水線模板包括開發流水線、測試流

水線和發布流水線，包含代碼構建，內置jenkins集成，可對接 git、svn軟件代碼倉庫，自動化打包管理，版本管理，實現開發集群的自動化部署。各流水線模板涵蓋的持續集成與發布動作如表1。

4.用戶與平臺的交互

為了清晰描述用戶如何通過持續集成發布平臺實現敏捷開發與交付過程，本節將對用戶與平臺的交互過程進行詳細論述：

（1）開發流水線

第一步：研發人員向代碼庫提交代碼。研發人員在完成代碼單元的編寫后，可以通過IDE插件向SVNGITGITHUB提交代碼，提交時需要一并提交maven工程文件、源碼、數據庫DDLDML文件等，代碼庫會根據其類型自動歸類；

表1 流水線模板

第二步：Jenkins抽取代碼。開發經理根據現場需求設置Jenkins的持續集成條件，包括代碼提交觸發、定時觸發、腳本觸發等。Jenkins會根據條件自動從代碼倉庫中拉取代碼到本地；

第三步：代碼編譯。Jenkins將調用Maven組件對已抽取到本地的代碼進行編譯，如果不通過則向研發人員的IDE推送異常事件；

第四步：單元測試及代碼質量檢查。無論代碼是否通過編譯，都可以選擇執行單元測試和代碼質量檢查， Jenkins將調用Xunit、Sonarqube分別進行單元測試和代碼質量檢查；

第五步：同步測試結果。將測試結果返回給DevOps Dashboard，同時也支持將測試結果返回至研發人員的IDE開發工具中；

第六步：打包。通過DevOps Dashboard觸發打包動作，準備進入測試流水線；

（2）測試流水線

第一步：準備測試環境容器：通過DevOps Dashboard觸發CaaS平臺，生成測試所需的容器環境；

第二步：生成build環境。CaaS平臺從其標準構件庫中拉取容器鏡像，生成包含tomcat、數據庫等構件的容器環境1；

第三步 ：部署 Jar、War。DevOps Dashboard通知CI平臺向容器環境1中部署本次開發的JAR或WAR包；

第四步：執行配置、數據庫初始化。DevOps Dashboard通知CSA平臺對容器環境1中的配置文件進行自動修改，對數據庫環境進行初始化。至此容器環境1已經可以作為測試環境獨立運行，容器環境1主要面向測試人員，用于新增功能的功能驗證測試；

第五步：生成測試鏡像。CAAS平臺將容器環境1打包生成測試鏡像；

第六步：生成測試環境。CAAS平臺利用上一部生成的測試鏡像生成一個與容器環境1完全相同的測試環境，即容器環境2；該環境主要面向自動化測試平臺，用于歷史功能的自動化功能回歸測試及性能測試；

第七步：執行測試。DevOps Dashboard通 知ATP平臺開始自動化功能回歸測試及性能測試，并將測試結果反饋給DevOps Dashboard；至此測試流水線完成，下一步開始進入發布流水線；

（3）發布流水線

第一步：發布。DevOps Dashboard通知CAAS平臺進行版本發布動作，CAAS平臺從測試臨時庫中抽取測試環境，打包生成發布版本；

第二步：提交部署。CAAS平臺將發布版本遞交給CSA平臺，由CSA平臺向生產環境（以PC服務器為主）發布生產版本；

第三步：設定部署策略。用戶在該階段可以選擇設定部署策略，如藍綠部署、滾動部署、金絲雀部署策略等；

第四步：執行部署策略。CSA平臺聯通生產環境，根據上一步設定的部署策略對生產環境中的服務器、負載均衡進行部署策略執行；

第五步：結果驗證。CSA對部署結果進行驗證，并生成上線報告同步至DevOps Dashboard，供技術經理閉環審閱。