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

??

[[209351]]

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

前端保障

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

01.瀏覽器端測實時監控用戶頁面狀態

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

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

??

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

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

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

??

02.WEEX 加速 APP 端 Wap 頁展現

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

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

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

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

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

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

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

??

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

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

APP 運維

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

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

01.全方位數據監控，促成整體“零事故”

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

全面數據監控，保證 APP“零事故”

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

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

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

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

精準數據采集，協助服務端“零事故”

本次 O2O 購物節期間，我們在現有全面數據監控的基礎上增加了另外一項核心功能——精準數據采集。

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

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

02.精準 DNS 解析，用戶訪問更穩定

在 O2O 購物節期間，復雜多樣的用戶網絡環境必然會帶來各種 DNS 解析失敗、DNS 劫持的問題。

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

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

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

03.網絡連接加速，用戶體驗極致快

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

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

網絡支撐

雙 11 大促的網絡保障包括公網和內網兩方面：

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

整個網絡保障的體系如下圖所示，包括數據收集、故障發現、故障定位和故障處理四個方面。

??

01.網絡數據收集

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

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

??

負載均衡設備連接數和 CPU 監控

02.故障發現和定位

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

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

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

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

對于運營商質量告警，需要探測運營商節點質量。比如告警發現南京聯通地區有大量 TCP 連接超時異常，則運維人員會通過手動撥測的方式去檢測當地運營商節點狀態，定位超時是在哪一級路由造成的。

03.故障處理

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

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

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

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

服務監控

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

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

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

01.如何規劃容量

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

當產品發展到一個較為穩定成熟的階段，對產品的整體處理能力的把控將不可或缺，盡管我們在線下做性能測試能夠獲得一些數據，通過這些數據來驗證我們系統所能經受的壓力。

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

明確目標

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

目標如何達成

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

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

架構調整完成以后，我們也會在平時的檢查中優化系統性能。

線上壓測驗證

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

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

實施步驟如下：

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

監控異常

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

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

02.實時的線上監控預警

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

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

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

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

??

03.調用鏈定位

因為有了完善的預警機制，所以我們在發現問題的時候比平時更加迅速的進入狀態。

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

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

下面簡單的介紹下調用鏈監控：

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

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

??

結束語

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

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

??

[[209355]]

黃小虎

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

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

??

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