作者簡介：

劉驚驚，唯品會業(yè)務(wù)架構(gòu)部高級架構(gòu)師，負責唯品會電商平臺的用戶系統(tǒng)，營銷系統(tǒng)和庫存系統(tǒng)的架構(gòu)設(shè)計工作。2016年加入唯品會，參與了唯品會電商系統(tǒng)的大重構(gòu)，負責多個核心系統(tǒng)的梳理和大促準備。
 張廣平，唯品會企業(yè)架構(gòu)負責人，負責唯品會企業(yè)架構(gòu)管理工作，主持公司架構(gòu)評審運作；主持多個公司戰(zhàn)略級項目的架構(gòu)設(shè)計和支持工作；唯品會核心系統(tǒng)重構(gòu)總架構(gòu)師。

每年雙11是國內(nèi)各大電商貼身肉搏，激烈交鋒的時刻，同時也是把幾十天的交易量濃縮到一天釋放的日子。為了準備雙11的大促，各家都會在營銷、促銷、技術(shù)保障、物流、售后、客服等各個環(huán)節(jié)付出相當大的努力。唯品會作為中國第三大電商公司，自然也會在這場盛宴中付出自己的努力，收獲應有的成績。

唯品會是一家專注于特賣閃購的電商公司。業(yè)務(wù)系統(tǒng)為了支撐特賣的場景，在業(yè)務(wù)架構(gòu)上有一些鮮明的特點：購物車庫存扣減，特賣專場作為營銷和流量的入口，優(yōu)惠活動設(shè)置在專場維度，營銷觸達的周期性峰值明顯，自建物流系統(tǒng)支持分區(qū)售賣等。圖1給出了整個業(yè)務(wù)架構(gòu)的概覽。

隨著業(yè)務(wù)量的迅速增長，原有的PHP服務(wù)逐漸無法應對高并發(fā)大流量的網(wǎng)絡(luò)請求。為了支撐增長迅速的業(yè)務(wù)，唯品會在過去2年中啟動了大規(guī)模的重構(gòu)。在服務(wù)Java化過程中，基礎(chǔ)架構(gòu)部開發(fā)了的OSP RPC框架，采用帶Sidebar的Local Proxy + Zookeeper作為整個框架的核心組成部分，提供了去中心化的服務(wù)注冊、發(fā)現(xiàn)、治理的能力。

OSP框架還內(nèi)嵌服務(wù)追蹤機制，將服務(wù)調(diào)用路徑抽樣展示，便于監(jiān)控服務(wù)調(diào)用中發(fā)生的4xx/5xx錯誤，及時發(fā)現(xiàn)擁塞、調(diào)用錯誤等情況。

圖2  唯品會基礎(chǔ)架構(gòu)示意圖

由于唯品會特賣的特點，特賣專場集中在早上10點和晚上8點推出，特賣模式下流量峰值變化極大。業(yè)務(wù)特點決定了彈性云平臺對唯品會有極大的價值。唯品會搭建的Noah云平臺，在Kubernetes的基礎(chǔ)上，開發(fā)了與現(xiàn)有生產(chǎn)系統(tǒng)流程集成的一系列組件。其中包括支撐運維自動化的Noah API Server， DevOps使用的管理平臺Noah Portal，與S3存儲系統(tǒng)類似的分布式鏡像倉庫，以及自主研發(fā)的網(wǎng)絡(luò)方案、磁盤網(wǎng)絡(luò)隔離方案。 

為了應對雙11的峰值，唯品會借鑒HPA的思想，開發(fā)了自動擴縮容功能。所有容器均自動跨機器跨機架部署，純?nèi)萜饔蛟陔p機房部署并自動鄰近路由，混合域（物理機+容器）則支持一鍵切換物理機和容器流量，以及一鍵跨機房遷移等功能。

2017年雙11是Noah云平臺經(jīng)歷的首次大促考驗。共有52個業(yè)務(wù)域運行在云平臺上，其中在5個核心域上云平臺承擔了30%－50%的流量。

唯品會歷年大促峰值數(shù)據(jù)都會進行妥善的整理，核心業(yè)務(wù)系統(tǒng)按照不同的促銷等級，預估了不同的峰值流量。雙11按照去年12.8店慶的2倍來估算系統(tǒng)峰值容量。以用戶鑒權(quán)系統(tǒng)舉例，單臺服務(wù)器壓力測試約為25000QPS，全域提供約25萬QPS的服務(wù)能力，可以滿足2倍峰值量，本次大促就無需擴容了。

