本文整理自蔣江偉在ArchSummit 2016 北京站上的演講。

后臺回復(fù)關(guān)鍵詞「雙十一」，下載本文完整PPT。

從2009年到2016年，參與了8屆雙十一技術(shù)備戰(zhàn)工作。2009年的雙十一，印象并不深刻，主要原因是當(dāng)時整個淘寶的體量已經(jīng)很大，每天的交易額已經(jīng)有幾億的規(guī)模，而當(dāng)時的淘寶商城雙十一交易額只有5000萬左右，和幾億比體量還是非常小的，所以感覺還沒開始就過去了。

到了后面幾年，每年都要花費(fèi)好幾個月的時間去精心準(zhǔn)備，要做監(jiān)控、報警的梳理，要做容量的規(guī)劃，要做整個依賴的治理等等，也整理了各種各樣的方法論。這是一個過程，當(dāng)然在這個過程里面也沉淀出了很多非常有意義的事情。今天有人問我怎么做雙十一，怎么做大促活動，我會告訴他一個非常簡單的方法，就是做好容量規(guī)劃，做好限流降級。

2008年，我加入淘寶，直接參與淘寶商城的研發(fā)工作。淘寶商城就是后來的天貓，當(dāng)時整個淘寶商城的技術(shù)體系，和淘寶網(wǎng)是完全不一樣的，是完全獨(dú)立的體系。它的會員、商品、營銷、推薦、積分、論壇，都和淘寶網(wǎng)沒有任何的關(guān)系。兩套體系是完全獨(dú)立的，唯一有關(guān)系的是整個會員的數(shù)據(jù)是共享的。

2008年末啟動了「五彩石項(xiàng)目」，把兩套體系的數(shù)據(jù)打通、業(yè)務(wù)打通，最核心的點(diǎn)就是業(yè)務(wù)的發(fā)展變得非常靈活。這個項(xiàng)目的完成給淘寶商城的發(fā)展帶來非常大的飛躍，后來淘寶商城也升級品牌為天貓。

另外，這個項(xiàng)目里還有一個很大的意義，就是比較優(yōu)雅的實(shí)現(xiàn)了架構(gòu)的擴(kuò)展性、業(yè)務(wù)的擴(kuò)展性和技術(shù)的擴(kuò)展性。我們實(shí)現(xiàn)了整個服務(wù)的全部服務(wù)化，抽取了所有與電商相關(guān)的公共元素，包括會員體系、商品中心、交易中心、營銷、店鋪、推薦等?；谶@個體系，構(gòu)建后來像聚劃算、電器城、航旅等的業(yè)務(wù)就非?？炝恕４蚱圃瓉淼募軜?gòu)，將整個公共的服務(wù)抽取出來之后，上層的業(yè)務(wù)跑得非?？欤@就解決了業(yè)務(wù)擴(kuò)展性的問題。

第一次大規(guī)模使用中間件是在這個項(xiàng)目里，中間件3劍客，HSF、Notify、TDDL得到了很大的創(chuàng)新沉淀，并被大規(guī)模的使用。分布式帶來的問題是一個系統(tǒng)被拆成了很多的系統(tǒng)，這其中也涉及到了擴(kuò)展性的問題。這個項(xiàng)目也帶來了技術(shù)的進(jìn)步，從業(yè)務(wù)的發(fā)展到技術(shù)的擴(kuò)展性，都達(dá)成了非常好的目標(biāo)。

2012年，我開始帶中間件產(chǎn)品線和高可用架構(gòu)的團(tuán)隊(duì)。那么為什么要做容量規(guī)劃呢？雙十一推動了阿里巴巴技術(shù)上非常大的創(chuàng)新，容量規(guī)劃也是雙十一在這個過程中非常好的創(chuàng)新。

