在24小時之內實現30億美元的銷售額，中國的電商巨頭阿里巴巴最近做到了這一壯舉。天貓和淘寶在處理這種規模的負載時遇到了哪些挑戰，又是如何應對這些挑戰的呢？InfoQ有機會就此向天貓和淘寶的架構師莊卓然和優曇請教了一些問題。
天貓是中國領先的B2C電子商務網站，而淘寶是中國最大的C2C在線購物平臺，二者都是阿里巴巴集團的子公司，總共有超過5億的註冊用戶。雙11大促活動今年已經是第4年，UV數總計達1.47億，實現總商品價值量（Gross Merchandise Volume）191億元人民幣（大約30億美元）。
面對“中國規模”電子商務的挑戰：
在2012年11月11日雙11大促當天，天貓和淘寶迎接了1.47億的用戶訪問，3000萬人的購買，產生了近1億筆支付訂單。在零點的一瞬間，併發在線的用戶數超過了1000萬。除了滿足雙11的各種功能需求之外，如何在前期準備過程中對系統有一個完整準確的評估，如何有效推進各種優化和容災預案，如何在活動當天各種緊急情況下正確決策，以及如何保證在頂級流量的衝擊下整個網站的穩定、性能和用戶體驗，這是對技術團隊的極大考驗。
雙11當天，天貓交易系統的峯值發生在第1個小時，當時系統每秒成功處理了1.3萬的下單請求。系統峯值QPS（每秒查詢數）爲4萬/秒，系統的平均響應時間在200毫秒。天貓的商品詳情頁面當天的系統訪問數高達16億次，峯值吞吐率達到了6.9萬次訪問/秒，並且在峯值時還保持了12毫秒的高響應能力。天貓搜索雙11當天PV高達5.9億，峯值吞吐率達到了1.4萬次訪問/秒。
莊卓然解釋到，從應用層面上講，天貓和淘寶的應用都構建於自主研發的服務化架構以及MVC框架和Spring之上。這是由分佈式文件系統、分佈式緩存、消息中間件和CDN網絡帶寬支持的。核心數據庫可以通過自主研發的數據訪問中間件訪問，底層數據庫的水平拆分和數據搬運對應用是完全透明的。
基於這種水平擴容架構，面對促銷活動引起的流量壓力，天貓和淘寶的系統可以靈活地添加機器來應對。
前期我們花了很多時間進行容量計算，對於網站所有應用之間的依賴關係、流量分配比例和應用內部的調用鏈路做了深入的分析，通過在線的壓力測試對各個應用單機的QPS進行準確評估，從而達到對網站目前集羣處理能力的客觀判斷。這個過程操作起來實際上是非常有挑戰的，因爲天貓和淘寶本質上不是一個耦合性很弱的系統，通過單一系統的壓測不能很好地反映系統的瓶頸。同時，我們也不可能完全照搬線上的環境和配置一套完整的壓力測試環境。所以會更多地依賴線上的壓力測試，真實地反映系統的短板。
最後，則是根據網站的自然增長趨勢和雙11的歷史數據，評估當天有可能達到的業務指標，再從這些業務指標對各個系統擴容目標進行準確地計算。
當然，僅僅依靠水平擴容方式，對於大促高峯過後的機器利用率是存在弊端的，同時也會大量依賴運維人員的靈活調配能力。因此，今年我們在以聚石塔（http://cloud.tmall.com）爲代表的一些應用中也嘗試了大量的彈性計算框架，在塔中很多商家的不同應用共用一個集羣的系統資源。雙11當天彈性升級帶寬、VM和存儲資源。同時，我們的很多內部應用也採用了這樣的機制。這也是今年在雙11準備過程中我們在技術上的一個突破。
在雙11大促的準備過程中，淘寶和天貓的團隊對系統進行了針對性的優化，包括SQL和緩存命中率的優化、數據庫連接和應用服務器參數的調整、JVM參數的配置、代碼的複審和梳理等等。此外，大量固態硬盤（SSD）的使用也提高了數據庫存儲的整體性能。
爲了在負載超過預期時關閉非核心操作，團隊也準備了業務降級和限流預案。
所謂業務降級，就是犧牲非核心的業務功能，保證核心功能的穩定運行。簡單來說，要實現優雅的業務降級，需要將功能實現拆分到相對獨立的不同代碼單元，分優先級進行隔離。在後臺通過開關控制，降級部分非主流程的業務功能，減輕系統依賴和性能損耗，從而提升集羣的整體吞吐率。
當出現了降級還無法緩解的大流量時，就要通過限流的方式來應付。首先從最前端的Web應用進行排隊，控制流入應用的流量，也就是通過Web服務器的定製模塊來實現QPS限流功能。根據被保護的Web服務器所能承受的最大壓力做強制的QPS流控，超出QPS上限的用戶進入排隊等待頁面。另外，爲了避免前端某個Web應用出現大規模流量激增時造成後端服務無法承載的雪崩效應，後端的服務會針對低優先級的業務進行限流，以確保不同來源的業務壓力不會壓垮後端服務，保障核心業務的訪問。
針對2012年的雙11，天貓和淘寶總共準備了400多個系統降級預案。 爲了保證所有降級和限流預案的準確執行，我們在前期做過了大量的預案演習，所有的應急預案雖然原則上我們一個都不希望使用，但是必須確保每個預案執行的準確性和便捷性。
應急決策過程：
雙11當天，我們有近400多位工程師集中辦公，確保整個活動的順利進行。整體流程上我們的目標是希望實現決策的最短路徑，並且保證信息傳達的簡單有效。那麼怎麼實現呢？首先我們會有一個戰地情報分揀中心，負責從客服、運營、安全、產品和商家等不同的信息來源收集和彙總各種用戶反饋，剔除重複和無效的反饋，確保不會出現技術團隊的信息爆炸。
其次，雖然我們會有一個戰地指揮部，但是應急決策的決定權大多數還是交由一線開發工程師的。所有集中辦公的工程師分工明確，每個應用都有1-2個核心負責人，他們會根據監控中心的各種系統指標變化情況，快速做出應急決策，確保響應的及時性。只有當涉及到對業務影響較大或是對用戶體驗傷害較大的時候，纔會升級到指揮部來進行判斷。
淘寶和天貓也有一個有效的開源策略，大量代碼都在http://code.taobao.org開源了。包括遠程通信框架HSF、消息中間件Notify和數據訪問中間件TDDL在內的一些框架已經開源。