【51CTO.com原創(chuàng)稿件】今年的蘇寧 O2O 購物節(jié)，我們提出了“零事故”的挑戰(zhàn)目標(biāo)。全面投入，全面聚焦，全力打響了 2017 年的最終沖刺戰(zhàn)。

??

[[209351]]

本文從前端保障、APP 運(yùn)維、網(wǎng)絡(luò)支撐和服務(wù)監(jiān)控四個方面全面回顧蘇寧易購的大促保障之道。

前端保障

為了保證更好的用戶體驗(yàn)，蘇寧前端一直都力求了解用戶端打開前端 Web 頁面的準(zhǔn)確性能，獲得網(wǎng)站的訪問速度和渲染性能，來調(diào)整頁面的元素和網(wǎng)絡(luò)配置，并通過引入 WEEX 等技術(shù)手段來提高 Wap 頁面的打開體驗(yàn)。

01.瀏覽器端測實(shí)時監(jiān)控用戶頁面狀態(tài)

在今年的 O2O 購物節(jié)中，蘇寧啟用了瀏覽器端測，來獲得用戶的真正性能數(shù)據(jù)。與機(jī)房的訪問相比較，它通過放置于 Web 頁面上的 JS來收集性能數(shù)據(jù)，更能反映用戶端的真實(shí)情況。

在大促過程中，用戶的訪問量激增，CDN 節(jié)點(diǎn)也會面臨更大的壓力，通過瀏覽器端測，可以獲取實(shí)時的用戶速度，并通過關(guān)鍵頁面的報(bào)警設(shè)置，使我們可以在用戶端問題爆發(fā)之前，快速行動，解決網(wǎng)絡(luò)問題。

??

同樣的，訪問量的增加，也會加劇后端的接口壓力，同時瀏覽器的腳本兼容問題也會影響更多的用戶。

借助瀏覽器端測，系統(tǒng)可以實(shí)時的捕捉到瀏覽器端的 JavaScript 錯誤，更快的定位問題，保證用戶體驗(yàn)。

今年雙十一大促中，瀏覽器端測還會在用戶問題的定位排查，慢頁面追蹤，地域問題分布等各方面，發(fā)揮更大的作用。

??

02.WEEX 加速 APP 端 Wap 頁展現(xiàn)

這次大促我們在客戶端內(nèi)大范圍使用了 WEEX 方案，目的是為了更好的提升用戶體驗(yàn)，提升頁面的性能。

在使用 WEEX 之前，系統(tǒng)每次打開 H5 頁面都需要有一個 webview 的加載過程，這個過程對用戶不是那么友好，使用 WEEX 之后會直接調(diào)用原生的加載方式，整個加載場景會變得很流暢，用戶不會被一些突兀的加載降低使用體驗(yàn)。

大促期間曝光量需求最高的就是主會場，最終我們采用了主會場 WEEX 定制開發(fā)的方案，這樣更好的保證了主會場的獨(dú)立性和穩(wěn)定性，使主會場能更好的承載大量用戶的訪問。

同時還有大量的促銷頁需要開發(fā)，針對每天都變的促銷頁我們開發(fā)了大量的 WEEX 模塊，使運(yùn)營有動態(tài)搭建 WEEX 模板的能力，在后臺可以輕松搭建出豐富多彩的頁面。

針對各種模塊的動態(tài)組裝，我們定義了一些特殊場景，減少了一些不必要的模塊沖突，減少運(yùn)營操作出錯的概率。

針對一些公司特有的業(yè)務(wù)，我們把之前 H5 的邏輯重新用 WEEX 的方式重構(gòu)了一次，使其滿足兩端業(yè)務(wù)，大大提高了開發(fā)效率和維護(hù)成本，真正做到 write once，run any where。

同時和客戶端一起重新封裝了 JSBridge，使其更加的通用，共享同一套 api，減少學(xué)習(xí)成本，易用性更強(qiáng)。

??

使用 WEEX 對前端來說可以更好的開發(fā)一些原生的需求，給一些因?yàn)榘姹緦徍硕鵁o法及時上線的需求提供了解決思路；對于用戶來說獲得了更好的用戶體驗(yàn)。

技術(shù)本來就是為用戶服務(wù)，如果能使用戶在使用過程中擁有良好的用戶體驗(yàn)就是一個成功的技術(shù)方案。

APP 運(yùn)維

在 O2O 購物節(jié)期間，蘇寧易購移動 APP 面對巨大的流量，單一的技術(shù)方案必然不能解決用戶環(huán)境復(fù)雜多樣所產(chǎn)生的問題。