今年做雙十一的時候，老板問我今年還有什么風(fēng)險？我告訴他風(fēng)險肯定很多，但是最終如果系統(tǒng)出問題了，肯定發(fā)生在交易相關(guān)的系統(tǒng)里。阿里巴巴的系統(tǒng)分兩部分：一部分系統(tǒng)是促進(jìn)交易的，比如推薦、導(dǎo)購、搜索、頻道等都是促進(jìn)交易的，會做各種各樣的營銷；另外一部分系統(tǒng)做交易、紅包、優(yōu)惠等相關(guān)系統(tǒng)。

原因非常簡單，導(dǎo)購類的系統(tǒng)留給你足夠的時間去做判斷，它流量的上漲不是瞬間上漲，而是一個曲線慢慢上升，它留給你30分鐘做出判斷。但是交易系統(tǒng)沒有留出任何時間判斷，一旦流量開始，沒有給人反應(yīng)時間，沒有任何決策的時間，所有的行為只有系統(tǒng)會自動化執(zhí)行。這個過程里面容量規(guī)劃變的非常重要。

在早些年的時候，我們業(yè)務(wù)的自然增長本身就非?？臁Ｓ∠蠓浅Ｉ羁痰氖牵?dāng)時大家購物的時候打開的商品詳情頁面，有一段時間這個頁面的負(fù)載比較高，公司召集了一些對于虛擬機(jī)調(diào)優(yōu)、性能優(yōu)化比較擅長的人來進(jìn)行優(yōu)化，調(diào)優(yōu)了幾天之后系統(tǒng)終于掛掉了。還好也在做一些擴(kuò)容的準(zhǔn)備，擴(kuò)容完成，重啟之后系統(tǒng)恢復(fù)了。這說明了什么？在早些年的時候，淘寶網(wǎng)也是一樣，對容量的準(zhǔn)備和預(yù)估是沒有概念的，不知道多少容量能支撐整個系統(tǒng)需要的能力。

新業(yè)務(wù)不斷地上線，業(yè)務(wù)運(yùn)營、促銷類的活動也非常頻繁，記得有一次做一個促銷規(guī)模非常大。會員系統(tǒng)非常重要，因?yàn)樗械臉I(yè)務(wù)基本上都會訪問會員中心用戶的數(shù)據(jù)，包括買家的數(shù)據(jù)還有賣家的數(shù)據(jù)。那時物理機(jī)單機(jī)緩存的能力大概在每秒處理八萬請求的規(guī)模，今天來看是遠(yuǎn)遠(yuǎn)不止。但當(dāng)時還沒有到高峰期的時候就達(dá)到了六萬，這是非常大的一個數(shù)字。

我們就把所有訪問會員的系統(tǒng)全部拉出來，看哪些與交易無關(guān)就通知需要停掉，或者停掉一半。比如把與商家相關(guān)的，與開放相關(guān)的，與社區(qū)相關(guān)的系統(tǒng)停掉。在這個過程里面發(fā)生了各種各樣的問題，總結(jié)來說就是我們根本不知道容量怎么去做，或者說根本就沒有概念需要去做容量。所以容量規(guī)劃歸根結(jié)底就是：在什么時候什么樣的系統(tǒng)需要多少服務(wù)器？需要給出有確定性，量化的數(shù)字。

容量規(guī)劃整個過程大概經(jīng)歷了七八年的時間，總共三個階段。

第一個階段在非常早期，我們評估的方法就是「拍腦袋」（經(jīng)驗(yàn)判斷）。根據(jù)負(fù)載的情況、系統(tǒng)的響應(yīng)時間，各種各樣的表現(xiàn)去拍一個數(shù)字出來。當(dāng)時我問一個高管，到底怎么去判斷服務(wù)器夠還是不夠，要支撐多少流量？他告訴我一個經(jīng)驗(yàn)值，每臺服務(wù)器支持100萬的PV。

