本文整理自蔣江偉在ArchSummit 2016 北京站上的演講。
后臺回復關鍵詞「雙十一」，下載本文完整PPT。
從2009年到2016年，參與了8屆雙十一技術備戰(zhàn)工作。2009年的雙十一，印象并不深刻，主要原因是當時整個淘寶的體量已經(jīng)很大，每天的交易額已經(jīng)有幾億的規(guī)模，而當時的淘寶商城雙十一交易額只有5000萬左右，和幾億比體量還是非常小的，所以感覺還沒開始就過去了。
到了后面幾年，每年都要花費好幾個月的時間去精心準備，要做監(jiān)控、報警的梳理，要做容量的規(guī)劃，要做整個依賴的治理等等，也整理了各種各樣的方法論。這是一個過程，當然在這個過程里面也沉淀出了很多非常有意義的事情。今天有人問我怎么做雙十一，怎么做大促活動，我會告訴他一個非常簡單的方法，就是做好容量規(guī)劃，做好限流降級。
2008年，我加入淘寶，直接參與淘寶商城的研發(fā)工作。淘寶商城就是后來的天貓，當時整個淘寶商城的技術體系，和淘寶網(wǎng)是完全不一樣的，是完全獨立的體系。它的會員、商品、營銷、推薦、積分、論壇，都和淘寶網(wǎng)沒有任何的關系。兩套體系是完全獨立的，唯一有關系的是整個會員的數(shù)據(jù)是共享的。
2008年末啟動了「五彩石項目」，把兩套體系的數(shù)據(jù)打通、業(yè)務打通，最核心的點就是業(yè)務的發(fā)展變得非常靈活。這個項目的完成給淘寶商城的發(fā)展帶來非常大的飛躍，后來淘寶商城也升級品牌為天貓。
另外，這個項目里還有一個很大的意義，就是比較優(yōu)雅的實現(xiàn)了架構的擴展性、業(yè)務的擴展性和技術的擴展性。我們實現(xiàn)了整個服務的全部服務化，抽取了所有與電商相關的公共元素，包括會員體系、商品中心、交易中心、營銷、店鋪、推薦等。基于這個體系，構建后來像聚劃算、電器城、航旅等的業(yè)務就非?？炝?。打破原來的架構，將整個公共的服務抽取出來之后，上層的業(yè)務跑得非?？?，這就解決了業(yè)務擴展性的問題。
第一次大規(guī)模使用中間件是在這個項目里，中間件3劍客，HSF、Notify、TDDL得到了很大的創(chuàng)新沉淀，并被大規(guī)模的使用。分布式帶來的問題是一個系統(tǒng)被拆成了很多的系統(tǒng)，這其中也涉及到了擴展性的問題。這個項目也帶來了技術的進步，從業(yè)務的發(fā)展到技術的擴展性，都達成了非常好的目標。
2012年，我開始帶中間件產(chǎn)品線和高可用架構的團隊。那么為什么要做容量規(guī)劃呢？雙十一推動了阿里巴巴技術上非常大的創(chuàng)新，容量規(guī)劃也是雙十一在這個過程中非常好的創(chuàng)新。
今年做雙十一的時候，老板問我今年還有什么風險？我告訴他風險肯定很多，但是最終如果系統(tǒng)出問題了，肯定發(fā)生在交易相關的系統(tǒng)里。阿里巴巴的系統(tǒng)分兩部分：一部分系統(tǒng)是促進交易的，比如推薦、導購、搜索、頻道等都是促進交易的，會做各種各樣的營銷；另外一部分系統(tǒng)做交易、紅包、優(yōu)惠等相關系統(tǒng)。
原因非常簡單，導購類的系統(tǒng)留給你足夠的時間去做判斷，它流量的上漲不是瞬間上漲，而是一個曲線慢慢上升，它留給你30分鐘做出判斷。但是交易系統(tǒng)沒有留出任何時間判斷，一旦流量開始，沒有給人反應時間，沒有任何決策的時間，所有的行為只有系統(tǒng)會自動化執(zhí)行。這個過程里面容量規(guī)劃變的非常重要。
在早些年的時候，我們業(yè)務的自然增長本身就非?？?。印象非常深刻的是，當時大家購物的時候打開的商品詳情頁面，有一段時間這個頁面的負載比較高，公司召集了一些對于虛擬機調優(yōu)、性能優(yōu)化比較擅長的人來進行優(yōu)化，調優(yōu)了幾天之后系統(tǒng)終于掛掉了。還好也在做一些擴容的準備，擴容完成，重啟之后系統(tǒng)恢復了。這說明了什么？在早些年的時候，淘寶網(wǎng)也是一樣，對容量的準備和預估是沒有概念的，不知道多少容量能支撐整個系統(tǒng)需要的能力。
新業(yè)務不斷地上線，業(yè)務運營、促銷類的活動也非常頻繁，記得有一次做一個促銷規(guī)模非常大。會員系統(tǒng)非常重要，因為所有的業(yè)務基本上都會訪問會員中心用戶的數(shù)據(jù)，包括買家的數(shù)據(jù)還有賣家的數(shù)據(jù)。那時物理機單機緩存的能力大概在每秒處理八萬請求的規(guī)模，今天來看是遠遠不止。但當時還沒有到高峰期的時候就達到了六萬，這是非常大的一個數(shù)字。
我們就把所有訪問會員的系統(tǒng)全部拉出來，看哪些與交易無關就通知需要停掉，或者停掉一半。比如把與商家相關的，與開放相關的，與社區(qū)相關的系統(tǒng)停掉。在這個過程里面發(fā)生了各種各樣的問題，總結來說就是我們根本不知道容量怎么去做，或者說根本就沒有概念需要去做容量。所以容量規(guī)劃歸根結底就是：在什么時候什么樣的系統(tǒng)需要多少服務器？需要給出有確定性，量化的數(shù)字。
容量規(guī)劃整個過程大概經(jīng)歷了七八年的時間，總共三個階段。
第一個階段在非常早期，我們評估的方法就是「拍腦袋」（經(jīng)驗判斷）。根據(jù)負載的情況、系統(tǒng)的響應時間，各種各樣的表現(xiàn)去拍一個數(shù)字出來。當時我問一個高管，到底怎么去判斷服務器夠還是不夠，要支撐多少流量？他告訴我一個經(jīng)驗值，每臺服務器支持100萬的PV。
當時一天的流量曲線會有三個峰值，九點到十點，中午兩、三點到五點，晚上八點到十點之間都是峰值。為什么是100萬呢？這也是一個經(jīng)驗值，當然也有一點科學根據(jù)。我們希望做到一半的服務器停下來后能夠去支撐線上的流量，同時在峰值的情況下，全部能夠支撐住。實際上單機能支撐320萬的PV，這是當時的經(jīng)驗值。
當然這個經(jīng)驗值當時是起作用的，原因非常簡單，因為當時的系統(tǒng)架構簡單。可以理解為把整個淘寶所有的邏輯和模塊都集中在一個系統(tǒng)里面，所以各個模塊之間的熱點有時間差，通過一臺服務器內(nèi)部CPU的搶占或者調度在OS層面就解決了。
到了第二個階段是線上壓測階段。因為一旦到了分布式之后，就會出現(xiàn)問題。舉個例子，本來是會員的調用和交易的調用在一臺服務器上，但是分開之后，流量比例就不清楚了。所以必須要引入一些壓測機制，我們引入一些商業(yè)的壓測工具來做壓測。
當時有兩個目的：第一個是系統(tǒng)上線之前要做壓測，判斷響應時間、負載能否達到上線的要求；第二個目的是希望能夠根據(jù)線下的壓測情況，準確地評估出線上大概需要多少服務器。第二個目的做起來就比較困難一些，記得當時性能壓測團隊還做了一個項目，叫線下線上容量之間的關系。因為線上的環(huán)境和數(shù)據(jù)與線下完全不一樣，這里面沒有規(guī)律可尋，沒辦法通過線下壓測的指標反饋到線上去。
這時候怎么辦？首先是直接在線上壓測。當時來看我們做這個決定是非常瘋狂的，因為沒有一家公司，包括阿里巴巴自己也沒有人在線上直接做過壓測。我們寫了一個工具，拉取出前一天的日志直接在線上做回放。比如，根據(jù)響應時間和負載設定一個的預值，達到預值觸發(fā)的時候看它QPS的多少值。
其次我們做了一個分流。因為阿里整個架構還是比較統(tǒng)一的，全部是基于一整套的中間件，所以通過軟負載，通過調整配比，比如把線上的流量按照權重調整到一臺服務器上，通過調整到應用端和服務端不斷地調整到一臺服務器上去，增加其權重，這時候它的負載也會上升，QPS也會上升，把這個過程記錄下來。
這里已經(jīng)是兩種場景了，一種是模擬，回放日志。第二種是真實的流量，把做成自動化讓它每天自動跑產(chǎn)生數(shù)據(jù)。這個事情做完之后，它從一個維度來說，替代了線下性能壓測的過程。因為它可以讓每個系統(tǒng)每天自己獲得性能的表現(xiàn)情況。項目發(fā)布，或是日常需求的發(fā)布的性能有沒有影響的指標都可以直接看出來。后來性能測試團隊就解散了。
這里有個問題，它還沒有基于場景化。場景化非常重要，比如我買一件衣服，平時買東西的流程可能是在購物的搜索框里面搜索，或者是在類目的導航里搜索，從搜索到購物車，再到下單這樣的一個過程。雙十一推的是商品的確定性，很多頻道頁面會把賣家比較好的促銷商品直接拿出來作為一個頻道頁。雙十二的時候推的是店鋪，KPI不一樣，推的東西也不一樣。
雙十一商品相關的服務器系統(tǒng)的流量會高，它所需要的服務器也會更多一些。雙十二和店鋪相關的系統(tǒng)服務器所需要也會更多一些。這與平時的流量表現(xiàn)是不一樣的，用平時的容量去計算場景化流量，這也是不準確的。
我們也做了一件非常重要的事情：全鏈路壓測。這是我們在2013年完成的事情，之前從沒有對外講過，這是一個核武器，它有個分界線。2009年是最順利的一次雙十一，因為沒有什么流量，我們忽略不計。2010年、2011年、2012年，其實每年的雙十一總是有那么一些小問題，其實心里也沒底。
在2013年的時候，我們做了全鏈路壓測這個產(chǎn)品之后，發(fā)生了一個本質的變化。2013年的表現(xiàn)非常好，2014年也非常好，這就是一個核武器的誕生。對于做營銷和促銷類的，它是有峰值的，在這個時間點之前峰值非常低，這個時間點之后峰值突然上去了。這就是處理這種情況非常有效的一種方法。
重點分析一下線上壓測和場景化的全鏈路壓測。
線上壓測主要是由于淘寶的業(yè)務形態(tài)多樣化。分布式之后各種各樣的業(yè)務都出現(xiàn)了，它幫助解放了生產(chǎn)力。以前一百多個人在做一個系統(tǒng)，非常糟糕，但是通過分布式改造之后，整個業(yè)務服務抽象出來之后，生產(chǎn)力被解放了。
其次，每個業(yè)務的機器規(guī)模非常大，每個業(yè)務應用數(shù)量非常大。我們其實是做了一個分層，根據(jù)一個系統(tǒng)具備的容量不斷計算，最后計算出來阿里巴巴的集群容量。我們先做一個應用系統(tǒng)，通過分流，流量通過負載導入，把負載跑到最高之后計算。把這個APP整個集群，比如100臺服務器能支撐多少量計算出來。當然數(shù)據(jù)庫非常難算，數(shù)據(jù)庫都是提前規(guī)劃的，一般來說數(shù)據(jù)庫分庫分表之后，都是留了好幾年的量，比較困難一些。
通過這樣把整個集群的量和規(guī)模全部做出來是有問題的，為什么呢？因為系統(tǒng)一旦開始拆分之后一發(fā)而不可收拾，拆得越來越多。系統(tǒng)的依賴關系雖然是有工具能夠梳理出來的，但是我們沒有經(jīng)歷看到底哪些系統(tǒng)會因為這個場景下面什么原因導致整個集群出現(xiàn)了一個小問題。一旦出現(xiàn)了一個小問題，整個集群全部崩潰掉，這種問題是沒法避免的。
在2013年之前都是基于這套體系去做，想想也是挺合理的，每個系統(tǒng)算出容量，一個個集群算出來，再算出整個大集群也是可以的，但是它還不是一個非常好的解決方案。它非常好的一點是可以自動化運行，可以每天跑出系統(tǒng)的容量，并且可以保證系統(tǒng)不腐化，日常的性能、指標不腐化。
2013年的雙十一是通過這套系統(tǒng)做的。通過幾種方式，通過模擬以及流量的復制，轉發(fā)的引流，還有負載均衡的流量去實現(xiàn)。整個系統(tǒng)做成自動化，每周都會跑，根據(jù)發(fā)布前后的一天跑出來數(shù)據(jù)之后生成一個報表反饋性能有沒有下降可以得出。根據(jù)計算值準備整個活動流量大概要多少。這里有一些數(shù)據(jù)，每個月有5天自動做壓測，這種情況下靠人工做性能壓測是做不到的，因為它是自動化的。
剛才也講了一些缺陷，它是以點到面，通過一個點的容量評估，擴展到一條線，擴展到一個面。最大的問題是沒有一個人搞得清楚整個架構到底怎么樣，整個系統(tǒng)依賴關系里有遺漏之后會形成整體的崩潰。
為什么要做場景化的容量評估？
我們需要場景化壓測的另外一個原因是因為整個背景的流量大部分用的是分流，分流意味著是用真實的流量去做的，所謂真實的流量其實是很低的，和做活動相比流量非常低，沒有背景流量整個機房的網(wǎng)絡設備和交換機的流量無法跑滿，所以這些問題是沒辦法暴露出來的。第二個問題是場景化的確定性，每個人購物流程是不一樣的，在不同的流程下面整個系統(tǒng)的資源必須確定下來，要用最少的服務器支撐最大的量。
基于此，當時有一套爭論，要怎么做場景化壓測這個事情？第一種方法，把整個淘寶網(wǎng)隔離出一個小的環(huán)境里面布100多個系統(tǒng)。整個流量引進來，把集群跑滿，流量跑滿。它比較好地解決了依賴關系的問題，如果依賴出現(xiàn)問題的時候，在這個環(huán)境是能夠驗證的。但是沒辦法解決環(huán)境的問題，那一年我們公司有一個業(yè)務，就是因為沒有采用這套方案，采用了類似于小環(huán)境的流量去驗證的方案，導致入口交換機的整個流量跑滿。
所以需要有一個更簡單可靠的評估工具，這就是基于場景化的全鏈路壓測。2013年之后我們?nèi)炕谶@套體系在做，首先要造數(shù)據(jù)，流量希望能夠更接近真實的情況造出來。剛才提到臨近峰值是沒辦法做決策的，唯一能做的是什么？能夠提前模擬一次零點的峰值是什么樣子的嗎？我們希望把整個流量模擬出來，這是一個理想的架構，但是它也有很多困難的地方。
我們要盡可能把數(shù)據(jù)造得精確，各種場景都要模擬出來，比如優(yōu)惠券如何使用，購物車里商品比例是多少，一次下單有多少商品，最后多少商品提交到支付寶等等。數(shù)據(jù)量每年越來越大，比如以2015年為例，數(shù)據(jù)量接近1T，把這1T的數(shù)據(jù)傳到中心，通過中心傳到壓測節(jié)點上去，這就是壓測集群。它是一個壓測工具，但是它本身又是一個集群性的壓測工具，它可以產(chǎn)生非常巨大的流量，與雙11一模一樣規(guī)模的數(shù)據(jù)。
把集群部署到CDN節(jié)點上，產(chǎn)生巨大的流量。這里有一些技術點，壓測的工具要支持多種協(xié)議，比如HTTPS協(xié)議，需要提升性能。還要做流量的控制，根據(jù)業(yè)務場景的不同調節(jié)流量。第三點流量需要染色，右圖反映了真實的流量，這些全部是在線跑的，沒辦法在線下模擬這個環(huán)境，否則會影響線上正常的流量，所以要把正常的流量和壓測的流量完全區(qū)分開來。第四點是流量的隔離。沒有流量隔離之前，我們只能在零點以后流量很低的時候，每個人都盯著自己的系統(tǒng)有沒有出現(xiàn)什么問題，非常辛苦。第二年提了一個目標，希望能改善大家的幸福指數(shù)，所以我們推出了流量隔離。
流量隔離是把整個集群從原來在線的集群，比較快地通過負載均衡隔離出一個集群出來。當然隔離出的集群規(guī)模是非常大的，它可以占原來集群的從90%到10%。比如原來有10萬臺服務器，可以隔離到9萬臺服務器。因為準備做大促的時候，比如雙十一的流量是平時的20倍以上，所以平時流量非常低是可以隔離出來的，并且不會影響現(xiàn)有的流量。
整個過程是怎么樣的？以圖為例，ABCD這4個系統(tǒng)是日常的流量，原始的場景C所需要的服務器多，但是壓測之后發(fā)現(xiàn)B和D需要的服務器比較多。整個過程都是自動化的，如果C不需要這么多服務器，它的服務器就會被下線，這些服務器就被自動加到B和D。由于都是自動化跑，效率非常高，而且不需要到凌晨跑。最后需要把隔離出來的集群還到原來在線的集群，變成服務器的比例，就可以準備第二天的大考了。
整個容量評估的流程，從數(shù)據(jù)構造到流量環(huán)節(jié)，我們都有一個指揮部。比如我們要做一次活動，這次活動大概要5萬筆每秒的交易量，輸入5萬筆每秒這個數(shù)字之后，整套系統(tǒng)開始運作，做壓測、做彈性調度、做隔離，這就是整個自動化的過程。容量是可以預測的，但是沒辦法規(guī)劃，只能做限流。我們可以非常精確地預測出雙十一大概會來多少量，會來多少用戶，以及當時的峰值，都可以完全精確預測出來。
但預測出來也沒有太多的意義，能做的就是限流筆數(shù)，比如2016年我們做到了17.5萬筆，限流的值設定到了17.2萬，所有的系統(tǒng)先設定到這個值。這也是沒辦法的，因為真實的流量比這個大得多，要支持真實的流量成本會非常高。
日常占有的服務器是非常低的，在大促的時候我們基本上都采用阿里云的服務器，所以成本下降明顯。所以說整個容量規(guī)劃限定了一個值，比如說17萬，明年可能是20萬，或者25萬，在這個值的基礎上，通過基于場景化的全鏈路壓測工具，然后把整個系統(tǒng)的容量壓測出來，計算出來，把整個服務器資源占用拉平。這樣做的好處是用了最少的資源做了一次最成功的活動。
從2013年開始，我們通過這套技術發(fā)現(xiàn)了大量的問題，而且這些問題經(jīng)過日常的測試，功能測試，或者一些工具的測試，是沒辦法發(fā)現(xiàn)這些問題。硬件、網(wǎng)絡、操作系統(tǒng)的問題，從來沒有發(fā)現(xiàn)的問題全部暴露出來，在大負載情況下表現(xiàn)出各種詭異的問題。
任何一個問題在雙十一發(fā)生，可能都是災難性的。2013年我們做完這些事情之后，回頭看2012年、2011年，不出問題還怪，肯定會出問題。凡是峰值流量是平時峰值超過多少倍以上的活動肯定會出問題，因為很多的問題沒辦法通過一些邏輯，通過一些思考找出來的，它必須借助一個真實的環(huán)境，模擬出所有場景的流量把它營造出來。
容量規(guī)劃是一個領域、一個長時間的過程。最初利用商業(yè)軟件做性能壓測，當時覺得這個軟件應用挺好的，也能夠支撐整個容量的一些計算，甚至今天很多的公司還在用類似的軟件做性能的評估，它也是不斷引進的過程。后來發(fā)現(xiàn)，其實與真實壓測評估的容量還相差非常遠，所以我們引入了線上的壓測，引入了分流、復制流量、及日志的回放，通過一個個節(jié)點把自己的流量評估出來。
當時覺得這套系統(tǒng)很厲害，因為當時做了這套系統(tǒng)獲得了整個技術部的創(chuàng)新大獎，所以覺得有了這套系統(tǒng)以后，以后做雙十一就不用愁了，做任何活動就不用愁了，覺得這是非常了不起的系統(tǒng)。實際情況還是需要不斷地發(fā)展，做了全鏈路壓測，整個鏈路基于場景化的真實場景模擬，把整個集群壓測出來。
回過頭來看，在一個領域里面，當自己滿足于當前現(xiàn)狀的時候，比如說CSP“日常的壓測平臺”能夠完全滿足于當前現(xiàn)狀，而且已經(jīng)領先于國內(nèi)很多產(chǎn)品的時候，其實你還是可以繼續(xù)往前走一步。
我們只是做了雙十一創(chuàng)新里容量規(guī)劃這個點。阿里巴巴整個技術架構非常統(tǒng)一，因為做了全鏈路壓測之后，很多的業(yè)務單元，像支付寶等等都可以采用這種方式做，它可以非常簡單地復制出去，這也給我們帶來了非常低的成本。從研發(fā)開始到學習，以及運維的過程，運維的產(chǎn)品線，帶給了我們非常低的成本。所以我們整個團隊人非常少，做全線路壓測就4、5個人，但是它服務了整個集團100多個業(yè)務方，這也是因為整個架構的統(tǒng)一性。
今年雙十一做完了之后，我們的CTO也給我們提出了新的挑戰(zhàn)：雙十一的整個過程可以投入更少的成本，全鏈路壓測是對日常系統(tǒng)的一種驗證，而不是找問題本身，同時希望我們的系統(tǒng)更加的自動化和智能化。我們正在思考如何實現(xiàn)。
蔣江偉，花名小邪，阿里巴巴研究員，08年加入淘寶網(wǎng)，參與業(yè)務系統(tǒng)研發(fā)工作。 12年開始負責阿里巴巴中間件技術產(chǎn)品和高可用架構，中間件產(chǎn)品是阿里巴巴電商等業(yè)務分布式架構的基礎技術組件，使得各種業(yè)務系統(tǒng)能快速構建一套高可用的分布式架構集群。
點擊下方圖片即可閱讀
回顧容器的2016：「已死」or「永生」？
