雙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，這意味着我們的運維成本還是不夠低。主要有以下幾方面原因：
單臺物理機上跑的應用不夠多；
分給應用的機型及機器數是靜態的；
集羣的資源利用率不均衡。
爲了最大化物理機的資源性能，從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”，只有這樣才能夠確保對最終結果有把握。