當(dāng)時一天的流量曲線會有三個峰值，九點(diǎn)到十點(diǎn)，中午兩、三點(diǎn)到五點(diǎn)，晚上八點(diǎn)到十點(diǎn)之間都是峰值。為什么是100萬呢？這也是一個經(jīng)驗(yàn)值，當(dāng)然也有一點(diǎn)科學(xué)根據(jù)。我們希望做到一半的服務(wù)器停下來后能夠去支撐線上的流量，同時在峰值的情況下，全部能夠支撐住。實(shí)際上單機(jī)能支撐320萬的PV，這是當(dāng)時的經(jīng)驗(yàn)值。

當(dāng)然這個經(jīng)驗(yàn)值當(dāng)時是起作用的，原因非常簡單，因?yàn)楫?dāng)時的系統(tǒng)架構(gòu)簡單?？梢岳斫鉃榘颜麄€淘寶所有的邏輯和模塊都集中在一個系統(tǒng)里面，所以各個模塊之間的熱點(diǎn)有時間差，通過一臺服務(wù)器內(nèi)部CPU的搶占或者調(diào)度在OS層面就解決了。

到了第二個階段是線上壓測階段。因?yàn)橐坏┑搅朔植际街?，就會出現(xiàn)問題。舉個例子，本來是會員的調(diào)用和交易的調(diào)用在一臺服務(wù)器上，但是分開之后，流量比例就不清楚了。所以必須要引入一些壓測機(jī)制，我們引入一些商業(yè)的壓測工具來做壓測。

當(dāng)時有兩個目的：第一個是系統(tǒng)上線之前要做壓測，判斷響應(yīng)時間、負(fù)載能否達(dá)到上線的要求；第二個目的是希望能夠根據(jù)線下的壓測情況，準(zhǔn)確地評估出線上大概需要多少服務(wù)器。第二個目的做起來就比較困難一些，記得當(dāng)時性能壓測團(tuán)隊(duì)還做了一個項(xiàng)目，叫線下線上容量之間的關(guān)系。因?yàn)榫€上的環(huán)境和數(shù)據(jù)與線下完全不一樣，這里面沒有規(guī)律可尋，沒辦法通過線下壓測的指標(biāo)反饋到線上去。

這時候怎么辦？首先是直接在線上壓測。當(dāng)時來看我們做這個決定是非常瘋狂的，因?yàn)闆]有一家公司，包括阿里巴巴自己也沒有人在線上直接做過壓測。我們寫了一個工具，拉取出前一天的日志直接在線上做回放。比如，根據(jù)響應(yīng)時間和負(fù)載設(shè)定一個的預(yù)值，達(dá)到預(yù)值觸發(fā)的時候看它QPS的多少值。

其次我們做了一個分流。因?yàn)榘⒗镎麄€架構(gòu)還是比較統(tǒng)一的，全部是基于一整套的中間件，所以通過軟負(fù)載，通過調(diào)整配比，比如把線上的流量按照權(quán)重調(diào)整到一臺服務(wù)器上，通過調(diào)整到應(yīng)用端和服務(wù)端不斷地調(diào)整到一臺服務(wù)器上去，增加其權(quán)重，這時候它的負(fù)載也會上升，QPS也會上升，把這個過程記錄下來。

這里已經(jīng)是兩種場景了，一種是模擬，回放日志。第二種是真實(shí)的流量，把做成自動化讓它每天自動跑產(chǎn)生數(shù)據(jù)。這個事情做完之后，它從一個維度來說，替代了線下性能壓測的過程。因?yàn)樗梢宰屆總€系統(tǒng)每天自己獲得性能的表現(xiàn)情況。項(xiàng)目發(fā)布，或是日常需求的發(fā)布的性能有沒有影響的指標(biāo)都可以直接看出來。后來性能測試團(tuán)隊(duì)就解散了。

