從0到1，蘑菇街怎樣打破應用運維自動化的技術藩籬

從0到1，蘑菇街怎樣打破應用運維自動化的技術藩籬？

中國統計網 2017-07-10 17:30

做者介紹

白海強（花名：普智），目前在蘑菇街平臺技術部從事應用運維體系和其它建設工做，與團隊一塊兒推動業務應用運維標準化及自動化系統的建設。在加入蘑菇街以前在淘寶任職，負責淘寶商品詳情等業務的運維工做。

本文根據〖6月25日DBAplus電商行業運維實踐沙龍〗白海強老師的現場演講內容整理而成。點擊文末【閱讀原文】還能下載PPT哦~

演講大綱：

1. 蘑菇街技術架構及運維演進

2. 應用運維體系建設思路

3. 應用運維自動化實踐過程

蘑菇街技術架構及運維演進

導購期（2011-2012）

2011年蘑菇街上線時，它的主要業務是分享社區，就是買家買了商品之後，把這個商品分享出來給你們。2012年開始轉型商品導購，早期業務比較簡單，相對設備比較少，基本上是一套業務代碼。運維都是由具體的開發同窗本身去管理的，根本不須要專業的運維人員。

轉型期（2013-2014）

從2013年開始，咱們開始自建電商平臺，從下單到支付整條鏈路開始自主建設。業務發生了變化，可是整個架構沒有太大的變化，只是把中間層，數據層脫離出來了。設備增長了很多，從原來個位數增長到三位數了，還有網絡設備了。業務這一塊是開發本身維護，運維這邊主要建設了一些初級版的服務器管理系統、發佈系統、監控系統。

社交化電商（2015-至今）

2015年整個業務開始發生變化了，集團開始從原來的PHP開發，逐步轉向了Java開發，從原來主站一套單一業務套代碼拆分紅各個子業務系統，整個架構發生改變。流量入口咱們分紅兩塊，無線端和PC端二塊接入。MWP爲無線網關。其餘PC端的流量經過代理層分發到各個不一樣的子業務系統，部分系統實現先後端分離服務化，最底層爲數據層。從原來業務再新加業務需求，逐漸演變成擁有目前1300多個應用系統。

業務快速發展對咱們運維帶來的挑戰：

第一：1300多個應用如何進行管理，這是一個大的問題。不一樣業務如何區分？業務確定要部署在具體服務器上面，不一樣業務部署不一樣服務器，業務和服務器之間的對應關係如何管理？還有業務部署環境，不一樣的業務運行的環境有可能存在差別的，因此咱們須要把業務與環境之間的對應關係也要管理起來。

第二：早期業務之間能夠依賴簡單應用代碼之間內部的調用，拆分演變成應用與應用之間的依賴關係，如何管理業務之間的上下游依賴？如何快速定位排查問題？這對咱們排查工具帶來了挑戰和要求。

咱們帶着這些問題看一下運維體系建設的思路。

應用運維體系建設思路

運維核心理念

運維工做圍繞這四個主題展開的：

• 穩定性。保證業務穩定快速地發展；

• 成本。成本涉及到兩塊：人力成本和系統資源成本，咱們指望以最小的成本創造最大生產價值；

• 效率。運維工做自動化，提升工做效率，減小成本；

• 安全。

咱們平常運維工做都是圍繞這四塊展開的，系統建設的時候也是圍繞這四個主題展現；這四塊主題優先等級我我的認爲是：安全第一，若是系統存在安全問題，那確定是第一時間處理；其次是穩定性、成本、效率。以上我的對運維的理解。

應用運維繫統架構

基於運維需求，咱們逐步建設起目前的運維體系的架構。從最底層看，第一層基礎的硬件環境，如IDC/服務器/網絡設務。第二層爲業務須要的底層基礎服務，如DNS、NTP、YUM源、LVS等；第三層針對這些系統資源管理平臺，虛擬化平臺，DNS管理系統等。上面三層針對業務的，有咱們應用管理系統、服務器管理系統、DBMS等；還有經常使用的系統，像發佈系統、部署系統之類的。最頂層是開放給業務開發使用的統一運維平臺。這些系統並非說在咱們建設當中一下就能建設好的，而是根據咱們平常操做當中運維的須要逐步搭建而成。

應用標準化規範-思路

若是一個系統業務要接入進來，第一步要作的是標準化。按照咱們規範進行改造，符合咱們要求才能接入進來。否則1300多個應用沒有一個統一接入標準，讓咱們去作適配打造運維相關的系統，那是不可能的。咱們整體的思路，先標準、後接入，只有按標準改造了，業務開發才能方便地使用咱們的運維繫統。

應用標準化規範-範圍

標準化到底要作哪些事情呢？主要分紅三塊：

