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

轉載本文需註明出處：微信公眾號EAWorld，違者必究。

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

• 建設背景

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

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

1.通過DevOps平臺統一管理所有產品、專案，對團隊、對人能進行數字化的考核

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

3.在兩年內，將目前部門的研發、測試、運維釋出的工作效率提升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%的持續整合、測試環境的自動化部署。並且在月尾的釋出視窗，選擇了一個試點應用成功通過平臺進行釋出上線。

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

總結下一期的建設成果：

1.實現40+微服務的的持續整合、自動化部署

2.基於Scrum體系，統一管理20+產品、30+專案

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

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平臺等專案。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562043/viewspace-2284567/，如需轉載，請註明出處，否則將追究法律責任。