這里有個問題，它還沒有基于場景化。場景化非常重要，比如我買一件衣服，平時買東西的流程可能是在購物的搜索框里面搜索，或者是在類目的導(dǎo)航里搜索，從搜索到購物車，再到下單這樣的一個過程。雙十一推的是商品的確定性，很多頻道頁面會把賣家比較好的促銷商品直接拿出來作為一個頻道頁。雙十二的時候推的是店鋪，KPI不一樣，推的東西也不一樣。

雙十一商品相關(guān)的服務(wù)器系統(tǒng)的流量會高，它所需要的服務(wù)器也會更多一些。雙十二和店鋪相關(guān)的系統(tǒng)服務(wù)器所需要也會更多一些。這與平時的流量表現(xiàn)是不一樣的，用平時的容量去計算場景化流量，這也是不準(zhǔn)確的。

我們也做了一件非常重要的事情：全鏈路壓測。這是我們在2013年完成的事情，之前從沒有對外講過，這是一個核武器，它有個分界線。2009年是最順利的一次雙十一，因?yàn)闆]有什么流量，我們忽略不計。2010年、2011年、2012年，其實(shí)每年的雙十一總是有那么一些小問題，其實(shí)心里也沒底。

在2013年的時候，我們做了全鏈路壓測這個產(chǎn)品之后，發(fā)生了一個本質(zhì)的變化。2013年的表現(xiàn)非常好，2014年也非常好，這就是一個核武器的誕生。對于做營銷和促銷類的，它是有峰值的，在這個時間點(diǎn)之前峰值非常低，這個時間點(diǎn)之后峰值突然上去了。這就是處理這種情況非常有效的一種方法。

重點(diǎn)分析一下線上壓測和場景化的全鏈路壓測。

線上壓測主要是由于淘寶的業(yè)務(wù)形態(tài)多樣化。分布式之后各種各樣的業(yè)務(wù)都出現(xiàn)了，它幫助解放了生產(chǎn)力。以前一百多個人在做一個系統(tǒng)，非常糟糕，但是通過分布式改造之后，整個業(yè)務(wù)服務(wù)抽象出來之后，生產(chǎn)力被解放了。

其次，每個業(yè)務(wù)的機(jī)器規(guī)模非常大，每個業(yè)務(wù)應(yīng)用數(shù)量非常大。我們其實(shí)是做了一個分層，根據(jù)一個系統(tǒng)具備的容量不斷計算，最后計算出來阿里巴巴的集群容量。我們先做一個應(yīng)用系統(tǒng)，通過分流，流量通過負(fù)載導(dǎo)入，把負(fù)載跑到最高之后計算。把這個APP整個集群，比如100臺服務(wù)器能支撐多少量計算出來。當(dāng)然數(shù)據(jù)庫非常難算，數(shù)據(jù)庫都是提前規(guī)劃的，一般來說數(shù)據(jù)庫分庫分表之后，都是留了好幾年的量，比較困難一些。

通過這樣把整個集群的量和規(guī)模全部做出來是有問題的，為什么呢？因?yàn)橄到y(tǒng)一旦開始拆分之后一發(fā)而不可收拾，拆得越來越多。系統(tǒng)的依賴關(guān)系雖然是有工具能夠梳理出來的，但是我們沒有經(jīng)歷看到底哪些系統(tǒng)會因?yàn)檫@個場景下面什么原因?qū)е抡麄€集群出現(xiàn)了一個小問題。一旦出現(xiàn)了一個小問題，整個集群全部崩潰掉，這種問題是沒法避免的。

在2013年之前都是基于這套體系去做，想想也是挺合理的，每個系統(tǒng)算出容量，一個個集群算出來，再算出整個大集群也是可以的，但是它還不是一個非常好的解決方案。它非常好的一點(diǎn)是可以自動化運(yùn)行，可以每天跑出系統(tǒng)的容量，并且可以保證系統(tǒng)不腐化，日常的性能、指標(biāo)不腐化。