• 基礎環境。基礎環境裏面規範有哪些呢？咱們能夠分爲兩塊：硬件、軟件。硬件咱們規範了使用的服務器硬件配置規格，目前虛擬機規格分紅三類：2核4G內存的，4核8G內存的，8核16G內存的；目前要求都使用的是虛擬機。軟件方面咱們主要規範部署須要的軟件的版本、管理方式和部署目錄；

• 應用配置。這裏規範了應用部署目錄、應用包名和應用配置等。

• 技術架構。規範了業務對基礎組件使用姿式，如流量接入層、ZK、Kafka等。

應用標準化規範-內容

集團應用體系規範

接下來看一下具體的標準化定義內容。整個運維標準化體系是咱們運維部牽頭搞的。主要是剛纔講到的內容，定義了具體咱們使用的應用和基礎服務的接入、目錄的規範。旁邊能夠看一下應用的管理規範，詳細定義應用名命名規範、應用包名規範、應用目錄、部署目錄等內容，造成文件，在整個集團各個部門裏面傳達執行。

應用標準化規範文檔-實例

應用部署規範

咱們按照開發語言不一樣，應用服務對服務器的部署環境要求也不一樣；咱們前後制定Java版、PHP版、GO版和Node.js版等。每一個版本的規範裏面都基本上定義了這些內容：

第一：目錄：基礎軟件部署目錄和版本要求；

第二：應用運行的用戶帳號是什麼、權限是什麼。

應用標準化規範文檔-實例說明

（1）應用啓停腳本

接下來咱們還規範了啓停腳本，還定義了這個腳本里面傳的參數，能夠支持哪些參數，啓動或者重啓。每條指令裏面作什麼事情都進行了說明和規範。

（2）規範應用上線標準

除此以外還定義了一個業務上線以前要遵循的標準，上線的標準和下線的標準。上線以前須要業務方提供標準的自檢功能，要怎麼知道你這個應用是成功仍是失敗的，那確定須要有一個檢測機制告訴我，腳本里面經過這個檢測機制知道這個業務究竟是否正常，這是一個強制性的規範。下線也是同樣，上流根據定時檢測指定這個URL，根據訪問結果判斷是否把流量自動地切掉。

標準化文檔裏面主要就是規範上述一些內容。這些內容爲後面的運維繫統作了規範。咱們運維繫統都是基於這個規範來作。

應用運維自動化實踐過程

應用運維核心概念

1300多個應用如何管理？在介紹應用管理以前須要重點介紹一下這幾個概念，這做爲蘑菇街應用運維核心概念。

第一：應用名錶明在蘑菇街應用系統中具體業務功能，不一樣的應用名用於區分不一樣的業務，咱們按照一套業務代碼進行劃分。

第二：應用名分組是管理服務器的，用來組織管理服務器的。

二者之間的關係是什麼？一個應用下面能夠對應多個應用分組；這個分組按照什麼維度來劃分的呢？能夠根據環境，也能夠根據穩定性的要求來拆分的。應用名做爲應用運維的核心，運維繫統都以應用名做爲資源的組織方式。

應用管理系統

系統裏面主要管哪些內容呢？其中一塊用於管理業務、部門、人員三者之間的關係。

能夠看一下這個圖，像這個業務是屬於哪個部門的，開發者是誰，代碼review是誰，這個裏面都會維護好。除此以外還會定義這個應用的部署特徵，這個應用部署類型是什麼，這個比較關鍵。後期的運維繫統咱們會拿着部署特徵信息後面作判斷應用於具體操做。應用管理系統中定義裏面每個字段在後面運維繫統裏面都會存在必定關聯。

服務器管理

接下來服務器管理也有單獨的系統，服務器管理系統前面說了，分組是做爲管理服務器的，在這一層能夠看一下咱們整個層次結構分紅兩層：部門下面是具體的應用，應用下面是分組。應用分組默認有三個組：DEV表明線下測試環境，PRE表明預發環境，ONLINE表明生產環境。咱們在分組上面創建了不一樣環境的標識；發佈系統或其餘運維繫統就能夠根據需求按應用的緯度獲取不一樣環境的機器列表。

同一個應用目前咱們只分了三套環境：測試環境、預發環境和線上環境，通常默認對應3個應用分組；但有時基於穩定性考慮，會把線上環境的服務器拆分紅多個應用分組。假如某個應用是爲其餘應用業務提供基礎服務的；若是調用服務不隔離管理的話，很容易出現穩定性的問題，如非核心業務調用量過大，致使核心業務調用失敗或超時，基於上述問題，咱們很容易想到解決方案就是把服務拆分紅不一樣服務集羣，讓核心業務調用1個服務集羣，讓非核心業務調用另一個集羣。這個需求RPC服務管理控制檯均可以實現IP與服務關係綁定；根據依賴業務重要程度區分出不一樣的服務集羣，再根據不一樣集羣調用量需求將服務器劃到不一樣的應用分組中進行管理，這個拆分分組是比較好的一個解決方案；