對于一些需要擴容的服務(wù)，如類目服務(wù)、庫存規(guī)則服務(wù)等，優(yōu)先選擇容器擴容。使用Noah云平臺進行擴容后，廣告、風控等系統(tǒng)的容器使用占比都達到了50%以上。起到了節(jié)省機器和彈性擴容的目的。

有了上述的基礎(chǔ)服務(wù)能力，線上壓力測試就有了基本的技術(shù)儲備。雙11來臨前，核心系統(tǒng)按照預估的容量進行了線上壓力測試。下面我們就以收藏系統(tǒng)作為例子，來展示的具體實踐經(jīng)驗。

收藏是唯品會會員應對特賣閃購模式的重要工具，收藏量的多少和收藏展示分類的數(shù)量，直接決定了整個大促的銷售成績，因此收藏系統(tǒng)的穩(wěn)定至關(guān)重要。在雙11到來之前，商品收藏和品牌收藏都進行了大面積的改版，業(yè)務(wù)從前到后均做了比較大的改動，并在雙11前1個月部署到生產(chǎn)環(huán)境。那么如何檢驗新版的收藏系統(tǒng)可以頂住大促的洪峰流量呢？下圖展示了收藏系統(tǒng)線上壓力測試的系統(tǒng)部署圖。

圖4 雙11大促收藏系統(tǒng)壓測示意圖

線上壓測的具體步驟分為以下幾個步驟：Top 10接口篩選，線上回放腳本準備，nGinder壓測集群搭建，壓測指標確認。

找到收藏系統(tǒng)日常Top 10訪問量的接口抓取線上日志（約占總流量的80%以上），生成線上回放腳本，按照去年店慶12.8的峰值流量的2倍給出了壓測目標值。線上壓測安排在凌晨流量最低的時刻，當達到壓測目標值的過程中，監(jiān)控系統(tǒng)情況，看看系統(tǒng)有沒有超時、異常，應用服務(wù)器的CPU、I/O、內(nèi)存等資源消耗情況。在整個壓測過程中，先后發(fā)現(xiàn)了物理機和容器流量不均勻的問題，若干接口請求到達1w QPS時，出現(xiàn)200ms超時等問題。通過調(diào)整權(quán)重以及分片數(shù)量等方法加以解決。

核心系統(tǒng)都通過類似的線上壓測的方法，發(fā)現(xiàn)了大量的潛在隱患，有力的保障了大促的順利進行。

核心系統(tǒng)對于依賴系統(tǒng)都準備了降級和災備方案。對于容易被黑產(chǎn)攻擊的脆弱部位，以及非重要業(yè)務(wù)都做了降級處理。大促降級分為以下四個方面：

1. 系統(tǒng)設(shè)計層面需要考慮兼容依賴系統(tǒng)服務(wù)不可用的情況

“Design for Failure”是一個非常好的設(shè)計原則，在系統(tǒng)設(shè)計中我們需要充分考慮依賴服務(wù)的可靠性，在依賴服務(wù)不可用時，需要有對應的策略。在核心系統(tǒng)梳理上面，著重梳理了對外部系統(tǒng)依賴部分，確定可以降級的依賴，以及無法降級的依賴。對于可以降級的依賴，在出現(xiàn)異常時，盡量保證服務(wù)的可用性，必要時果斷降級。對于無法降級的依賴，如核心數(shù)據(jù)庫宕機，直接啟動系統(tǒng)預案，避免錯誤的擴大化。

我們總結(jié)了一些實踐經(jīng)驗：

• 調(diào)用下游系統(tǒng)服務(wù)接口或者訪問緩存／數(shù)據(jù)庫時，需要設(shè)置超時時間

• 超時設(shè)定，打破部門墻，盡量不要在客戶端直接設(shè)定

• 對只讀方法設(shè)置重試

• 不是每個方法都適合熔斷，可單獨關(guān)閉，比如：支付的撈單接口，同一個接口處理多個銀行，權(quán)衡熔斷的利弊

• 主動降級，不依賴于客戶端開關(guān)，主動關(guān)閉某個方法，某個來源域

2. 非核心流程可使用開關(guān)關(guān)閉

非核心流程一般提供一些系統(tǒng)增強服務(wù)，如復購推薦，時效標識展示等。由于唯品會業(yè)務(wù)的特殊性，新專場上線有固定的時間點，所以峰值流量可以預計。在峰值流量到達的前后，關(guān)閉非關(guān)鍵路徑的業(yè)務(wù)，可以有效的降低系統(tǒng)的負荷，保障核心業(yè)務(wù)的可用性。

