關(guān)于蘑菇街

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

蘑菇街業(yè)務(wù)架構(gòu)-導(dǎo)購期(2011-2012)

運(yùn)維早期情況

早期階段(2011-2012年)

– 兩位數(shù)機(jī)器、個(gè)位數(shù)網(wǎng)絡(luò)設(shè)備。

– 沒有運(yùn)維，開發(fā)即運(yùn)維，靠牛逼的腳本和一些開源工具搞定。

蘑菇街業(yè)務(wù)架構(gòu)-轉(zhuǎn)型期(2013)

運(yùn)維的發(fā)展

中間階段(2013年-2014年)

– 三位數(shù)服務(wù)器、兩位數(shù)網(wǎng)絡(luò)設(shè)備

– 2-3名專職運(yùn)維同學(xué)(主機(jī)&網(wǎng)絡(luò)&DB&緩存&......) – 問題響應(yīng)式的工作方式

– 工具化的運(yùn)維平臺(tái)

• 機(jī)器資源管理(CMDB的雛形)
• PHP發(fā)布系統(tǒng)
• 從指標(biāo)維度監(jiān)控系統(tǒng)(主機(jī)、QPS、RT、調(diào)用次數(shù).... )

蘑菇街業(yè)務(wù)架構(gòu)-社會(huì)化電商

我們應(yīng)該怎么辦

思路：

• 建立以應(yīng)用服務(wù)為核心的管理標(biāo)準(zhǔn)體系。
• 打造CMDB、流程申請(qǐng)、持續(xù)集成和監(jiān)控為一體的自動(dòng)化運(yùn)維系統(tǒng), 而不是孤立的單點(diǎn)系統(tǒng)。
• 把運(yùn)維能力服務(wù)化(API)，使運(yùn)維的能力無處不在。 

關(guān)于應(yīng)用服務(wù)管理

案例介紹

讓我們看一個(gè)從服務(wù)器管理—申請(qǐng)—代碼發(fā)布—線上監(jiān)控的案例。

關(guān)于應(yīng)用服務(wù)器-Hestia服務(wù)和資源管理

• 從業(yè)務(wù)的維度來管理主機(jī)-CMDB的核心概念。
• 支持?jǐn)U容、上下線、設(shè)備保障、權(quán)限等常規(guī)流程申請(qǐng)。
• 自動(dòng)化任務(wù)的配置和下發(fā)。

關(guān)于應(yīng)用服務(wù)管理-Mops流程申請(qǐng)系統(tǒng)

關(guān)于應(yīng)用服務(wù)管理-發(fā)布系統(tǒng)

以trade_ordership_service為標(biāo)示,進(jìn)行代碼發(fā)布。

關(guān)于應(yīng)用服務(wù)管理-監(jiān)控系統(tǒng)Sentry

通用+自定義監(jiān)控，運(yùn)維+開發(fā)可以時(shí)刻關(guān)注自己的服務(wù)狀態(tài)和質(zhì)量。

運(yùn)維的現(xiàn)狀

專業(yè)的運(yùn)維團(tuán)隊(duì) – 系統(tǒng)運(yùn)維

– 應(yīng)用運(yùn)維 – DBA

– 運(yùn)維開發(fā)

• 運(yùn)維的能力向平臺(tái)化和服務(wù)化發(fā)展(DevOps,依賴于能力而不是人) – CMDB服務(wù)化平臺(tái)

– PHP+Java持續(xù)集成發(fā)布平臺(tái)

– 統(tǒng)一的監(jiān)控平臺(tái)

– 全鏈路服務(wù)質(zhì)量分析平臺(tái) – 穩(wěn)定性平臺(tái)

– 容量評(píng)估平臺(tái)(待做)

• 工作方式的改變

– 從問題響應(yīng)式,向整體解決方案提供方向發(fā)展

雙11技術(shù)保障，運(yùn)維做了什么?

雙11關(guān)鍵技術(shù)分享—全鏈路系統(tǒng)

全鏈路背景

• 復(fù)雜的分布式系統(tǒng),頁面上的一次鏈接點(diǎn)擊，在后端可能會(huì)產(chǎn)生幾十次的RPC調(diào)用，Web、服務(wù)化、緩存、 消息、DB.......都有可能涉及，如果出了問題，如何快速定位到故障點(diǎn)要擴(kuò)容，如何合理評(píng)估。
• 關(guān)鍵概念，全局唯一的TraceId。

全鏈路技術(shù)架構(gòu)

全鏈路應(yīng)用-快速發(fā)現(xiàn)問題點(diǎn)和瓶頸點(diǎn)

全鏈路應(yīng)用-調(diào)用合理性分析

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

全鏈路使用后的收益和后續(xù)

使用全鏈路后的收益

– 提升問題的定位效率 – 準(zhǔn)確的評(píng)估容量

后續(xù)

– Mogu-Watch，與前端打通，實(shí)現(xiàn)用戶全鏈路的分析 – 壓測做到平時(shí)，與容量評(píng)估平臺(tái)和資源分配打通。

– 引入云資源彈性擴(kuò)容，避免應(yīng)對(duì)峰值的批量機(jī)器采購。

壓測之后，關(guān)鍵技術(shù)改造-ATS靜態(tài)化方案

靜態(tài)化方案背景和簡介

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

– 資源類的如圖片、CSS、JS等的靜態(tài)化方案都會(huì)采用CDN技術(shù)。

– 對(duì)于頁面內(nèi)容類的數(shù)據(jù)，如商品名稱、商品詳情等都屬于靜態(tài)數(shù)據(jù)，而 商品的庫存、優(yōu)惠等則需要獲取動(dòng)態(tài)結(jié)果。

– 對(duì)于活動(dòng)頁面、H5活動(dòng)推廣頁面等，則可以完全靜態(tài)化。

ATS(Apache Traffic Server)靜態(tài)化技術(shù)方案-Cheetah

ATS靜態(tài)化案例-商品詳情頁

ATS靜態(tài)化使用后的收益和后續(xù)

• 使用靜態(tài)化后的收益

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

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

– 容量提升，減少了后端服務(wù)器的數(shù)量。

• 后續(xù)

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

– 支持HTTPS。

– 回源流控和容災(zāi)控制。

限流&降級(jí)開關(guān)推送和WEB應(yīng)急擴(kuò)容方案

• 限流&降級(jí)開關(guān)

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

– 降級(jí)，App層(服務(wù)化)，保障核心應(yīng)用。

• •Web應(yīng)急擴(kuò)容方案

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

– 資源利用率提升明顯。