所以我們不僅使用全面精準(zhǔn)的 APP 實(shí)時數(shù)據(jù)監(jiān)控，同時還通過靈活的配置配合多樣的、針對性的技術(shù)方案，實(shí)時調(diào)整目標(biāo)用戶 APP 的技術(shù)運(yùn)行方案，從而保障用戶在 O2O 購物節(jié)期間的購物體驗(yàn)。

01.全方位數(shù)據(jù)監(jiān)控，促成整體“零事故”

在 O2O 購物節(jié)期間，錯綜復(fù)雜的用戶環(huán)境必然會大大增加 APP 發(fā)生錯誤甚至崩潰的概率，全面、精準(zhǔn)的 APP 實(shí)時數(shù)據(jù)監(jiān)控是我們即時發(fā)現(xiàn)問題、解決問題的重要手段。

全面數(shù)據(jù)監(jiān)控，保證 APP“零事故”

我們擁有一套完善數(shù)據(jù)分析系統(tǒng)——云跡。通過云跡系統(tǒng)提供的快捷操作，可以即時的分析出 APP 不同版本、系統(tǒng)、運(yùn)營商、區(qū)域、設(shè)備下的 HTTP 訪問質(zhì)量、網(wǎng)絡(luò)劫持率、ANR 率、崩潰率等通用信息。

這樣既可以通過云跡系統(tǒng)提供的 APP 基本信息概覽圖進(jìn)行全面綜合監(jiān)控，也可以根據(jù)多維度的條件進(jìn)行篩選。

在 O2O 購物節(jié)期間，通過云跡后臺發(fā)現(xiàn)問題的時候，我們可以使用客戶端現(xiàn)有的熱修復(fù)、插件升級、Wap 頁替換等多套技術(shù)方案，對問題進(jìn)行即時修復(fù)。

與此同時，我們額外添加了核心業(yè)務(wù)的自定義數(shù)據(jù)采集，實(shí)時監(jiān)控核心流程處理的運(yùn)行狀況，實(shí)時預(yù)防問題的發(fā)生，保證 APP 的“零事故”。

精準(zhǔn)數(shù)據(jù)采集，協(xié)助服務(wù)端“零事故”

本次 O2O 購物節(jié)期間，我們在現(xiàn)有全面數(shù)據(jù)監(jiān)控的基礎(chǔ)上增加了另外一項(xiàng)核心功能——精準(zhǔn)數(shù)據(jù)采集。

當(dāng)通過云跡后臺、用戶反饋、電話反饋等渠道收集到用戶的報(bào)錯信息時，我們可以即時通過后臺多維度的配置，收集目標(biāo)用戶指定模塊、指定場景下的接口請求、本地操作等詳細(xì)信息，如接口的鏈接時間、報(bào)文大小、數(shù)據(jù)解析時間、可用內(nèi)存大小、網(wǎng)絡(luò)環(huán)境等。

采集到在 APP 端發(fā)生錯誤的用戶詳細(xì)信息后，我們可以通過這些信息聯(lián)合服務(wù)端開發(fā)，模擬錯誤發(fā)生的場景，一旦發(fā)現(xiàn)是服務(wù)端也存在業(yè)務(wù)數(shù)據(jù)處理邏輯的問題，第一時間進(jìn)行修復(fù)，從而做到協(xié)助服務(wù)端的“零事故”。

02.精準(zhǔn) DNS 解析，用戶訪問更穩(wěn)定

在 O2O 購物節(jié)期間，復(fù)雜多樣的用戶網(wǎng)絡(luò)環(huán)境必然會帶來各種 DNS 解析失敗、DNS 劫持的問題。

為了預(yù)防并解決該類問題的出現(xiàn)，在本次 O2O 購物節(jié)版本中，APP 端引入的 HTTPDNS 技術(shù)。

使用 HTTP 替代 UDP 的方式，提高 DNS 的解析精確率，同時配合云跡的監(jiān)控，結(jié)合不同區(qū)域的 DNS 解析情況實(shí)時配置 DNS 解析方案，最大程度的提升客戶端 DNS 的精準(zhǔn)解析。

另一方面通過 HTTPDNS，針對客戶端訪問量較大的接口，配置靈活的調(diào)度方案，緩解大量接口請求引起的局部服務(wù)器處理壓力，保證用戶訪問更穩(wěn)定。

03.網(wǎng)絡(luò)連接加速，用戶體驗(yàn)極致快

當(dāng)我們通過云跡后臺，發(fā)現(xiàn)接口網(wǎng)絡(luò)連接較長，或者是無法連接的情況時（特別是邊遠(yuǎn)地區(qū)的用戶），APP 在本次的 O2O 購物版本中額外提供的專有鏈路加速技術(shù)——可以對指定的域名、路徑進(jìn)行加速。

