超大流量電商平台系統背後的持續整合與發布

內容來源：2017年9月2日，美麗聯合集團技術專家蔣志強在“七牛雲&美麗聯合集團架構師實踐日：CI/CD落地最佳實務”進行《持續整合和發布在美麗聯合集團的實踐》演講分享。IT 大咖說（ID：itdakashuo）作為獨家視頻合作方，經主辦方和講者審閱授權發布。

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

擷取嘉賓演講視頻回放及PPT，請點擊：http://t.cn/RscHvFO

摘要

發布作為應用上線前的最後一個步驟，一直以來都是營運做的比較頻繁也是風險比較高的操作，發布系統不僅要做到提升發布效率，更重要的是保障發布過程中系統的穩定，減少因發布導致的故障。本次演講主要講述美聯的發布&持續整合系統的演化以及在提高發布效率，保障系統穩定上的實踐。

發布系統的演化

發布系統的演化在一定程度上代表了營運體系甚至是公司技術架構的演化。

技術架構-早期(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等等為營運提供了一套最標準的環境，所有的應用都跑在同樣的環境上。

應用本身配置的標準化，應用命名、組態管理，啟停指令碼、檢測指令碼、部署目錄、日誌目錄這些有統一的標準。

我們提供了一個應用的模版，假如應用完全符合我們的標準，就不需要改動可以直接接入，但也有些特殊的應用可能情況會不一樣。

Application Configuration Manangement

應用類型配置可以使用我們的標準模版，也可以做一些自訂的功能，主要是人員角色、應用類型、啟停命令和軟體包資訊。其實它們整合在我們的發布系統裡面，後來我們發現這些設定不僅僅是發布系統要用，其它很多營運系統、業務系統都會用到。於是我們把它羅列出來單獨成立了一個配置中心。

是我們發布系統的一個依賴關係，裡面的一圈是它的核心依賴，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”，其餘狀況均為失敗。

發布計劃&審批

日常發布是周一至周四工作時間，由主管審批；

常規緊急發布在周五、周末，由研發D進行審批；

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

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

我們的特色

研發流程閉環

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

多機房、多分組構建

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

線下&預發多套環境

因為需求多、變更多，所以部署變更非常頻繁，測試總是抱怨環境不穩定。大項目希望能獨佔一套項目環境，解決環境的隔離。

Jar包檢測&Diff

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

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

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

Jar包Diff：查看本次發布版本和基準版本的jar包差異。

穩定性

前端掃描：對於css_js的發布做前端代碼品質檢測；

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

整合測試：預發環境發布的同時執行單元測試、介面測試；

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

我今天的分享就到這裡，謝謝大家！