萬達網路科技的DevOps平台架構解析

萬達 DevOps 平台建設歷程

我們從 2017 年 2 月份開始幫助萬達網路科技建設 DevOps 平台，2017 年 6 月份完成試運行上線交付。目前萬達網路科技公共平台研發中心的所有產品和項目都已經通過 DevOps 平台管理起來，實現了全面的持續集成、持續交付等能力，並持續進行過程度量和改進，不斷提升 IT 運行效率。

建設背景

萬達網科成立後，業務需求處於一個飛速增長的階段，在短時間內已經發展到將近 30 個產品、40 個項目，管理成本相當之高，傳統的管理方式很難高效率、高質量的進行管理和把控如此之多的產品和項目。並且隨著虛擬化、容器雲、微服務等技術的發展，應用底層的運行環境愈發多樣化，物理機、虛擬機、容器雲三種異構環境、移動應用、Springboot 應用、純前端應用等數十個異構應用都需要通過一個平台進行統一的部署和管理。

建設目標簡單可以歸納為如下三點：

通過 DevOps 平台統一管理所有產品、項目，對團隊、對人能進行數字化的考核

實現所有應用的持續集成、100% 自動化部署，提升應用的軟體交付效率

在兩年內，將目前部門的研發、測試、運維發布的工作效率提升 50%。

建設過程

項目從 2 月初開始，到 6 月底上線交付。持續了 5 個月的時間。項目過程基於 Scrum 過程體系，以月迭代的方式，每個月發布一個版本。同時，基於 MVP 的理念，保證每個月上線的版本功能都是可用的，不斷的完善平台能力。每個衝刺過程如下：

Sprint1（2 月份）：2 月份主要進行了整體需求分析，完成我們現有產品的上線，以產品的現有能力作為第一個 MVP 版本。

Sprint2（3 月份）：3 月份交付了產品管理、項目管理、持續集成等能力，並且最重要的，結合萬達的流程和規範，打通持續交付的流水線。流水線從構建開始，一直到上線部署，有了持續交付流水線，即使中間的一些環節（如測試環境）暫時無法做到完全的自動化測試，但是可以通過人工的參與，自動與人工結合，至少保障了整個軟體交付過程便已經通過平台管理起來。後續便可以此流水線為基準，不斷的完善中間環節的自動化能力。

Sprint3（4 月份）：完善了度量優化、部署、流水線協作看板等能力。在度量優化模塊，結合萬達的度量點和度量考核規範，從多個維度和視角，不斷提昇平台的度量能力。在部署管理模塊，首先結合萬達的環境資源規範，對接其 CMDB 系統，在 DEV/LAB/SIT/UAT/PRE/PROD 六大環境的基礎上，統一納管所有項目的環境資源。結合部署規範（操作系統、部署用戶許可權、目錄要求、資料庫版本、jdk 版本、nginx 版本等），定製出符合萬達要求的自動化部署能力。在流水線能力上，完善了兩個協作看板：產品發布看板、環境看板。產品發布看板以產品為主視角，可以直觀看到產品的每個版本到了持續交付的哪個環節。環境看板則是以環境為主視角，可以直觀看到每個環境下，有哪些產品版本在運行。

Sprint4（5 月份）：5 月份繼續豐富了一些尚未完善的能力，比如針對 vue 的代碼質量掃描等（sonarqube 目前並不支持對於 vue 的代碼質量掃描），比如一些平台級的功能如角色許可權的配置、首頁看板的定製、操作日誌、密碼策略等等一些功能進行了完善。到此整個平台的全部功能就已經完成交付。

Sprint5（6 月份）：6 月份是上線試運行階段，這個階段將 20 多個產品、30 多個項目、50 多個代碼庫都遷移到平台上統一管理，做到了 100% 的持續集成、測試環境的自動化部署。並且在月尾的發布窗口，選擇了一個試點應用成功通過平台進行發布上線。

我們也是第一次嘗試月迭代的方式，所以這個對於我們而言也是很大的一個挑戰。在這個過程中，也在不斷的思考和改進。

總結下一期的建設成果：

實現 40+ 微服務的的持續集成、自動化部署

基於 Scrum 體系，統一管理 20+ 產品、30+ 項目

統一持續交付流水線，9 大環節，跨 4 大環境，驅動開發、測試、質量、運維、管理等多個角色協作

支撐 PMO 精益度量，多維度統計 20+ 報表

平台架構解析

總體架構解析

從邏輯上我們把 DevOps 平台劃分為三大領域：敏捷過程、持續交付、持續改進。

