超大流量電商平臺系統背後的持續集成與發佈

內容來源：2017年9月2日，美麗聯合集團技術專家蔣志強在「七牛雲&美麗聯合集團架構師實踐日：CI/CD落地最佳實踐」進行《持續集成和發佈在美麗聯合集團的實踐》演講分享。IT 大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2380 | 4分鐘閱讀

嘉賓演講視頻回顧及PPT： suo.im/SHpc3

摘要

發佈做爲應用上線前的最後一個步驟，一直以來都是運維作的比較頻繁也是風險比較高的操做，發佈系統不只要作到提高發布效率，更重要的是保障發佈過程當中系統的穩定，減小因發佈致使的故障。本次演講主要講述美聯的發佈&持續集成系統的演進以及在提升發佈效率，保障系統穩定上的實踐。

發佈系統的演進

發佈系統的演進在必定程度上表明瞭運維體系甚至是公司技術架構的演進。

技術架構-早期(2011-2013)

最先期的開發語言是PHP，最流行的開源運行環境是LNMP，代碼管理是SVN。

最開始的是人肉發佈，後來有了PHP主站發佈系統。它能代替人肉進行發佈和操做，支持文件發佈，有了回滾的功能，還有最簡單的審批操做。

業務架構-中期(2014-2015)

到了2014年，咱們的業務架構有所調整，創建了本身的交易平臺。

開發語言變成了JAVA，運行環境是TOMCAT，代碼管理用的是GIT。

業務系統改爲JAVA之後對發佈系統也提出了更多的挑戰。JAVA發佈和PHP發佈有很大區別，因而咱們作了JAVA的發佈系統。

發佈系統也改成StarkPlus，須要支持更多的發佈類型、發佈模式，以及更多的發佈功能。

發佈系統的特色是支持類型多，有JAVA、C++、NodeJS、PHP、Golang、Css_js以及二方庫。

發佈策略也多，有分批發布、分組發佈、流式發佈、自動發佈和自定義發佈。

功能多。原來的系統每次只能發佈一個特定的分支，如今有一個應用多個分支並行開發的狀況，因此咱們須要多分支集成。

咱們的應用又部署在多個機房，每一個機房的配置可能都是不同的，構建也不一樣，因此須要多機房構建。

最開始只有三套環境，後來慢慢發現三套環境已經不能知足咱們的研發需求，須要多套環境部署。

Docker是目前很是流行的一個容器，咱們如今也有部分應用在Docker上面，要對Docker作一些支持。同時也支持Docker和KBM的混合發佈。

還有集成測試、安全掃描、性能壓測和jar包檢測，這些是其它業務團隊作的工具，咱們把它們集成到咱們的發佈系統中，來加強這些功能。

實踐之路

運維的基礎-標準化

首先要作好基礎軟件及配置標準化，OS、JDK、tomcat、nginx等等爲運維提供了一套最標準的環境，全部的應用都跑在一樣的環境上。

應用自己配置的標準化，應用命名、配置管理，啓停腳本、檢測腳本、部署目錄、日誌目錄這些有統一的標準。

咱們提供了一個應用的模版，假如應用徹底符合咱們的標準，就不須要改動能夠直接接入，但也有些特殊的應用可能狀況會不同。

應用配置管理

應用類型配置可使用咱們的標準模版，也能夠作一些自定義的功能，主要是人員角色、應用類型、啓停命令和軟件包信息。其實它們集成在咱們的發佈系統裏面，後來咱們發現這些設置不只僅是發佈系統要用，其它不少運維繫統、業務系統都會用到。因而咱們把它羅列出來單獨成立了一個配置中心。

上圖是咱們發佈系統的一個依賴關係，裏面的一圈是它的核心依賴，CMDB管理服務器，配置中心管理應用的配置，OpsAgent在每一個機器上部署一個Agent，用來執行一些在服務器上持續的操做。Gitlab作代碼管理，流程引擎用於審批內容。

外圍一圈都是用於加強咱們的功能和一些外部依賴，有監控、安全掃描等等。

發佈系統架構很是簡單，主要就是兩部分，一個是JAVA前端，用來作頁面和流程控制。下面一個是用Pathon寫的一組worker，用於執行一些具體的操做，例如代碼的構建、合併、部署。中間經過一個MQ作任務隊列和解耦，它們之間經過DB來進行傳遞。

分支管理

上圖是咱們的分支管理。全部的開發分支都是來源於master，在開發分支上開發完成將近發佈的時候，發佈系統會從master上拉出一個release，把feature分支一個個往上合，合完之後發佈這個release分支。release分支發到線上成功之後再把它合回到master，建立一個基線。

新建&導入變動

建立變動有兩種方式，一種是新建變動，就是從master上拉出一個新的分支；另外一種是導入變動，已經有了從另外的開發分支上的一個分支，須要手動把這個分支拉出來進行導入。

集成&發佈

上圖是咱們集成發佈的頁面。最上層是咱們的三套部署環境；發佈的基礎信息包括了應用名和當前發佈的分支名稱等；下面是咱們發佈過程，發佈過程會根據應用類型的不一樣而有所區別；集成區的分支就是當前分支在發佈中，待集成區是已經開發提交了集成可是尚未進行發佈。

進入線上

預發必須部署成功，集成區的checklist要所有經過。

代碼合併

手動解決在代碼合併過程當中發生的衝突。Release分支更換策略就是新加入的分支或者修改feature分支代碼的時候，Release分支是不會變的，不用再解決第二次衝突。

不一樣應用類型的構建方式是不同的，並且構建是基於合併完成的Release分支，像JAVA、C++、GOLANG、NODEJS是放在一個Docker容器中進行構建，構建完成後會有產出。

健康檢查

每一個應用都有健康檢查URL：/status

當訪問/status時，檢查覈心依賴（DB、cache、依賴應用），預熱數據。

執行成功返回「SUCCESS」，其他情況均爲失敗。

發佈計劃&審批

平常發佈是週一至週四工做時間，由主管審批；

常規緊急發佈在周5、週末，由研發D進行審批；

節假日例如法定節假日、運營商封網等，也是研發D審批；

特殊時期好比大促、集團發佈會等期間，理論上是不容許任何發佈的，如需發佈就須要經過CTO審批。

咱們的特點

研發流程閉環

深度整合發佈系統與項目管理系統（PMO），需求、項目能夠建立、關聯變動。變動發佈後能夠通知到PMO的系統去更新需求和項目狀態，這樣就能夠明確每次發佈的目的。

多機房、多分組構建

同一個應用在不一樣的機房有不一樣的配置，在不一樣的分組提供的服務也有區別。

線下&預發多套環境

由於需求多、變動多，因此部署變動很是頻繁，測試老是抱怨環境不穩定。大項目但願能獨佔一套項目環境，解決環境的隔離。

Jar包檢測&Diff

Jar包衝突檢測：Jar包衝突會致使莫名其妙的問題，難以排查。

Snapshot包檢測：Snapshot版本更新頻率高，不可控。

Jar包版本限制：已經廢棄的版本、有bug的版本不能被使用。

Jar包Diff：查看本次發佈版本和基線版本的jar包差別。

穩定性

前端掃描：對於css_js的發佈作前端代碼質量檢測；

安全掃描：對java代碼作靜態安全性分析；

集成測試：預發環境發佈的同時執行單元測試、接口測試；

性能監控&壓測：線上beta發佈後對beta機器執行性能壓測。

我今天的分享就到這裏，謝謝你們！