關于蘑菇街

中國***的女性時尚社交電商平臺，成立于2011年，總部位于浙江杭州，目前(2015.Q3)擁有1.3億注冊用戶，雙十一日UV超2000萬。2015.11.21日宣布完成D輪融資，并實施"一街雙城"戰略，杭州+北京，杭州偏電商方向，北京偏社交媒體方向。

蘑菇街業務架構-導購期(2011-2012)

運維早期情況

早期階段(2011-2012年)

– 兩位數機器、個位數網絡設備。

– 沒有運維，開發即運維，靠牛逼的腳本和一些開源工具搞定。

蘑菇街業務架構-轉型期(2013)

運維的發展

中間階段(2013年-2014年)

– 三位數服務器、兩位數網絡設備

– 2-3名專職運維同學(主機&網絡&DB&緩存&......) – 問題響應式的工作方式

– 工具化的運維平臺

• 機器資源管理(CMDB的雛形)
• PHP發布系統
• 從指標維度監控系統(主機、QPS、RT、調用次數.... )

蘑菇街業務架構-社會化電商

 

我們應該怎么辦

思路：

• 建立以應用服務為核心的管理標準體系。
• 打造CMDB、流程申請、持續集成和監控為一體的自動化運維系統, 而不是孤立的單點系統。
• 把運維能力服務化(API)，使運維的能力無處不在。 

 

關于應用服務管理

 

案例介紹

讓我們看一個從服務器管理—申請—代碼發布—線上監控的案例。

關于應用服務器-Hestia服務和資源管理

• 從業務的維度來管理主機-CMDB的核心概念。
• 支持擴容、上下線、設備保障、權限等常規流程申請。
• 自動化任務的配置和下發。

 

關于應用服務管理-Mops流程申請系統

 

關于應用服務管理-發布系統

以trade_ordership_service為標示,進行代碼發布。

 

關于應用服務管理-監控系統Sentry

通用+自定義監控，運維+開發可以時刻關注自己的服務狀態和質量。

 

運維的現狀

專業的運維團隊 – 系統運維

– 應用運維 – DBA

– 運維開發

• 運維的能力向平臺化和服務化發展(DevOps,依賴于能力而不是人) – CMDB服務化平臺

– PHP+Java持續集成發布平臺

– 統一的監控平臺

– 全鏈路服務質量分析平臺 – 穩定性平臺

– 容量評估平臺(待做)

• 工作方式的改變

– 從問題響應式,向整體解決方案提供方向發展

雙11技術保障，運維做了什么?

 

雙11關鍵技術分享—全鏈路系統

全鏈路背景

• 復雜的分布式系統,頁面上的一次鏈接點擊，在后端可能會產生幾十次的RPC調用，Web、服務化、緩存、 消息、DB.......都有可能涉及，如果出了問題，如何快速定位到故障點要擴容，如何合理評估。
• 關鍵概念，全局唯一的TraceId。

全鏈路技術架構

  

全鏈路應用-快速發現問題點和瓶頸點

  

全鏈路應用-調用合理性分析

沒有明顯的瓶頸點，每一次調用RT也很正常，但是全鏈整體的RT卻很高，問題又出在哪里了呢?

 

全鏈路使用后的收益和后續

使用全鏈路后的收益

– 提升問題的定位效率 – 準確的評估容量

后續

– Mogu-Watch，與前端打通，實現用戶全鏈路的分析 – 壓測做到平時，與容量評估平臺和資源分配打通。

– 引入云資源彈性擴容，避免應對峰值的批量機器采購。

壓測之后，關鍵技術改造-ATS靜態化方案

靜態化方案背景和簡介

– 主鏈路(首頁-詳情&活動-交易-支付)，降低RT，提升容量。

– 資源類的如圖片、CSS、JS等的靜態化方案都會采用CDN技術。

– 對于頁面內容類的數據，如商品名稱、商品詳情等都屬于靜態數據，而 商品的庫存、優惠等則需要獲取動態結果。

– 對于活動頁面、H5活動推廣頁面等，則可以完全靜態化。

 

ATS(Apache Traffic Server)靜態化技術方案-Cheetah

 

ATS靜態化案例-商品詳情頁

ATS靜態化使用后的收益和后續

• 使用靜態化后的收益

– 詳情頁(全站流量的30%+)靜態化在雙11期間的***率達到95%，換言之，減少了后端服務接近30%的流量壓力。

– RT從原來200ms降低到50ms，用戶體驗大大提升。

– 容量提升，減少了后端服務器的數量。

• 后續

– 借助云資源搭建云上的ATS，更貼近用戶 – ATS Cluster方案。

– 支持HTTPS。

– 回源流控和容災控制。

限流&降級開關推送和WEB應急擴容方案

• 限流&降級開關

– 限流，Web層，防止被流量打垮。

– 降級，App層(服務化)，保障核心應用。

• •Web應急擴容方案

– 選擇Docker 容器，批量生成效率高 – 啟動速度快。

– 資源利用率提升明顯。