2013年的雙十一是通過這套系統(tǒng)做的。通過幾種方式，通過模擬以及流量的復(fù)制，轉(zhuǎn)發(fā)的引流，還有負(fù)載均衡的流量去實(shí)現(xiàn)。整個系統(tǒng)做成自動化，每周都會跑，根據(jù)發(fā)布前后的一天跑出來數(shù)據(jù)之后生成一個報表反饋性能有沒有下降可以得出。根據(jù)計算值準(zhǔn)備整個活動流量大概要多少。這里有一些數(shù)據(jù)，每個月有5天自動做壓測，這種情況下靠人工做性能壓測是做不到的，因?yàn)樗亲詣踊摹?/p>

剛才也講了一些缺陷，它是以點(diǎn)到面，通過一個點(diǎn)的容量評估，擴(kuò)展到一條線，擴(kuò)展到一個面。最大的問題是沒有一個人搞得清楚整個架構(gòu)到底怎么樣，整個系統(tǒng)依賴關(guān)系里有遺漏之后會形成整體的崩潰。

為什么要做場景化的容量評估？

我們需要場景化壓測的另外一個原因是因?yàn)檎麄€背景的流量大部分用的是分流，分流意味著是用真實(shí)的流量去做的，所謂真實(shí)的流量其實(shí)是很低的，和做活動相比流量非常低，沒有背景流量整個機(jī)房的網(wǎng)絡(luò)設(shè)備和交換機(jī)的流量無法跑滿，所以這些問題是沒辦法暴露出來的。第二個問題是場景化的確定性，每個人購物流程是不一樣的，在不同的流程下面整個系統(tǒng)的資源必須確定下來，要用最少的服務(wù)器支撐最大的量。

基于此，當(dāng)時有一套爭論，要怎么做場景化壓測這個事情？第一種方法，把整個淘寶網(wǎng)隔離出一個小的環(huán)境里面布100多個系統(tǒng)。整個流量引進(jìn)來，把集群跑滿，流量跑滿。它比較好地解決了依賴關(guān)系的問題，如果依賴出現(xiàn)問題的時候，在這個環(huán)境是能夠驗(yàn)證的。但是沒辦法解決環(huán)境的問題，那一年我們公司有一個業(yè)務(wù)，就是因?yàn)闆]有采用這套方案，采用了類似于小環(huán)境的流量去驗(yàn)證的方案，導(dǎo)致入口交換機(jī)的整個流量跑滿。

所以需要有一個更簡單可靠的評估工具，這就是基于場景化的全鏈路壓測。2013年之后我們?nèi)炕谶@套體系在做，首先要造數(shù)據(jù)，流量希望能夠更接近真實(shí)的情況造出來。剛才提到臨近峰值是沒辦法做決策的，唯一能做的是什么？能夠提前模擬一次零點(diǎn)的峰值是什么樣子的嗎？我們希望把整個流量模擬出來，這是一個理想的架構(gòu)，但是它也有很多困難的地方。

我們要盡可能把數(shù)據(jù)造得精確，各種場景都要模擬出來，比如優(yōu)惠券如何使用，購物車?yán)锷唐繁壤嵌嗌?，一次下單有多少商品，最后多少商品提交到支付寶等等。?shù)據(jù)量每年越來越大，比如以2015年為例，數(shù)據(jù)量接近1T，把這1T的數(shù)據(jù)傳到中心，通過中心傳到壓測節(jié)點(diǎn)上去，這就是壓測集群。它是一個壓測工具，但是它本身又是一個集群性的壓測工具，它可以產(chǎn)生非常巨大的流量，與雙11一模一樣規(guī)模的數(shù)據(jù)。

