技術員看雙11

雙11業務生態

在開始介紹這些挑戰以前，咱們先用一張圖來看一看，做爲消費者，你在2013年的雙11大促中都會經歷哪些業務過程，如圖1所示。

圖1  雙11大促時的業務過程

首先，你會經過各類終端（PC、手機、平板）訪問淘寶、天貓、聚划算的導購市場，豐富多樣的導購產品會幫助你發現和挑選本身心儀的商品。大數據的基礎平臺支撐了大量有價值的數據應用，以保證你在這個環節的購物體驗。穩定的交易平臺確保了優惠價格的準確計算、庫存的及時扣減和擔保交易的訂單有效生成。這時，你就能夠經過支付寶安全放心地進行支付寶餘額或者網上銀行支付，滿心歡喜地等待包裹的送達。

這時就開始輪到面向商家的系統忙碌起來了。聚石塔提供的雲推送功能在第一時間將交易訂單同步到部署在聚石塔雲工做平臺上的商家ERP、WMS、CRM軟件中，而且爲這部分軟件提供了動態彈性擴容的能力和安全方面的有效保護，以便大商家在大量訂單面前，能夠像平常狀況同樣，快速組織商品出庫和發貨，而不用額外擔憂本身軟件的處理能力。

最後出場的是菜鳥網絡打造的雷達預警系統，經過大數據的力量，對商家的備貨、消費者購買行爲、物流服務能力進行預測，並與國家氣象局、交通部實時發佈的天氣、道路狀況進行同步運算，將將來半天至七天的預測結果反饋到13家快遞公司，以便快遞公司提早調配運力。最終，全部的包裹得以第一時間送到消費者的手中。

挑戰和技術準備

業務跨數量級的快速發展對總體架構帶來了新挑戰

經歷了過去幾年「去IOE」（IBM小型機、Oracle、EMC高端存儲）總體架構改造，整個阿里集團創建了基於中間件、PC Server的輕量級分佈式SOA架構，保證了服務器、數據庫、網絡、機房各個層面無單點，能夠以較小的成本支持水平擴展，提高網站的負載能力。但隨着這幾年雙11業務的飛速增加，PV、同時在線用戶數、峯值交易和峯值支付等核心指標都開始跨越到新的數量級，架構在更高負載能力要求下的一些缺陷開始暴露出來。

• 第一，大規模訪問請求帶來的機房網絡瓶頸。

雙11當天有數億用戶訪問天貓和淘寶的系統，高峯期甚至有數千萬人同時在線。以天貓的「商品詳情」頁面爲例，集羣峯值QPS達到了十萬以上的量級，是平時峯值QPS的數十倍。這樣的突發性流量增加，使得機房的網絡容量面臨着巨大壓力。如何可以利用合理的成本應對瞬間飆高所帶來的網絡壓力，確保活動完整週期內用戶響應時間的穩定性，以及局部出現問題時的高可用性，成了首先須要面對的問題。

着眼於將來，從2011年起，咱們就開始了對瀏覽型的應用進行新的架構改造。歷經頁面細粒度的動靜分離、統一緩存接入、CDN靜態化三個階段。最終，將更新頻率不高的內容僞靜態化直接緩存到CDN，經過統一的秒級失效機制控制緩存的更新操做，讓絕大多數內容請求不須要回流到主機房，直接在用戶最近的CDN節點就可以完成。這種方式一方面極大地緩解了主機房網絡的壓力，另外一方面也優化了用戶頁面的響應時間。徐昭的《天貓瀏覽型應用的CDN靜態化架構演變》將帶你們更深刻地瞭解咱們是如何經歷這一過程的。

• 第二，超大規模系統如何繼續保持在不一樣層面上的水平伸縮性。

首先，服務器需求的增多，致使將來單一地區的IDC資源已沒法知足容量增加的需求，機房供電能力成爲短時間內沒法逾越的瓶頸。其次，簡單地橫向擴展IDC機房，機房之間的網絡流量又成爲了新的瓶頸。多機房的應用、緩存、數據庫等訪問的相互穿透，也加重着跨機房的流量增加。最後，核心服務集羣的應用服務器的規模增加，使對應的數據庫鏈接數成爲了瓶頸。每增長一臺數據庫服務器，對應的應用服務器都須要鏈接上來，數據庫的鏈接數立刻就不夠分配了。也就是說，在今天的業務規模下，咱們沒法繼續針對核心服務的數據庫層再作橫向的水平擴展了。