既然RPC這邊已經把服務邏輯分組，那服務器管理系統中是否是能夠不用區分了，服務器放在同一個應用分組下進行管理，這樣不是更簡單嗎？

不拆分出應用分組，對於業務訪問是沒有影響的，由於應用分組的做用只是管理服務器，不會影響線上正常訪問；可是運維繫統是不知道應用業務內部邏輯訪問分組是什麼樣，那些機器屬於同一個服務集羣，操做時須要必須一塊兒操做；若是同一個集羣一塊兒操做的話，那線上的服務就掛完了；因此必須把這個體現出來，管理起來；

應用分組這個管理方式是比較靈活的，能夠根據不一樣業務的特徵創建不一樣的分組。好比說機房緯度、地域緯度等。分組能夠理解爲是一個集羣的概念，同一個應用分組下提供服務和服務對象都是相同的。這是服務器管理這一塊。

應用部署類型模板管理

同一類開發語言開發出來的業務應用對於部署環境依賴大體都是相同的。基於這個特徵，咱們基於應用部署類型制定應用部署模板，用於管理同類應用部署服務器環境的需求。咱們基於不一樣部署類型創建對應的應用部署模板，如Java版、C++、GO等。在這個模板裏面咱們定義了：部署的軟件和常規配置文件等內容。舉個例子，Java開發業應用，通常部署服務器環境所須要的包括一個JDK，容器咱們使用Tomcat，Nginx做爲Web代理服務器；除此以外，咱們還有可能須要啓停腳本和配置文件，用於保證環境正常運行。

應用基線管理

部署模板的用途用是什麼呢？它主要爲應用基線提供服務的。應用基線咱們創建的維度按照應用分組維度創建的。

應用基線創建的維度咱們是按照應用分組維度來創建的。通常狀況下應用基線部署的內容配置都是從部署模板裏面導過來的，基本上都能知足相應的應用部署環境的須要；當個別應用須要個性化的環境配置或軟件時，咱們就能夠針對相應的應用分組的應用基線進行修改補充，已知足業務方的需求；

應用基線產生時間點是在應用申請流程結束後，根據應用申請時選擇的部署類型自動地把應用模板相應配置信息導入到該應用下的全部應用分組下面。

應用部署系統

經過前面幾個系統，咱們基本上把環境、應用都管理起來了。但如何實現環境的自動化部署？咱們創建了應用的部署系統，應用部署系統裏面定義什麼呢？就是咱們定義了部署環境的執行步驟。

如第一步，部署安裝軟件；第二步配置文件；第三步初始化等等。根據咱們應用的部署類型創建不一樣的部署須要執行的步驟，按照定義執行步聚能完整地構建起一個應用的運行環境。

運維工單管理

最後缺一個觸發的場景，能把上面各個相關係統串聯起來的系統。像申請服務器、擴容，新應用申請，由於這些都是業務開發提出了需求，如何組織在一塊兒，跟咱們的環境部署系統組織在一塊兒呢？經過運維工單的方式，須要業務開發提相應的工單，根據不一樣的工單把咱們前面運維的步驟總的綜合在一塊兒。

目前咱們工單的範圍比較多，覆蓋了咱們運維當中常見的一些運維需求，像服務器申請、新應用申請之類的。這些步驟裏面，每一個工單裏面都包含兩部分：第一部分是流程審批，由於有的人很反對流程，但流程是爲了保證穩定性的手段而已。還有一部分是咱們的工單，具體作的事情。工單系統裏面是這兩部分組成。

應用運維自動化實現總結

接下來講一下整個過程，當運維開發提交一個工單給咱們的時候，假設新應用申請，重新應用裏面根據這個應用裏面定義的內容獲取應用的配置信息。應用的審覈人員是誰，根據這個審覈人員審批流程經過之後，會獲取對應系統裏面部署的機器列表，根據部署列表拿到之後，把數據傳給應用部署系統裏面部署環境。部署環境裏面，部署哪些軟件、同步哪些配置文件，這些數據從哪取？從應用基線裏面取。應用基線裏面若是是空的，就從應用模板裏面獲取。當環境部署完成之後或者出了異常之後把具體信息返回給工單系統，工單系統能夠作一次重試任務或者結單。

（1）應用運維自動化實現-工單實例

這邊是具體使用的工單實例場景——新應用申請。有流程審批，流程審批結束之後，運維繫統裏面作的第一步，應用的基本信息插入到應用管理系統裏面，同時設備管理系統裏面自動的建立分組，分配機器。機器分配完之後去部署環境，同時添加相應責任人的權限。這幾個步驟基本上都是所有自動的。有問題的時候會停留在具體工單上面，運維人員會作這一塊的重試或者查看工單詳情，看哪一塊出了問題。