把集群部署到CDN節(jié)點(diǎn)上，產(chǎn)生巨大的流量。這里有一些技術(shù)點(diǎn)，壓測的工具要支持多種協(xié)議，比如HTTPS協(xié)議，需要提升性能。還要做流量的控制，根據(jù)業(yè)務(wù)場景的不同調(diào)節(jié)流量。第三點(diǎn)流量需要染色，右圖反映了真實(shí)的流量，這些全部是在線跑的，沒辦法在線下模擬這個環(huán)境，否則會影響線上正常的流量，所以要把正常的流量和壓測的流量完全區(qū)分開來。第四點(diǎn)是流量的隔離。沒有流量隔離之前，我們只能在零點(diǎn)以后流量很低的時候，每個人都盯著自己的系統(tǒng)有沒有出現(xiàn)什么問題，非常辛苦。第二年提了一個目標(biāo)，希望能改善大家的幸福指數(shù)，所以我們推出了流量隔離。

流量隔離是把整個集群從原來在線的集群，比較快地通過負(fù)載均衡隔離出一個集群出來。當(dāng)然隔離出的集群規(guī)模是非常大的，它可以占原來集群的從90%到10%。比如原來有10萬臺服務(wù)器，可以隔離到9萬臺服務(wù)器。因?yàn)闇?zhǔn)備做大促的時候，比如雙十一的流量是平時的20倍以上，所以平時流量非常低是可以隔離出來的，并且不會影響現(xiàn)有的流量。

整個過程是怎么樣的？以圖為例，ABCD這4個系統(tǒng)是日常的流量，原始的場景C所需要的服務(wù)器多，但是壓測之后發(fā)現(xiàn)B和D需要的服務(wù)器比較多。整個過程都是自動化的，如果C不需要這么多服務(wù)器，它的服務(wù)器就會被下線，這些服務(wù)器就被自動加到B和D。由于都是自動化跑，效率非常高，而且不需要到凌晨跑。最后需要把隔離出來的集群還到原來在線的集群，變成服務(wù)器的比例，就可以準(zhǔn)備第二天的大考了。

整個容量評估的流程，從數(shù)據(jù)構(gòu)造到流量環(huán)節(jié)，我們都有一個指揮部。比如我們要做一次活動，這次活動大概要5萬筆每秒的交易量，輸入5萬筆每秒這個數(shù)字之后，整套系統(tǒng)開始運(yùn)作，做壓測、做彈性調(diào)度、做隔離，這就是整個自動化的過程。容量是可以預(yù)測的，但是沒辦法規(guī)劃，只能做限流。我們可以非常精確地預(yù)測出雙十一大概會來多少量，會來多少用戶，以及當(dāng)時的峰值，都可以完全精確預(yù)測出來。

但預(yù)測出來也沒有太多的意義，能做的就是限流筆數(shù)，比如2016年我們做到了17.5萬筆，限流的值設(shè)定到了17.2萬，所有的系統(tǒng)先設(shè)定到這個值。這也是沒辦法的，因?yàn)檎鎸?shí)的流量比這個大得多，要支持真實(shí)的流量成本會非常高。

日常占有的服務(wù)器是非常低的，在大促的時候我們基本上都采用阿里云的服務(wù)器，所以成本下降明顯。所以說整個容量規(guī)劃限定了一個值，比如說17萬，明年可能是20萬，或者25萬，在這個值的基礎(chǔ)上，通過基于場景化的全鏈路壓測工具，然后把整個系統(tǒng)的容量壓測出來，計算出來，把整個服務(wù)器資源占用拉平。這樣做的好處是用了最少的資源做了一次最成功的活動。

從2013年開始，我們通過這套技術(shù)發(fā)現(xiàn)了大量的問題，而且這些問題經(jīng)過日常的測試，功能測試，或者一些工具的測試，是沒辦法發(fā)現(xiàn)這些問題。硬件、網(wǎng)絡(luò)、操作系統(tǒng)的問題，從來沒有發(fā)現(xiàn)的問題全部暴露出來，在大負(fù)載情況下表現(xiàn)出各種詭異的問題。