爲了解決以上問題，2013年雙11咱們嘗試了新的邏輯機房的架構方案，將數據水平拆分（Sharding）的思路向上提到接入層。以支付寶爲例，先將完成某一特定業務須要的系統、核心服務、數據庫組合抽象成一個業務單元（Zone）的概念，業務單元從應用服務器、緩存到數據庫能夠獨立封閉運行。而後，從入口處根據用戶請求路由到不一樣的邏輯業務單元，實現了單元級別的可伸縮性。再也不依賴同城IDC，讓交易、支付這樣複雜的業務單元具有了大規模跨地域部署的能力。胡喜的《支付寶的架構變遷》會有更加深刻和全面的介紹。

• 第三，如何更大程度地「壓榨」單服務器的系統資源。

虛擬化技術已做爲各大網站提高物理機資源利用率的基礎技術。以天貓和淘寶網爲例，2010年咱們引入Xen虛擬化技術，1臺物理機裝3個虛擬機，必定程度上下降了成本。但隨着機器規模的快速增加，咱們發現其中1/3的虛擬機的Peak load<0.5，這意味着咱們的運維成本仍是不夠低。主要有如下幾方面緣由：

1. 單臺物理機上跑的應用不夠多；

2. 分給應用的機型及機器數是靜態的；

3. 集羣的資源利用率不均衡。

爲了最大化物理機的資源性能，從2012年開始，咱們大規模地應用了新的基於LXC的虛擬化方案，成功地在每臺物理機（16Core/48GB）運行了12個應用實例，物理機的load提高到2~10。這對大促時期的成本控制很是有幫助，也爲內部私有云的完整構建，摸索了一條可行的路徑。

消費者對用戶體驗有了更高的要求

• 千人千面的購物體驗

有一個很現實的問題擺在了咱們面前：大促當天有幾億消費者會來到咱們的網站，在上百萬商家和過億商品裏面挑選本身心儀的寶貝。光靠運營人肉製做的活動頁面和消費者的主動搜索已遠遠不可能知足需求。所以，須要在產品上轉變思路，營造從以業務爲中心到以用戶爲中心的大促體驗。雙11應該是面向消費者的「個人雙11」，而不是「天貓的雙11」。

基於此，2013年的雙11大促中大面積應用了個性化算法，從PC到無線，從「會場」到「詳情」，真正意義上爲消費者打造了一個「個人雙11」。從最終效果來看，2013年雙11的用戶購買轉化率提升了10個百分點。張奇會在《個性化技術在雙11的應用》中介紹在個性化推薦系統架構、機器學習算法應用和算法的快速評測方面的思考。

• 多終端的業務一致性

移動智能終端的快速崛起，讓更多的消費者能夠隨時隨地訪問天貓和淘寶，但也讓咱們開始深刻地思考，在業務快速發展的前提下，如何在不一樣終端上快速提供本質相同的服務。2013年咱們首次在預熱期的大型活動中嘗試了基於Canvas的Web App解決方案，極大程度地提高了開發效率。天貓前端團隊的鄢學鵾會在《雙11的前端實踐》一文中分享Mobile First的理念是如何在雙11中實踐的。

穩定性的極致要求

• 容量預估、依賴治理、監控

這一環節是歷年雙11技術成功與否的關鍵環節。中間件團隊的《中間件技術的雙11實踐》除了會介紹在SOA架構體系中扮演重要角色的中間件產品以外，也會就容量預估、依賴治理和監控的雙11實踐作精彩介紹。

• 業務降級、限流預案

從2010年雙11開始，每一年都會針對性地準備一些技術預案，在流量超出預期時作好限流保護，在局部系統處理能力出現瓶頸時進行優雅降級，以提高總體的吞吐率，保證核心業務的正常運行。

2013年，咱們在技術環節準備了2000多套應急預案，大到遭受駭客***、各種業務應急動做，小到服務器機房空調發生故障，均有詳細預案。不只各服務器機房，甚至西溪園區雙11大促指揮辦公現場都準備了柴油發電機。此外，2013年針對雙11進行了上百次的內部演習，其中全網大規模演習就進行了10餘次，以確保每個預案的有效性。

• 全鏈路壓測

壓力測試對於評估網站性能的重要性是不言而喻的，但不管是線下模擬的單一集羣壓測，仍是線上引流壓測，都只能暴露一些基本的單點問題。對於雙11當天高峯期的真實壓力模擬，這兩種傳統的壓力測試方式還存在着巨大誤差。

首先是業務處理鏈路的複雜性，對於像天貓這樣一個分佈式處理平臺，一筆交易的建立會涉及多個應用集羣的處理，在能力評估時也應該考慮的是一個處理鏈路而不只僅是單一應用集羣的處理能力。其次是應用以外的風險點，像網絡、數據庫等，很難在傳統壓測中體現出來。