同時從 HTTP 升級到 HTTP2.0，通過鏈路復(fù)用、數(shù)據(jù)壓縮等手段，進(jìn)一步提升客戶端網(wǎng)絡(luò)數(shù)據(jù)的傳輸效率，全面加快本次 O2O 購物節(jié)期間所有用戶的數(shù)據(jù)訪問，頁面顯示更流暢，體驗(yàn)更極致。

網(wǎng)絡(luò)支撐

雙 11 大促的網(wǎng)絡(luò)保障包括公網(wǎng)和內(nèi)網(wǎng)兩方面：

• 公網(wǎng)保障，主要是指監(jiān)控并規(guī)避運(yùn)營商的網(wǎng)絡(luò)波動、CDN 節(jié)點(diǎn)宕機(jī)自切等互聯(lián)網(wǎng)問題的解決。
• 內(nèi)網(wǎng)保障，主要是機(jī)房網(wǎng)絡(luò)基礎(chǔ)設(shè)施的保障，包括出口帶寬、負(fù)載均衡壓力、交換機(jī)性能等的監(jiān)控，出現(xiàn)問題及時定位并解決。

整個網(wǎng)絡(luò)保障的體系如下圖所示，包括數(shù)據(jù)收集、故障發(fā)現(xiàn)、故障定位和故障處理四個方面。

??

01.網(wǎng)絡(luò)數(shù)據(jù)收集

網(wǎng)絡(luò)數(shù)據(jù)的收集需要覆蓋全面，任何一點(diǎn)的疏忽都會形成木桶短板效應(yīng)，成為大促時的風(fēng)險(xiǎn)點(diǎn)：

• 網(wǎng)絡(luò)設(shè)備的性能數(shù)據(jù)，包括出口帶寬、防火墻連接數(shù)和 CPU、負(fù)載均衡連接數(shù)和 CPU、交換機(jī)設(shè)備性能等。
• 服務(wù)器間延時和丟包數(shù)據(jù)，通過 Zabbix 實(shí)時探測服務(wù)器間的延時和丟包數(shù)據(jù)。
• 專線質(zhì)量，蘇寧 O2O 購物節(jié)時線下線上相融合，線下門店走專線回源站，專線的服務(wù)質(zhì)量數(shù)據(jù)需要收集并實(shí)時分析。
• 運(yùn)營商質(zhì)量，各運(yùn)營商的質(zhì)量通過主動撥測的方式來收集，并實(shí)時展示在監(jiān)控大盤上。

??

負(fù)載均衡設(shè)備連接數(shù)和 CPU 監(jiān)控

02.故障發(fā)現(xiàn)和定位

系統(tǒng)采集的性能數(shù)據(jù)落入 Kafka，通過規(guī)則引擎的分析，判斷是否已經(jīng)觸發(fā)了配置的告警，并通過短信和郵件的方式通知值班運(yùn)維。

運(yùn)維人員收到告警后，會針對不同情況進(jìn)行故障定位：

對于網(wǎng)絡(luò)設(shè)備異常、服務(wù)器之間丟包和延時的異常，需要探測設(shè)備狀態(tài)、檢查是否有設(shè)備自切情況。

對于出口帶寬告警，需要判斷是否有大量異常流量攻擊。

對于運(yùn)營商質(zhì)量告警，需要探測運(yùn)營商節(jié)點(diǎn)質(zhì)量。比如告警發(fā)現(xiàn)南京聯(lián)通地區(qū)有大量 TCP 連接超時異常，則運(yùn)維人員會通過手動撥測的方式去檢測當(dāng)?shù)剡\(yùn)營商節(jié)點(diǎn)狀態(tài)，定位超時是在哪一級路由造成的。

03.故障處理

以上面所說的運(yùn)營商節(jié)點(diǎn)故障為例，因?yàn)檫@也是最難處理的。如果是內(nèi)網(wǎng)網(wǎng)絡(luò)設(shè)備的問題，自動主備切換就能解決問題。

而運(yùn)營商路由節(jié)點(diǎn)的故障并不是我們所能控制的，當(dāng)遇到這種情況，我們會通過自建 CDN 機(jī)房的全網(wǎng)調(diào)度系統(tǒng)對問題網(wǎng)段的用戶進(jìn)行調(diào)度，避開受到影響的運(yùn)營商鏈路。

另外，對于雙 11 零點(diǎn)的瞬時流量峰值，網(wǎng)絡(luò)支撐層面也有成熟的應(yīng)對方案。