（2）集成發佈系統

對於運維開發還有一塊須要關注的是集成發佈系統。集成發佈系統的功能就是把代碼部署到線上服務器。當咱們把一個應用包編譯打包完成之後，須要將這個應用包發佈到具體的服務器到應用部署發佈完成通過如下幾個步驟：

首先檢查一下環境完整不完整，發佈系統檢測一下目前機器上面的部署環境是否完整。確認部署環境沒有問題後，發佈系統把應用包同步到對應的服務器上面；接下來經過監控系統接口關閉相應服務器上監控項；接下來執行應用目錄下的應用啓停腳本，通知RPC調用方或Web代理該服務器即將下線；暫停必定時間後，再執行應用啓停腳本中中止指令，停掉Nginx和Web容器；確認應用服務中止後，將應用包同步到運行目錄裏面解壓、啓動應用。

啓動應用時如何知道應用是否啓動成功了呢？經過咱們前面定義的，每一個應用裏面上線必需要遵循的規則自檢的程序來判斷（發請求/status檢測）。若是請求返回SUCCESS時，則說明應用啓動成功了，不然認爲失敗；確認成功後，通知RPC調用方和WE代理該服務器能夠正常服務了。

（3）監控系統

還有一塊是監控系統，當咱們應用上線完了應用都啓動成功了，把應用服務器狀態調整成Online，這樣能夠把監控系統自動觸發針對該應用進行監控。咱們會根據部署類型，部署不一樣類型定義不一樣的監控模板，固然業務方也能夠自定義監控項。

（4）全鏈路跟蹤分析

當從原來一個單一的應用演變成多個應用，之間的業務依賴關係如何進行管理，針對這塊需求，咱們跟穩定性團隊共同開發了一套「全鏈路跟蹤分析系統」。在咱們流量的入口把全鏈路的功能模塊嵌入進去，要求全部標準化的應用都引用了全鏈路的二方包，流量入口到底端構成了整個鏈路，經過這個鏈路分析對應的應用依賴關係。

在全鏈路跟蹤分析系統中，能夠看到應用自身提供的服務和依賴的服務，以及各個服務後端依賴的鏈路；當咱們出現問題的時候，在這個系統裏面直觀地能夠定位到哪個業務出了問題和哪一個服務出了問題。

除了應用總體的依賴關係之外，還能夠根據具體的鏈路分析出來整條鏈路上下游依賴關係，這條鏈路的這個請求進來之後依次通過哪些系統，並且系統與系統的調用關係是多少，在全鏈路分析系統裏面咱們均可以看獲得。全鏈路分析系統是咱們運維這邊比較重要的一個定位排查的系統。

（5）運維一站式管理平臺

咱們前期作了不少運維繫統，如應用管理的、域名管理的、服務器管理等，涉及到各個運維資源管理。但這種分系統部署管理給業務開發會帶來問題，須要一個信息之後，須要在不一樣的系統之間進行切換去察看相應的信息，這對開發來講是比較痛苦的。所以咱們目前正在作一站式的運維管理平臺，但願以業務的維度把全部的運維資源都展現在一塊兒，並結合相應的運維工。

這一套系統裏面分紅兩塊：第一塊是部門維度的。咱們基於部門能夠看這個部門下面全部的業務有哪些業務以及相應的人員，除此以外還能夠看到這個部門消耗的資源有哪些。旁邊這一塊有服務器利用率統計裏面能夠看到整個資源的消耗，這個部門下面有多少個業務，每一個業務消耗的服務器資源有哪些、利用率是多少。

第二塊應用的詳細信息，應用裏面會把全部應用相關的資源都定義好，在這裏面展現出來。咱們能夠在這個平臺裏面綜合的看到這個業務總體的狀況。目標是想打造一套NOOPS運維平臺，固然這是基於穩定性和安全的狀況下，把運維操做讓業務同窗自主的去完成的，不須要運維同窗過多參與，提升開發的工做效率。

咱們目標是NOOPS，目前正在路上，謝謝你們！

Q&A

Q1：內部Ops平臺已經成型了。我想問一下PE蘑菇街這邊的歷程，如今是怎樣的？

A1：蘑菇街前期PE主要是負責業務穩定性這一塊，資源分配、環境管理這一塊。慢慢的iPaas這個平臺上線，平常運維工做逐步減小後，之後咱們PE會更多關去心使用服務器資源使用率和成本。

End.

來源：公衆號「DBAplus社羣」

運行人員：中國統計網小編（微信號：itongjilove）

微博ID：中國統計網

中國統計網，是國內最先的大數據學習網站，公衆號：中國統計網

http://www.itongji.cn