爲了精確評估核心交易集羣中各個環節的能力瓶頸，2013年咱們實現了一套新的全鏈路壓測評估體系。經過線上真實用戶數據與人爲測試數據相結合的方式，首次成功地在生產環境中模擬出相對真實的超大規模訪問流量，將前端系統、網絡、數據庫等一整套系統環境完整地歸入壓測範圍，貼近實際的應用場景，爲評估淘寶和天貓交易核心鏈路的實際承載能力提供有說服力的數據依據。這一方面能夠驗證交易核心鏈路上各類限流和預案的準確性，另外一方面也能夠充分暴露全鏈路上的各類瓶頸和隱藏的風險點，讓壓力測試的工做真正落實到了肯定性的層面上。

基礎運維能力提高的預研

在支撐好現有業務的同時，如何將基礎運維能力（高穩定性、彈性調度、低能耗、快速交付等）提高到新的量級，成了阿里技術團隊將來面臨的新挑戰。爲了迎接這方面的挑戰，2013年雙11咱們也小範圍作了一些面向將來的基礎運維預研工做。

首先，能夠預見的是，隨着業務的不斷髮展，阿里會有愈來愈多IDC布點。雖然邏輯機房的方案已能解決交易支付環節場景下的跨機房調用問題，但隨着雲計算的推廣，咱們依然面臨着大量跨機房調用的場景。現階段，交換機的網絡路由主要是基於IP作簡單識別，並不會經過識別應用類型提供智能調度。當大規模出現多個IDC時，跨機房的用戶體驗問題會愈來愈成爲瓶頸。爲了解決這一問題，咱們2013年在交換機的OS層面作了大量自主研發工做，定製自主的交換機OS，實現軟件定義網絡（SDN），對管控和成本兩個層面都有較大的改進。龐俊英的《阿里的SDN實踐》將簡單介紹咱們如何讓應用流量經過SDN識別出來，從而實現不一樣流量的長途鏈路和短途鏈路調度。

其次，在將來的3~5年，阿里的服務器將擴大到幾十萬甚至百萬級的規模，若是延續之前按服務器進行交付的模式，交付速度和能耗都會很快出現瓶頸。所以，咱們2013年嘗試了整機架服務器解決方案，經過標準化、流程化、定製化，解耦各個交付環節在IDC現場部署的時間串行關係，提高交付的質量和效率。除此以外，其中例如統一機架Backbone模塊這樣的設計，將總體的耗電量下降了接近10%。放在百萬級服務器的規模下，無疑會節省一筆極大的開銷。武鵬的《阿里整機架服務器解決方案》會展現咱們在低能耗、快速交付上的思考和方案。

經驗小結

對於技術人員而言，雙11絕對是一次奇幻體驗，在這裏有豐富的場景能夠實現我的技術上的奇思妙想，同時也經歷着最極致的技術考驗。經歷了5年雙11，我來小結一下技術準備上的一些經驗心得。

提早明確架構目標。

架構和基礎技術的調整每每帶來應用系統的傷筋動骨，前面介紹的一些大架構改造，週期每每須要2~3年，試錯成本很是高。所以對於架構師和技術核心決策者而言，要有足夠的前瞻性，在選型設計上必定從全局發展和核心問題出發，準肯定位、明確目標，才能統一團隊的總體方向。

不過分追求過程當中的完美。

咱們在內部總把系統架構的過程類比爲建造水壩——上下游級聯，同時兼顧對於全局生態的影響。但落實到實施層面纔是挑戰的開始，你們老是會傾向於考慮是否優雅完美，從而讓方案的複雜度不斷提高。架構師須要可以兼顧成本、資源、時間等各方面的因素，勇於作取捨，敢於捨棄一些收效甚微的優化。到準備後期更是如此，發生問題不可怕，可怕的是解決問題的時候又引入新問題。沒有100%完美的方案，能知足業務現階段發展須要的方案就是好方案。

細節決定成敗。

分佈式系統的好處在於鬆耦合、靈活性和可快速擴展，但同時也帶來了一系列麻煩，包括數據的一致性、分佈式事務、各類應用在服務層的數據相互干擾等。在大促這樣的峯值壓力下，這些小問題都會被無限放大。所以，前期準備過程當中要謹記不能放過任何微小的細節，僥倖心理更是萬萬要不得，擔憂出問題的角落每每必定會出問題，最沒問題的地方或許會是風險最大的地方。另外，儘量工具化一切人爲操做環節，在架構上作好約束，同時時刻確保留有「Plan B」，只有這樣纔可以確保對最終結果有把握。