敏捷過程針對於軟體過程進行管理，包括產品、項目、團隊、計劃、任務等，持續交付則關注從需求到上線交付的管理，包括持續集成、自動化測試、自動化部署、交付流水線等。持續改進則體現了平台的核心價值，不斷的度量和優化軟體過程，為提升 IT 運行效率打下堅實的基礎。

在上面三大領域的基礎上，又做了一些模塊拆分，平台的邏輯架構如下：

DevOps 平台劃分為領域層、基礎服務層、工具層三層。工具層封裝了一些開源工具，提供基礎能力。服務層在此基礎上封裝的一些基礎服務，如編譯、部署、代碼管理等。領域層主要包括項目管理、產品管理、構建、部署、交付流水線、度量優化等模塊。底層運行環境支撐物理機、虛擬機、容器雲平台。

產品管理 & 項目管理

軟體的整個生命周期可以從不僅僅是項目的生命周期，而是應該也包括了產品的生命周期。在企業內部，通常我們先決定做哪個產品，然後需求調研、版本劃分，確認了具體版本要實現的需求範圍後，便可以組建項目進行研發。研發完成進行交付後，有進入產品的線上運營階段。直至產品下線。一個產品可以對應多個項目，當然，對於有些企業而言，一個項目也是持續穩定的維護一個產品。

持續集成

持續集成模塊功能主要有代碼庫管理、構建定義管理以及構建實例管理等。在構建定義管理模塊中，DevOps 平台將構建任務分成了四種類型：

編譯類任務：Maven、Ant、Gradle、純前端構建等

測試類任務：Sonarqube、Jmeter、Selenium 等

打包類任務：Npm、Archive、Docker 等

其他工具類任務：Copyfile、Shell、介質提交到 Nexus 倉庫、介質上傳二方庫等。

在每個構建定義上可以選擇若干個需要的構建任務，通過原子步驟編排，組裝成一個完整構建流程。代碼提交時觸發構建（支持 gitlab、github、svn 等常用代碼庫版本管理工具）、日構建等不同的構建觸發策略等支撐了持續集成的完整鏈路打通。

自動化部署

在自動化部署模塊中，為了更好的與實際結合，我們將部署分為三個階段：設計、轉換、運維。

設計階段：將部署架構分為三層：部署裝配（Assembly）、部署容器（Platform）、部署組件 (Component)。部署裝配是對部署架構的描述，由多個部署容器組成，每個部署容器由若干個部署組件組成。

轉換階段：將部署架構與部署策略（全新、藍綠、灰度、滾動升級等）、資源（具體資源如物理機、虛擬機、容器）、組件配置參數（埠號、JVM 參數、健康檢查 url 等）進行結合，生成部署計劃，一鍵執行自動化部署。

運維階段：對於已部署的實例進行運維管理，包括啟動、停止、重啟、修復、狀態檢查等等。

持續交付流水線

為什麼需要持續交付流水線？舉個例子來說，我們常常苦惱最終上線版本和系統集成測試環境不一致。這一般是因為在系統集成測試完成後發現了問題，作了代碼變更但沒有重新構建，而是直接在介質里進行了調整進而發布上線。在持續交付流水線中是不允許這種情況出現的。所有上線入口一定是最初的構建，所有的後續產物都是基於這一介質，如果有變更必須重走流程。這樣可以保證發布的安全性和統一性，線上出現問題也是可以追溯的。當然過程中的環境可以配置人工介入或自動執行。

發布流水線從構建到生產部署共 9 大環節，涵蓋 SIT/UAT/LAB/PROD 四大環境。驅動了開發、測試、質量、運維等多個角色的協作。

在設計流水線能力時，我們主要考慮到幾點：

結合企業的不同交付流程，要能支持自定義的流程配置，要能支持多套流程配置

流程的每一個環節都要支持自動執行的配置

流程中每個環節的屬性和配置信息可以自定義，靈活擴展

流程以構建開始，讓 buildNumber 貫穿整個流程，方便追根溯源

要有一個看板，直觀的看到整個產品的版本目前到了流程的哪個環節，是 SIT 還是 UAT，結果如何

要有一個看板，直觀的看到每個環境下，有哪些介質在運行

以這些為基礎準則，我們底層基於了我們的 BPS 流程引擎，支撐流程的自定義和擴展。並且，針對於每個環節，都可以配置前置後置事件、人工執行還是自動執行，責任人等。整個流水線從構建開始，保證全局介質唯一，避免人為修改介質導致的生產介質不可追溯。

在交付看板上，環境看板和發布看板如下

度量優化