• 對于計算復雜，QPS不高的服務(wù)，會提前關(guān)閉，保障服務(wù)器的核心服務(wù)接口的可用性。比如促銷活動的試算開關(guān)。

• 對于非核心系統(tǒng)的大量數(shù)據(jù)同步，在峰值前后進行關(guān)閉。如自動促銷系統(tǒng)的數(shù)據(jù)抓取行為。
  我們的服務(wù)框架OSP提供了一個非常好的功能，可以有選擇性的關(guān)閉某些服務(wù)或者服務(wù)接口。

3. 核心業(yè)務(wù)降級預案

核心系統(tǒng)通過線下壓測，可以確認峰值的服務(wù)能力，在大促前進行擴容。并且按照測試峰值配置開關(guān)，當出現(xiàn)峰值告警時，打開開關(guān)，啟動限流，提供有損服務(wù)，保障數(shù)據(jù)庫平穩(wěn)渡過峰值。風控系統(tǒng)在峰值來臨前，會清理高危賬戶的登錄狀態(tài)，降低被攻擊的風險。

為應對容災需求，核心系統(tǒng)需要分別部署在全國范圍內(nèi)多個機房中，避免單機房出現(xiàn)故障情況下服務(wù)不可用。多機房部署帶來一些挑戰(zhàn)，如機房之間的服務(wù)調(diào)用延時、數(shù)據(jù)同步不一致性、專線的穩(wěn)定性等等，需要對應用系統(tǒng)以及所依賴的數(shù)據(jù)庫／服務(wù)系統(tǒng)做規(guī)劃設(shè)計。

對于一些基礎(chǔ)服務(wù)如用戶標簽，個性化推薦等，訪問量非常大。這些服務(wù)位于多個關(guān)鍵路徑上，一旦癱瘓，無法降級求生，因此需要多機房部署，做異地容災，才能保證核心系統(tǒng)的穩(wěn)定運行。

下圖展示了核心系統(tǒng) – 個性化推薦系統(tǒng)的同城雙機房部署的架構(gòu)。Guard模塊可以調(diào)用同機房的Scheduler流量調(diào)度模塊，也可以調(diào)用其他機房的Scheduler模塊，具體的調(diào)用路由配置中心下發(fā)。具體的觸發(fā)時機，可以是由配置中心手動下發(fā)，也可以由底層框架檢查出錯誤比例自動觸發(fā)。流量執(zhí)行模塊也是多機房部署，在災難發(fā)生時，可以保證一鍵切換，僅增加跨機房的毫秒級時延，對用戶無感知。

Guard模塊冗余的本地緩存，也會存儲一份保底數(shù)據(jù)，這部分數(shù)據(jù)在后端系統(tǒng)服務(wù)不可用時，起到保底作用。保證極端情況下展示頁面不留白，防止同城機房光纖全部被挖斷的情況。

圖5 個性化推薦系統(tǒng)同城雙機房容災

為了提高故障響應速度，引入了Hummer系統(tǒng)。Hummer是一個秒級監(jiān)控工具，會實時統(tǒng)計生產(chǎn)環(huán)境發(fā)生的生產(chǎn)日志，在發(fā)生系統(tǒng)異常情況下，更快的發(fā)出報警，方便技術(shù)人員、運維人員迅速排查問題，采取行動，降低損失。Hummer解決了下列幾個問題：

• 現(xiàn)有Metric統(tǒng)計結(jié)果延遲較大，分鐘級統(tǒng)計只能在分鐘結(jié)束后得到結(jié)果，不能實時更新分鐘內(nèi)的結(jié)果。

• 問題發(fā)生時，影響了運維的響應速度，會造成較大的損失。

• 秒級監(jiān)控之前都是獨立開發(fā)，不能通用。

• 不能高并發(fā)的訪問統(tǒng)計結(jié)果。

核心系統(tǒng)目前大部分都接入了秒級監(jiān)控Hummer系統(tǒng)。下圖展示了秒級監(jiān)控的監(jiān)控臺?？梢郧逦目吹匠龉收系沫h(huán)節(jié)。

大促技術(shù)保障是多部門的技術(shù)協(xié)作，從雙11前2個月各系統(tǒng)就開始了梳理和準備，經(jīng)歷了幾輪的系統(tǒng)梳理，壓測，問題總結(jié)和修復，核心代碼審查等工序，最終圓滿的完成了大促的保障任務(wù)，在這個過程中，團隊得到了鍛煉，系統(tǒng)問題得到了總結(jié)，加深了對系統(tǒng)的理解。