任何一個問題在雙十一發(fā)生，可能都是災(zāi)難性的。2013年我們做完這些事情之后，回頭看2012年、2011年，不出問題還怪，肯定會出問題。凡是峰值流量是平時峰值超過多少倍以上的活動肯定會出問題，因?yàn)楹芏嗟膯栴}沒辦法通過一些邏輯，通過一些思考找出來的，它必須借助一個真實(shí)的環(huán)境，模擬出所有場景的流量把它營造出來。

容量規(guī)劃是一個領(lǐng)域、一個長時間的過程。最初利用商業(yè)軟件做性能壓測，當(dāng)時覺得這個軟件應(yīng)用挺好的，也能夠支撐整個容量的一些計算，甚至今天很多的公司還在用類似的軟件做性能的評估，它也是不斷引進(jìn)的過程。后來發(fā)現(xiàn)，其實(shí)與真實(shí)壓測評估的容量還相差非常遠(yuǎn)，所以我們引入了線上的壓測，引入了分流、復(fù)制流量、及日志的回放，通過一個個節(jié)點(diǎn)把自己的流量評估出來。

當(dāng)時覺得這套系統(tǒng)很厲害，因?yàn)楫?dāng)時做了這套系統(tǒng)獲得了整個技術(shù)部的創(chuàng)新大獎，所以覺得有了這套系統(tǒng)以后，以后做雙十一就不用愁了，做任何活動就不用愁了，覺得這是非常了不起的系統(tǒng)。實(shí)際情況還是需要不斷地發(fā)展，做了全鏈路壓測，整個鏈路基于場景化的真實(shí)場景模擬，把整個集群壓測出來。

回過頭來看，在一個領(lǐng)域里面，當(dāng)自己滿足于當(dāng)前現(xiàn)狀的時候，比如說CSP“日常的壓測平臺”能夠完全滿足于當(dāng)前現(xiàn)狀，而且已經(jīng)領(lǐng)先于國內(nèi)很多產(chǎn)品的時候，其實(shí)你還是可以繼續(xù)往前走一步。

我們只是做了雙十一創(chuàng)新里容量規(guī)劃這個點(diǎn)。阿里巴巴整個技術(shù)架構(gòu)非常統(tǒng)一，因?yàn)樽隽巳溌穳簻y之后，很多的業(yè)務(wù)單元，像支付寶等等都可以采用這種方式做，它可以非常簡單地復(fù)制出去，這也給我們帶來了非常低的成本。從研發(fā)開始到學(xué)習(xí)，以及運(yùn)維的過程，運(yùn)維的產(chǎn)品線，帶給了我們非常低的成本。所以我們整個團(tuán)隊(duì)人非常少，做全線路壓測就4、5個人，但是它服務(wù)了整個集團(tuán)100多個業(yè)務(wù)方，這也是因?yàn)檎麄€架構(gòu)的統(tǒng)一性。

今年雙十一做完了之后，我們的CTO也給我們提出了新的挑戰(zhàn)：雙十一的整個過程可以投入更少的成本，全鏈路壓測是對日常系統(tǒng)的一種驗(yàn)證，而不是找問題本身，同時希望我們的系統(tǒng)更加的自動化和智能化。我們正在思考如何實(shí)現(xiàn)。

作者介紹

蔣江偉，花名小邪，阿里巴巴研究員，08年加入淘寶網(wǎng)，參與業(yè)務(wù)系統(tǒng)研發(fā)工作。 12年開始負(fù)責(zé)阿里巴巴中間件技術(shù)產(chǎn)品和高可用架構(gòu)，中間件產(chǎn)品是阿里巴巴電商等業(yè)務(wù)分布式架構(gòu)的基礎(chǔ)技術(shù)組件，使得各種業(yè)務(wù)系統(tǒng)能快速構(gòu)建一套高可用的分布式架構(gòu)集群。

今日薦文

點(diǎn)擊下方圖片即可閱讀

回顧容器的2016：「已死」or「永生」？

---