根據(jù)業(yè)務(wù)優(yōu)先級，我們會在零點(diǎn)到來前，加長次要業(yè)務(wù)的緩存時間，提前減少源站帶寬和負(fù)載連接數(shù)。同時，設(shè)置了負(fù)載連接數(shù)閾值，超過閾值會直接限流，不會產(chǎn)生雪崩的情況。

服務(wù)監(jiān)控

每次大促保障的重點(diǎn)基本都落實(shí)到服務(wù)，因?yàn)槊總€接口的性能，承載的業(yè)務(wù)，以及瞬間流量的沖擊都是對系統(tǒng)的極大考驗(yàn)。

尤其在零點(diǎn)的瞬間，承接著瀏覽，訂單，支付的具體壓力，流量瞬間會增加到成百上千倍，這就要求我們在面對這樣高流量的壓力下，提前準(zhǔn)備好應(yīng)對的預(yù)案，在流量承接的過程中如何去發(fā)現(xiàn)，解決類似的問題。

所以我們就從系統(tǒng)如何進(jìn)行容量規(guī)劃來準(zhǔn)備，通過實(shí)時監(jiān)控系統(tǒng)來發(fā)現(xiàn)問題，通過調(diào)用鏈監(jiān)控來定位解決問題。下面就從這三個方面簡單的闡述我們所做的工作。

01.如何規(guī)劃容量

容量規(guī)劃，是一個產(chǎn)品滿足用戶目標(biāo)需求而決定生產(chǎn)能力的過程。

當(dāng)產(chǎn)品發(fā)展到一個較為穩(wěn)定成熟的階段，對產(chǎn)品的整體處理能力的把控將不可或缺，盡管我們在線下做性能測試能夠獲得一些數(shù)據(jù)，通過這些數(shù)據(jù)來驗(yàn)證我們系統(tǒng)所能經(jīng)受的壓力。

一般我們通過四個步驟來進(jìn)行容量規(guī)劃：

明確目標(biāo)

目標(biāo)的確認(rèn)首先要根據(jù)歷史的數(shù)據(jù)，業(yè)務(wù)發(fā)展的速度，進(jìn)行一個比較準(zhǔn)確的預(yù)估。再評估我們未來三至五年的性能與數(shù)據(jù)的增量。根據(jù)這些我們會定一個合理的目標(biāo)預(yù)期值。

目標(biāo)如何達(dá)成

確定好目標(biāo)以后，根據(jù)系統(tǒng)的特點(diǎn)評估系統(tǒng)的特性，比如我們的商品詳情系統(tǒng)就是 IO 密集性的系統(tǒng)。

所以在擴(kuò)容的時候，我們會重點(diǎn)關(guān)注如何增加這方面的能力，在硬件條件受到限制的時候，優(yōu)先考慮通過系統(tǒng)的架構(gòu)進(jìn)行水平擴(kuò)容。

架構(gòu)調(diào)整完成以后，我們也會在平時的檢查中優(yōu)化系統(tǒng)性能。

線上壓測驗(yàn)證

通過一系列的優(yōu)化工作，我們會在線上進(jìn)行壓測驗(yàn)證：

• 線上引流，將線上其他節(jié)點(diǎn)的請求復(fù)制到被測服務(wù)器上，推薦使用 Tcpcopy 工具。　
• 測試數(shù)據(jù)，線上請求直接復(fù)制引流，無需準(zhǔn)備數(shù)據(jù)。

實(shí)施步驟如下：

• 將線上一臺節(jié)點(diǎn) off-line，按照 Tcpcopy 部署的方法部署 client 和 server，為了便于指標(biāo)的統(tǒng)計(jì)，通常將 Tcpcopy 部署在 nginx 所在服務(wù)器，被壓測服務(wù)器前需要增加一層 nginx 服務(wù)器。
• 將集群的其他節(jié)點(diǎn)流量復(fù)制到 off-line 節(jié)點(diǎn)上，可以通過 Tcpcopy –r 參數(shù)逐步增加復(fù)制系數(shù)，不斷增加 -r 參數(shù)直至超過設(shè)定的服務(wù)指標(biāo)。
• 如果全部的線上流量都不能壓測到 off-line 節(jié)點(diǎn)的瓶頸，那么就逐步放大引流系數(shù)。

監(jiān)控異常

線上監(jiān)控不僅用于集群歷史數(shù)據(jù)的收集，計(jì)算集群的實(shí)際負(fù)荷的監(jiān)控，還用于壓測過程中監(jiān)控約束條件中的各種指標(biāo)是否超限并停止壓測。