精益運營的基礎是度量，度量的三大維度：指標、執行監控、預測。首先是明確指標和執行監控，基於軟體全生命周期的度量過程中企業遇到的最大困難莫過於拿不到完整的數據，各個部門、各個流程、各個系統之間數據相互隔閡，信息很難流通，導致無法從整體的角度對軟體過程進行度量。當 DevOps 平台能打通企業的軟體生產全生命周期時，數據的割裂性問題自然也就不存在。當然，度量不僅僅是事後的統計分析，更應該提供過程監控的能力，在過程中，通過一些看板（比如任務看板、需求看板、發布看板）、趨勢圖（比如任務燃盡圖、bug 燃盡圖）等，提前預知風險，規避風險，持續把控項目質量和產品質量。

示例如下：

建設過程中的難點

難點 1：統一流程和規範

回顧一下前文的發布流水線的介紹，其實這其中我們在介紹時省略了大量的細節。比如，在開始構建時是否要打一個 Tag，此時針對構建介質產物是否不應該是 snapshot 版本，而應該是 Stage 預發版本。如果 UAT 等測試通過之後，這個介質版本即為可發布版本，此時介質需要轉移到 Release 版本的介質倉庫。這就是一個完整的流程，也是需要加入到規範中去的。

梳理企業的流程和規範是企業建設 DevOps 的前提，甚至即使不建設 DevOps 平台，這也是一個必不可少的行為。只有統一了企業的流程和規範，才能建設出一個適用於企業的 DevOps 平台，否則到最後，有可能會讓 DevOps 平台脫離實際，導致沒有人會去使用。

我們在建設過程中，每一個模塊都需要結合萬達的流程規範以及我們的最佳實踐共同進行建設，在前期，當一些流程規範不是那麼明確的時候，還需要一起討論，同時規範也不是一蹴而就的，實施過程中發現一些不合適的地方就需要進行修改，這也就帶來了需求的反覆的可能。以持續交付流水線為例，這個就需要結合萬達的環境、發布規範來定製流程，對於其他企業而言，持續交付流水線未必就是這樣的一個流程，有可能會少一些環境，也有可能多個預發環境，又或者會把這一個流水線拆分成多個流水線。

難點 2：異構兼容

對於應用運行環境而言，需要同時支撐物理機、虛擬機、容器雲、Android 設備、IOS 設備多種類型的環境。而應用本身又分為純前端應用、SpringBoot 應用（Fat JAR）、傳統應用（WAR）、Android、IOS 等各種類型。這就對自動化部署框架提出了很高的要求，一套架構要能同時支撐異構應用部署在異構環境上。

以移動應用的自動化部署為例，os 部署組件可以用來區分系統、computer 可以用於校驗機型。選擇部署資源時，從 cmdb 中導出項目的移動設備資源，最後將應用自動化部署到移動設備上。

難點 3：職能切面

DevOps 平台建設之前，企業可能已經有不少系統了，比如雲資源管理平台、容器云云平台、自動化測試平台、統一監控平台等等。那麼很多時候一個困難點就在於 DevOps 的定位了，在測試的能力上，DevOps 平台要不要完整的把測試的能力都管理起來呢？在自動化部署的時候，要不要直接創建虛擬機對資源進行操作呢？我們在萬達落地 DevOps 的過程中，也遇到了這些問題。我們認為：

DevOps 無法讓每個人的工作都在上面，高級能力還是專人在專業系統上完成；

如果專業系統足夠自動和自助化，可考慮逐步納入 DevOps 平台

我們做的是工程效率平台，不是給多個系統做個統一門戶

本著這些理念，我們就明確了對職能的切分。像對底層資源的管理，是統一通過 CMDB 進行管理，DevOps 只是進行資源的申請與使用。在測試環節，則是對接自動化測試平台，將持續交付流水線中的測試環節拉起來，保障整個流水線的完整。在對已部署應用的監控，可以對接企業的統一監控平台進行健康監控。

總 * 結

雖然目前 DevOps 平台已經完成初步交付，並且已經將所有的產品、項目統一通過平台進行了管理。但是這僅僅做到了敏捷過程和持續交付。在持續改進領域還是有不少工作持續去做的，平台目前在度量優化部分的能力還是稍顯不足，如何能完成最初的目標：」在兩年內提升 IT 運營效率 50%「。還需要更加豐富、更加可量化的一些統計分析數據來支撐。而這，也是我們認為 DevOps 最核心的價值，致力於提升企業 IT 運營效率。

作者介紹

王海龍，現任普元信息高級研發工程師，畢業於華東師範大學，曾參與和負責銀聯 Paas 雲平台項目、興業銀行 CAP4J 項目、交通銀行信用卡中心統一監控平台項目、神華災備雲平台、萬達 DevOps 平台等項目。

本文轉載自EAworld，已獲授權。

歡迎加入由作者主持的技術討論微信群，與作者一同交流、探討微服務等相關問題。

掃描群助手微信二維碼，添加暗號：927

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 InfoQ 的精彩文章: