本文根據白海強老師的主題演講《蘑菇街應⽤運維體系建設及運維⾃動化實踐》整理而成。

[[214089]]

本次分享的內容主要分為以下三個方面：

• 蘑菇街技術架構及運維演進
• 應用運維體系建設思路
• 應用運維自動化實踐過程

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

導購期（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 版等。

每個版本的規范里面都基本上定義了這些內容：

• 目錄：基礎軟件部署目錄和版本要求。
• 應用運行的用戶賬號是什么、權限是什么。

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

應用啟停腳本

接下來我們還規范了啟停腳本，定義了這個腳本里面傳的參數，可以支持哪些參數，啟動或者重啟；每條指令里面做什么事情都進行了說明和規范。

規范應用上線標準

除此之外還定義了一個業務上線之前要遵循的標準，上線的標準和下線的標準。

上線之前需要業務方提供標準的自檢功能，要怎么知道你這個應用是成功還是失敗的，那肯定需要有一個檢測機制告訴我，腳本里面通過這個檢測機制知道這個業務到底是否正常，這是一個強制性的規范。

下線也是一樣，上流根據定時檢測指定這個 URL，根據訪問結果判斷是否把流量自動地切掉。

標準化文檔里面主要就是規范上述一些內容，這些內容為后面的運維系統做了規范，我們運維系統都是基于這個規范來做。

應用運維自動化實踐過程

應用運維核心概念

1300 多個應用如何管理？在介紹應用管理之前需要重點介紹一下這幾個概念，這作為蘑菇街應用運維核心概念：

• 應用名代表在蘑菇街應用系統中具體業務的功能，不同的應用名用于區分不同的業務，我們按照一套業務代碼進行劃分。
• 應用名分組是用來組織管理服務器的。

兩者之間的關系是什么？一個應用下面可以對應多個應用分組。

這個分組按照什么維度來劃分的呢？可以根據環境，也可以根據穩定性的要求來拆分的。應用名作為應用運維的核心，運維系統都以應用名作為資源的組織方式。

應用管理系統

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

可以看一下這個圖，像這個業務是屬于哪一個部門的，開發者是誰，代碼 review 是誰，這個里面都會維護好。

除此之外還會定義這個應用的部署特征，這個應用部署類型是什么，這個比較關鍵。

后期的運維系統我們會拿著部署特征信息后做判斷應用于具體操作。應用管理系統中定義的每一個字段在后面運維系統里面都會存在一定關聯。

服務器管理

接下來服務器管理也有單獨的系統，服務器管理系統前面說了，分組是作為管理服務器的，在這一層可以看到我們整個層次結構分成兩層：部門下面是具體的應用，應用下面是分組。

應用分組默認有三個組：

• DEV 代表線下測試環境。
• PRE 代表預發環境。
• ONLINE 代表生產環境。

我們在分組上面建立了不同環境的標識，發布系統或其他運維系統就可以根據需求按應用的緯度獲取不同環境的機器列表。

同一個應用目前我們只分了三套環境：測試環境、預發環境和線上環境，一般默認對應 3 個應用分組。

但有時基于穩定性考慮，會把線上環境的服務器拆分成多個應用分組。假如某個應用是為其他應用業務提供基礎服務的。

如果調用服務不隔離管理的話，很容易出現穩定性的問題，如非核心業務調用量過大，導致核心業務調用失敗或超時。

基于上述問題，我們很容易想到解決方案就是把服務拆分成不同服務集群，讓核心業務調用 1 個服務集群，讓非核心業務調用另外一個集群。

這個需求 RPC 服務管理控制臺都可以實現 IP 與服務關系綁定，根據依賴業務重要程度區分出不同的服務集群，再根據不同集群調用量需求將服務器劃到不同的應用分組中進行管理，這個拆分分組是比較好的一個解決方案。

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

不拆分出應用分組，對于業務訪問是沒有影響的，因為應用分組的作用只是管理服務器，不會影響線上正常訪問。

但是運維系統是不知道應用業務內部邏輯訪問分組是什么樣，那些機器屬于同一個服務集群，操作時必須一起操作。

如果同一個集群一起操作的話，那線上的服務就掛完了；所以必須把這個體現出來，管理起來。

應用分組這個管理方式是比較靈活的，可以根據不同業務的特征建立不同的分組，比如說機房緯度、地域緯度等。

分組可以理解為是一個集群的概念，同一個應用分組下提供服務和服務對象都是相同的，這是服務器管理這一塊。

應用部署類型模板管理

同一類開發語言開發出來的業務應用對于部署環境依賴大致都是相同的。

基于這個特征，我們基于應用部署類型制定應用部署模板，用于管理同類應用部署服務器環境的需求。

我們基于不同部署類型建立對應的應用部署模板，如 Java 版、C++、GO 等。在這個模板里面我們定義了：部署的軟件和常規配置文件等內容。

舉個例子，Java 開發類應用，一般部署服務器環境所需要的包括一個 JDK，容器使用 Tomcat，Nginx 作為 Web 代理服務器；除此之外，我們還有可能需要啟停腳本和配置文件，用于保證環境正常運行。

應用基線管理

部署模板的用途是什么呢？它主要為應用基線提供服務的。

應用基線建立的維度我們是按照應用分組維度來建立的。一般情況下應用基線部署的內容配置都是從部署模板里面導過來的，基本上都能滿足相應的應用部署環境的需要。

當個別應用需要個性化的環境配置或軟件時，我們就可以針對相應的應用分組的應用基線進行修改補充，以滿足業務方的需求。

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

應用部署系統

通過前面幾個系統，我們基本上把環境、應用都管理起來了。但如何實現環境的自動化部署？

我們建立了應用的部署系統，應用部署系統里面定義什么呢？就是我們定義了部署環境的執行步驟。

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

運維工單管理

最后缺一個觸發的場景，能把上面各個相關系統串聯起來的系統。像申請服務器、擴容，新應用申請，因為這些都是業務開發提出了需求，如何組織在一起，跟我們的環境部署系統組織在一起呢？

通過運維工單的方式，需要業務開發提相應的工單，根據不同的工單把我們前面運維的步驟總的綜合在一起。

目前我們工單的范圍比較多，覆蓋了我們運維當中常見的一些運維需求，像服務器申請、新應用申請之類的。

這些步驟里面，每個工單里面都包含兩部分：

• 流程審批，因為有的人很反對流程，但流程是為了保證穩定性的手段而已。
• 工單，是具體做的事情。

應用運維自動化實現總結

接下來說一下整個過程，當運維開發提交一個工單給我們的時候，假設新應用申請，從新應用里面根據這個應用里面定義的內容獲取應用的配置信息。

應用的審核人員是誰，根據這個審核人員審批流程通過以后，會獲取對應系統里面部署的機器列表，根據部署列表拿到以后，把數據傳給應用部署系統里面的部署環境。

部署環境里面，部署哪些軟件、同步哪些配置文件，這些數據從哪取？從應用基線里面取。

應用基線里面如果是空的，就從應用模板里面獲取。當環境部署完成以后或者出了異常以后把具體信息返回給工單系統，工單系統可以做一次重試任務或者結單。

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

這邊是具體使用的工單實例場景——新應用申請。

有流程審批，流程審批結束以后，運維系統里面做的第一步，應用的基本信息插入到應用管理系統里面，同時設備管理系統里面自動的創建分組，分配機器。

機器分配完以后去部署環境，同時添加相應責任人的權限。這幾個步驟基本上都是全部自動的，有問題的時候會停留在具體工單上面，運維人員會做這一塊的重試或者查看工單詳情，看哪一塊出了問題。

集成發布系統

對于運維開發還有一塊需要關注的是集成發布系統。集成發布系統的功能就是把代碼部署到線上服務器。

當我們把一個應用包編譯打包完成以后，需要將這個應用包發布到具體的服務器，再到應用部署發布完成，經過以下幾個步驟：

首先檢查一下環境完整不完整，發布系統檢測一下目前機器上面的部署環境是否完整。確認部署環境沒有問題后，發布系統把應用包同步到對應的服務器上面。

接下來通過監控系統接口關閉相應服務器上監控項；接下來執行應用目錄下的應用啟停腳本，通知 RPC 調用方或 Web 代理該服務器即將下線。

暫停一定時間后，再執行應用啟停腳本中停止指令，停掉 Nginx 和 Web 容器；確認應用服務停止后，將應用包同步到運行目錄里面解壓、啟動應用。

啟動應用時如何知道應用是否啟動成功了呢？通過我們前面定義的，每個應用里面上線必須要遵循的規則自檢的程序來判斷（發請求/status 檢測）。

如果請求返回 SUCCESS 時，則說明應用啟動成功了，否則認為失敗；確認成功后，通知 RPC 調用方和 WE 代理該服務器可以正常服務了。

監控系統

還有一塊是監控系統，當我們應用上線完了，應用都啟動成功了，把應用服務器狀態調整成 Online，這樣可以把監控系統自動觸發針對該應用進行監控。

我們會根據部署類型，部署不同類型、定義不同的監控模板，當然業務方也可以自定義監控項。

全鏈路跟蹤分析

當從原來一個單一的應用演變成多個應用，應用之間的業務依賴關系如何進行管理，針對這塊需求，我們跟穩定性團隊共同開發了一套“全鏈路跟蹤分析系統”。

在我們流量的入口把全鏈路的功能模塊嵌入進去，要求所有標準化的應用都引用了全鏈路的二方包，流量入口到底端構成了整個鏈路，通過這個鏈路分析對應的應用依賴關系。

在全鏈路跟蹤分析系統中，可以看到應用自身提供的服務和依賴的服務，以及各個服務后端依賴的鏈路。

當我們出現問題的時候，在這個系統里面直觀地可以定位到哪一個業務出了問題和哪個服務出了問題。

除了應用整體的依賴關系以外，還可以根據具體的鏈路分析出來整條鏈路上下游依賴關系。

這條鏈路的這個請求進來以后依次經過哪些系統，而且系統與系統的調用關系是多少，在全鏈路分析系統里面我們都可以看得到。全鏈路分析系統是我們運維這邊比較重要的一個定位排查的系統。

運維一站式管理平臺

我們前期做了很多運維系統，如應用管理的、域名管理的、服務器管理等，涉及到各個運維資源管理。

但這種分系統部署管理會給業務開發帶來問題，查詢一個信息時，需要在不同的系統之間進行切換去察看相應的信息，這對開發來說是比較痛苦的。

因此我們目前正在做一站式的運維管理平臺，希望以業務的維度把所有的運維資源都展示在一起，并結合相應的運維工。

這一套系統里面分成兩塊：

第一塊是部門維度的信息，我們基于部門可以看這個部門下面所有的業務有哪些業務以及相應的人員，除此之外還可以看到這個部門消耗的資源有哪些。

旁邊這一塊有服務器利用率統計，里面可以看到整個資源的消耗，這個部門下面有多少個業務，每個業務消耗的服務器資源有哪些、利用率是多少。

第二塊應用的詳細信息，應用里面會把所有應用相關的資源都定義好，在這里面展示出來。

我們可以在這個平臺里面綜合的看到這個業務整體的情況，目標是想打造一套 NOOPS 運維平臺，當然這是基于穩定性和安全的情況下，把運維操作讓業務同學自主的去完成的，不需要運維同學過多參與，提高開發的工作效率。

我們的目標是 NOOPS，目前正在路上，謝謝大家！

作者：白海強（花名：普智）

簡介：目前在蘑菇街平臺技術部從事應用運維體系和其它建設工作，與團隊一起推進業務應用運維標準化及自動化系統的建設。在加入蘑菇街之前在淘寶任職，負責淘寶商品詳情等業務的運維工作。