根據(jù)集群的特點(diǎn)和之前的性能測試經(jīng)驗(yàn)，關(guān)注容量指標(biāo)和約束條件的業(yè)務(wù)和資源指標(biāo)。而這里的歷史數(shù)據(jù)，是需要長期的采集和整理，進(jìn)而驗(yàn)證與監(jiān)控系統(tǒng)的健康狀況。

02.實(shí)時的線上監(jiān)控預(yù)警

準(zhǔn)備的再多也不能百分之百保障系統(tǒng)不出問題，所以在應(yīng)對可能出現(xiàn)的問題時，我們必須要在第一時間發(fā)現(xiàn)問題，并且制定一系列的相關(guān)措施。

以下就是我們應(yīng)對日常的突發(fā)情況建立的完善流程：

• 機(jī)制，目前我們各個研發(fā)中心不僅僅有短信、微信、郵件報(bào)警，24小時值班團(tuán)隊(duì)在第一時間發(fā)現(xiàn)問題還要電話給系統(tǒng)負(fù)責(zé)人，進(jìn)行及時反饋。
• 工具，我們會通過云際監(jiān)控系統(tǒng)，定制我們想看到的數(shù)據(jù)，如下圖。

這樣不僅僅能夠給我們的歷史數(shù)據(jù)進(jìn)行大數(shù)據(jù)對比分析，也能通過流量的監(jiān)控，進(jìn)行實(shí)時的預(yù)警，進(jìn)而在大促期間，我們能夠及時準(zhǔn)確的預(yù)估所有潛在的風(fēng)險(xiǎn)，及時進(jìn)行預(yù)案的操作。

??

03.調(diào)用鏈定位

因?yàn)橛辛送晟频念A(yù)警機(jī)制，所以我們在發(fā)現(xiàn)問題的時候比平時更加迅速的進(jìn)入狀態(tài)。

為了對線上的情況及時進(jìn)行處理并且讓系統(tǒng)快速的恢復(fù)到監(jiān)控狀態(tài)，我們快速的定位問題就需要了解當(dāng)時發(fā)生了什么，什么地方出現(xiàn)了錯誤。

所以我們引用了調(diào)用鏈，因?yàn)樗延脩舻囊淮握埱笸暾匿浵裣聛恚覀兛梢愿M(jìn)每個畫面進(jìn)行判斷具體在什么地方出現(xiàn)問題。

下面簡單的介紹下調(diào)用鏈監(jiān)控：

• 代碼級定位，輕量級 Agent，采集JVM、線程、SQL，調(diào)用鏈路等性能指標(biāo)，可分析表示層、業(yè)務(wù)層、數(shù)據(jù)層代碼執(zhí)行性能，給以最科學(xué)的代碼優(yōu)化參考。
• 侵入性低，安全穩(wěn)定，對代碼無侵入，對服務(wù)運(yùn)行無影響，有效保障代碼和數(shù)據(jù)的安全性。

因?yàn)橐陨系奶攸c(diǎn)我們在定位問題的時候非常的省時省力，通過下圖，我們可以很容易的發(fā)現(xiàn)系統(tǒng)產(chǎn)生的錯誤，而且能定位到具體那段代碼產(chǎn)生的錯誤。

??

結(jié)束語

為了準(zhǔn)備雙十一，我們其實(shí)還有很多的工作，在這里面就不一一列舉了。

短期內(nèi)我們還有很多的提升空間，未來我們會更加深入的運(yùn)用我們的大數(shù)據(jù)，AR 為用戶提供更加個性的購物體驗(yàn)，結(jié)合我們的線下實(shí)體店，讓用戶能夠深刻的了解到什么是 O2O 融合。

??

[[209355]]

黃小虎

蘇寧云商 IT 總部購物流程架構(gòu)負(fù)責(zé)人

全面負(fù)責(zé)蘇寧易購商品詳情頁、購物車、大聚會等核心系統(tǒng)的優(yōu)化及大促保障工作。對電商交易流程和業(yè)務(wù)有較深入的思考和研究，專注于高并發(fā)大型電商網(wǎng)站的架構(gòu)設(shè)計(jì)、高可用的系統(tǒng)設(shè)計(jì)。曾主導(dǎo)和參與了 Commerce 系統(tǒng)拆分、商品詳情頁接入層優(yōu)化、云信客服系統(tǒng)重構(gòu)等重大技術(shù)攻關(guān)項(xiàng)目?，F(xiàn)致力于打造蘇寧易購新一代核心購物流程系統(tǒng)，希望將購物體驗(yàn)做到極致。 

??

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】