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

??

[[209351]]

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

前端保障

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

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

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

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

??

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

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

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

??

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

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

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

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

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

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

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

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

??

使用 WEEX 對前端來說可以更好的開發(fā)一些原生的需求，給一些因為版本審核而無法及時上線的需求提供了解決思路；對于用戶來說獲得了更好的用戶體驗。

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

APP 運維

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

網(wǎng)絡支撐

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

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

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

??

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

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

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

??

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

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

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

運維人員收到告警后，會針對不同情況進行故障定位：

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

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

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

03.故障處理

以上面所說的運營商節(jié)點故障為例，因為這也是最難處理的。如果是內網(wǎng)網(wǎng)絡設備的問題，自動主備切換就能解決問題。

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

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

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

服務監(jiān)控

每次大促保障的重點基本都落實到服務，因為每個接口的性能，承載的業(yè)務，以及瞬間流量的沖擊都是對系統(tǒng)的極大考驗。

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

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

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

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

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

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

明確目標

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

目標如何達成

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

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

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

線上壓測驗證

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

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

實施步驟如下：

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

監(jiān)控異常

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

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

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

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

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

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

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

??

03.調用鏈定位

因為有了完善的預警機制，所以我們在發(fā)現(xiàn)問題的時候比平時更加迅速的進入狀態(tài)。

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

所以我們引用了調用鏈，因為它把用戶的一次請求完整的錄像下來，我們可以跟進每個畫面進行判斷具體在什么地方出現(xiàn)問題。

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

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

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

??

結束語

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

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

??

[[209355]]

黃小虎

蘇寧云商 IT 總部購物流程架構負責人

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

??

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