今年的蘇寧 O2O 購物節，我們提出了“零事故”的挑戰目標。全面投入，全面聚焦，全力打響了 2017 年的最終衝刺戰。

黃小虎

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

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

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

前端保障

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

1.瀏覽器端測實時監控使用者頁面狀態

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

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

同樣的，訪問量的增加，也會加劇後端的介面壓力，同時瀏覽器的指令碼相容問題也會影響更多的使用者。

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

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

2.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 購物節期間的購物體驗。

1.全方位資料監控，促成整體“零事故”

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

全面資料監控，保證 APP“零事故”

我們擁有一套完善資料分析系統——雲跡。通過雲跡系統提供的快捷操作，可以即時的分析出 APP 不同版本、系統、運營商、區域、裝置下的 HTTP 訪問質量、網路劫持率、ANR 率、崩潰率等通用資訊。

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

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

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

精準資料採集，協助服務端“零事故”

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

當通過雲跡後臺、使用者反饋、電話反饋等渠道收集到使用者的報錯資訊時，我們可以即時通過後臺多維度的配置，收集目標使用者指定模組、指定場景下的介面請求、本地操作等詳細資訊，如介面的連結時間、報文大小、資料解析時間、可用記憶體大小、網路環境等。

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

2.精準 DNS 解析，使用者訪問更穩定

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

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

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

另一方面通過 HTTPDNS，針對客戶端訪問量較大的介面，配置靈活的排程方案，緩解大量介面請求引起的區域性伺服器處理壓力，保證使用者訪問更穩定。

3.網路連線加速，使用者體驗極致快

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

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

1.網路資料收集

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

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

負載均衡裝置連線數和 CPU 監控

運營商質量監控

2.故障發現和定位

系統採集的效能資料落入 Kafka，通過規則引擎的分析，判斷是否已經觸發了配置的告警，並通過簡訊和郵件的方式通知值班運維。

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

• 對於網路裝置異常、伺服器之間丟包和延時的異常，需要探測裝置狀態、檢查是否有裝置自切情況。
• 對於出口頻寬告警，需要判斷是否有大量異常流量攻擊。
• 對於運營商質量告警，需要探測運營商節點質量。比如告警發現南京聯通地區有大量 TCP 連線超時異常，則運維人員會通過手動撥測的方式去檢測當地運營商節點狀態，定位超時是在哪一級路由造成的。

3.故障處理

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

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

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

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

服務監控

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

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

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

1.如何規劃容量

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

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

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

明確目標

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

目標如何達成

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

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

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

線上壓測驗證

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

• 線上引流，將線上其他節點的請求複製到被測伺服器上，推薦使用 Tcpcopy 工具。
• 測試資料，線上請求直接複製引流，無需準備資料。

實施步驟如下：

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

監控異常

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

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

2.實時的線上監控預警

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

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

• 機制，目前我們各個研發中心不僅僅有簡訊、微信、郵件報警，24小時值班團隊在第一時間發現問題還要電話給系統負責人，進行及時反饋。
• 工具，我們會通過雲際監控系統，定製我們想看到的資料，如下圖。這樣不僅僅能夠給我們的歷史資料進行大資料對比分析，也能通過流量的監控，進行實時的預警，進而在大促期間，我們能夠及時準確的預估所有潛在的風險，及時進行預案的操作。

3.呼叫鏈定位

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

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

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

下面簡單的介紹下呼叫鏈監控：

• 程式碼級定位，輕量級 Agent，採集JVM、執行緒、SQL，呼叫鏈路等效能指標，可分析表示層、業務層、資料層程式碼執行效能，給以最科學的程式碼優化參考。
• 侵入性低，安全穩定，對程式碼無侵入，對服務執行無影響，有效保障程式碼和資料的安全性。

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

結束語

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

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

原文來自微信公眾號：51CTO技術棧