作者：子柳，唐三（云棲社區(qū)）
阿里已經(jīng)不單單有電商業(yè)務(wù)，今天我們涉獵的非常廣泛，布局也非常多。阿里從一家電商公司開始，如果業(yè)務(wù)已經(jīng)覆蓋到了各個行業(yè)，圖為4年前，2015年的布局。
按照這樣的業(yè)務(wù)發(fā)展速度，如果沒有一套完整的技術(shù)體系支撐，勢必會影響整個業(yè)務(wù)的發(fā)展。
可以看到我們的技術(shù)是分層的,在最上的是業(yè)務(wù)，中間部分是中間件、搜索和大數(shù)據(jù)等中臺系統(tǒng)。整個的大中臺體系就是中中間這層通用的技術(shù)能夠快速支持上層業(yè)務(wù)的快速發(fā)展。只要是用發(fā)中臺的技術(shù)體系，都能夠在上面快速的搭建自己的業(yè)務(wù)。
整個中臺包括部分如圖，除了中間件、搜索，還有一些數(shù)據(jù)分析。中間件在業(yè)務(wù)研發(fā)的過程中起到非常重要的作用。這是在我們整個技術(shù)架構(gòu)演變過程中，逐漸形成的一套體系。
淘寶從初創(chuàng)開始到今天，我們的技術(shù)架構(gòu)總體上經(jīng)歷了四代：
第一代是基于LAMP的一套結(jié)構(gòu)。
第二代是基于Java的應(yīng)用架構(gòu)。
第三代是基于分布式體系，構(gòu)建出一整套的分布式架構(gòu)。
第四代是基于IDC，不但應(yīng)用能夠分布，整數(shù)數(shù)據(jù)中心也能夠分布。
那么接下來，我就從0開始，跟大家分享這一段歷程。
LAMP結(jié)構(gòu)
整個淘寶網(wǎng)從開始想去創(chuàng)建，到真正上線，總共經(jīng)歷了一個多月的時間。那這一個多月的時間都做了些什么呢？
第一件事情，我們開始做技術(shù)選型，決定我們后續(xù)怎么發(fā)展；第二件事情，如何在一個多月的時間，讓我們的網(wǎng)站上線我們購買了一套基于LAMP架構(gòu)的電商網(wǎng)站，并且拿到源代碼，我們對其進行二次開發(fā)，比如界面的UI改動，上下title的改動，其中最大的改動就是我們對它的數(shù)據(jù)庫做了讀寫分離。
Java架構(gòu)
隨著業(yè)務(wù)量的增長，就會發(fā)現(xiàn)一些瓶頸，主要來自于數(shù)據(jù)庫。當(dāng)時的數(shù)據(jù)庫是MySQL4，還不夠穩(wěn)定，數(shù)據(jù)庫經(jīng)常會出現(xiàn)死機。因此，我們直接把數(shù)據(jù)庫換成oracle，通過PHP和oracle直接去連接進行操作，但PHP不支持連接池，即使使用一些開源的PHP中間件，讓PHP去連接oracle，還是非常不穩(wěn)定，連接池的中間件經(jīng)?？ㄋ?。
然后我們開始考慮將技術(shù)體系轉(zhuǎn)成Java，因為Java在企業(yè)級的應(yīng)用中，有著比較成熟的生態(tài)。轉(zhuǎn)化的過程中也還是很坎坷的：第一，我們是一個線上正在運行的系統(tǒng)；第二，系統(tǒng)當(dāng)時正在大規(guī)模的增長。所以說把系統(tǒng)替換成Java，最好的方法就是分塊替換。同時發(fā)現(xiàn)，oracle的寫入量還是比較大的，當(dāng)時還做了一個search，把產(chǎn)品搜索和店鋪搜索放到search里面，這樣每一次的請求都打到數(shù)據(jù)庫里面了，這樣我們就完成了1.0架構(gòu)到2.0架構(gòu)的演進。
分布式架構(gòu)
隨著整個業(yè)務(wù)的發(fā)展，我們又迎來了新問題，洪峰流量給我們帶來了巨大的挑戰(zhàn)，電商行業(yè)在國內(nèi)已經(jīng)逐步開始盛行，我們的流量直線上漲，電商的人口紅利也開始上漲。隨著流量的上漲，我們面臨著服務(wù)器和數(shù)據(jù)庫的壓力。
從技術(shù)角度來看，我們面臨著兩個問題：
首先是淘寶上描述商品的圖片特別多，圖片問題非常嚴重，主要取決于我們采用的是商用存儲，成本非常高，最高級別版本也很難存儲下我們所有的圖片；
其次在淘寶上瀏覽的所有交易都有交易快照，這也是非常耗費存儲成本的；
第三，雖然數(shù)據(jù)庫替換成了oracle，隨著數(shù)據(jù)量的增大，我們所有的請求都打到數(shù)據(jù)庫上面，這時數(shù)據(jù)庫的存儲也快達到了極限，壓力也非常大。
所以我們開始對架構(gòu)升級。第一，我們增加了內(nèi)存cache，cache主要是解決數(shù)據(jù)庫壓力過大的問題，我們自己研制了一套Key/Value 分布式緩存（TAIR），就是在數(shù)據(jù)庫前端加了一個內(nèi)存cache，緩解了我們數(shù)據(jù)庫的壓力。第二，我們增加了分布式文件系統(tǒng)（TFS），之前的文件系統(tǒng)在商用的時候，成本太高，服務(wù)器的量非常大，所以我們研發(fā)了自己的一套文件系統(tǒng)。
隨著我們的業(yè)務(wù)量逐漸增大，人也越來越多，這就導(dǎo)致開發(fā)維護成本特別高，當(dāng)時我們是all-in-one系統(tǒng)，所有人改所有的代碼都是在這一個系統(tǒng)里面，就會出現(xiàn)以下問題：
技術(shù)團隊規(guī)模500人左右，維護變得越來越復(fù)雜
單一War應(yīng)用，應(yīng)用包一直增長，更新業(yè)務(wù)特性越來越慢；數(shù)據(jù)逐步形成多個孤島，無法拉通
基于傳統(tǒng)應(yīng)用開發(fā)架構(gòu)，業(yè)務(wù)爆發(fā)，彈性不足，單點故障影響巨大
還有性能問題。隨著前端業(yè)務(wù)量的增大，服務(wù)器逐漸增多的時候，oracle也出現(xiàn)了連接數(shù)的瓶頸。所以我們必須開始做新的架構(gòu)，讓整個架構(gòu)往前走一步。
于是，我們邁向了3.0架構(gòu)。系統(tǒng)進行拆分變小，拆分系統(tǒng)主要是把系統(tǒng)分層。把系統(tǒng)分成三類：
第一類是c類，是中心類，比如說會員、商品、店鋪等等，基于這些中心上面開發(fā)各自的系統(tǒng)。比如說商品詳情、交易下單；
還有一些公共的類，是p類，比如交易平臺，這是從業(yè)務(wù)上進行拆分。幾個比較知名的項目，比如千島湖項目（拆分出交易中心、類目屬性中心）、五彩石項目（拆分出店鋪中心、商品中心、評價中心）。
伴隨著技術(shù)架構(gòu)的改動，我們的業(yè)務(wù)結(jié)構(gòu)也開始進行改動，開始成立了相應(yīng)的團隊。上圖的下半部分就介紹了我們架構(gòu)的演變過程。開始時，是all in one，1~10在維護一個項目。第二個階段是10~1000人維護的MVC架構(gòu)，實現(xiàn)了前后端分離，各司其職。第三個階段是RPC，就是把各個系統(tǒng)進行拆分，然后各個系統(tǒng)之間進行通信。第四個階段就是SOA這樣一個模式。
重點分享RPC的發(fā)展歷程。我們把應(yīng)用拆成才c類、p類、垂直團隊類。這些應(yīng)用本來就是在一個大應(yīng)用里面，他們之間可以很自然地進行通信，可以直接進行相互調(diào)用。但是拆分之后，我們的應(yīng)用如何進行相互調(diào)用？
我們開發(fā)了輕量級的HSF框架，它是基于Java interface 的RPC框架，使得開發(fā)系統(tǒng)時就像開發(fā)本地應(yīng)用一樣去正常的調(diào)用Java。使用這個框架可以真正遠程的調(diào)用到其他的系統(tǒng)上面。
隨著應(yīng)用逐漸發(fā)展，我們會依賴中間件或者各個產(chǎn)品之間相互依賴。為了解決Jar包沖突的問題，我們研究出了Pandora容器。這個容器能把所有的加包做隔離，當(dāng)發(fā)生Jar包沖突的時候，它知道優(yōu)先加載哪個，這樣，我們就把Jar包沖突的問題解決了，那服務(wù)發(fā)現(xiàn)怎么辦呢？比如：一個應(yīng)用A如何知道應(yīng)用B里面有多少臺機器呢，你的ip又是什么？最簡單的方式就是靜態(tài)列表，記錄下ip，做輪詢策略，先調(diào)用A的1號機，再調(diào)用2號機。這樣就沒法實現(xiàn)一個動態(tài)的發(fā)現(xiàn)。所以在這個過程中，我們有一個動態(tài)的配置中心（configserver），在你服務(wù)上線的時候，作為provider把服務(wù)放到configserver上去，當(dāng)需要消費這個服務(wù)的時候，會看哪些服務(wù)可以調(diào)用，然后把這個列表拿到。
Configserver會自動把相應(yīng)的provider的ip推送到consumer上面。然后consumer會自動發(fā)現(xiàn)provider的服務(wù)，然后彼此會發(fā)生一個相互調(diào)用關(guān)系。如果configserver掛掉之后，你的provider是掛不上去的，但是已經(jīng)發(fā)上去的服務(wù)是不受影響的，因為configserver已經(jīng)把相應(yīng)的服務(wù)推送到consumer上面。當(dāng)我們把分布式系統(tǒng)變得龐大之后，其實各個系統(tǒng)各司己職就好了。
Oracle其實也產(chǎn)生了性能瓶頸，而MySQL經(jīng)過了多年發(fā)展，已經(jīng)非常的成熟和穩(wěn)定了。我們考慮把數(shù)據(jù)庫做拆分，也就是去IOE。對MySQL進行拆分，其實就是按照一定的規(guī)則去分庫分表。拆分首先就是讀寫分離，然后做垂直拆分，還有水平拆分。垂直拆分主要是按業(yè)務(wù)來拆分，當(dāng)垂直拆分到一定程度之后，有一些大業(yè)務(wù)還是不能承擔(dān)這樣的數(shù)據(jù)量，我們只能水平做分庫分表，做sharding的拆分。分庫分表就基于某一些主鍵算，如果主鍵符合什么樣的條件，就Sharding到什么服務(wù)器上面。但是讓每一個業(yè)務(wù)系統(tǒng)去做的成本是非常高的，一定要有一個中間通用的東西，能夠解決數(shù)據(jù)庫水平拆分的問題。
所以我們開發(fā)了一套數(shù)據(jù)庫的中間件叫TDDL。TDDL就是在中間件層面支持數(shù)據(jù)庫的水平拆分，業(yè)務(wù)就是在寫單庫一樣，你不需要感知太多的東西，但是我已經(jīng)把數(shù)據(jù)分散到各個數(shù)據(jù)庫里面去了。當(dāng)時還有一個系統(tǒng)是CORONA，CORONA今天我們已經(jīng)把他放到云上面去了，它遵循標標準的JDBC協(xié)議，應(yīng)用在寫代碼的時候還是遵循標準的JDBC協(xié)議，完全不需要感知任何的東西，用的也是標準的JDBC包。把請求送到我們的server上面，server去做Sharding處理，整個對應(yīng)用是完全沒有感知的。
有了分庫分表，我們?nèi)绾伟裲racle的數(shù)據(jù)遷移到MySQL？對此，我們開發(fā)了幾個中間件，第一個就是“愚公”，把oracle里面的數(shù)據(jù)通過“愚公”一點一點地遷移到MySQL里面去，放到各個庫里面，同時保證我們的業(yè)務(wù)不受影響；當(dāng)我們把數(shù)據(jù)庫做分庫分表之后，我們還需要在數(shù)據(jù)庫和緩存之間做一些trigger，當(dāng)數(shù)據(jù)變了，需要觸發(fā)一個事件，可能以前我們需要通過寫一個程序來實現(xiàn)，現(xiàn)在我們也沉淀了一套中間件系統(tǒng)——精衛(wèi)，它會監(jiān)聽每個數(shù)據(jù)庫的變化，當(dāng)數(shù)據(jù)庫每個記錄發(fā)生變化之后，它就觸發(fā)一個事件，接聽到這個事件之后，業(yè)務(wù)方可以根據(jù)自己的業(yè)務(wù)需求寫一個精衛(wèi)的worker，然后放到精衛(wèi)里面去，觸發(fā)相應(yīng)的邏輯。
最典型的就是觸發(fā)cache邏輯。隨著我們IDC架構(gòu)之后，當(dāng)我們的數(shù)據(jù)在單點寫完之后，其他的地域如何感知到數(shù)據(jù)的變化呢？就是通過精衛(wèi)這樣一個系統(tǒng)實現(xiàn)的。當(dāng)數(shù)據(jù)庫變化了，精衛(wèi)會觸發(fā)失效cache，當(dāng)業(yè)務(wù)請求再過來的時候，就會把cache里面的數(shù)據(jù)填充成最新的數(shù)據(jù)，然后能夠讓業(yè)務(wù)看到最新的數(shù)據(jù)，就不會出現(xiàn)當(dāng)A單元數(shù)據(jù)變動了，然后B單元和C單元的cache沒有生效的情況。
先是垂直拆分后是水平拆分，接下來就是對應(yīng)用的拆分。應(yīng)用拆分是通過HSF這個RPC框架解決應(yīng)用之間的調(diào)用，解決同步調(diào)用，接下來還有異步調(diào)用。例如，我要創(chuàng)建一個訂單，訂單后面依賴了200多個系統(tǒng)，如果按照同步調(diào)用一步步進行下去，可能最終返回的返回時間會非常長，這時候怎么辦呢？我們會選擇并發(fā)，A去調(diào)用B、去調(diào)用C、去調(diào)用D的這種HSF直接調(diào)用。但這時存在一個問題，如果說下游依賴的200多個系統(tǒng)中有一個系統(tǒng)被掛起了，就使整個請求被掛起了，然后接下來就很難進行了，而且這時如果對方的系統(tǒng)出現(xiàn)了嚴重的問題，會使我后續(xù)的請求都被掛起，最終也會把我的系統(tǒng)拖垮。這個時候我們需要一個異步解耦的方式，那么就產(chǎn)生了消息中間件。
消息中間件就是當(dāng)A要去調(diào)用的時候，然后就會發(fā)一個消息，然后下游的系統(tǒng)開始訂閱這條消息，各自去處理各自的，處理完之后把結(jié)果返回給中間件，這樣就完成了異步通信過程。那么如果其中某一個系統(tǒng)發(fā)生了問題，前端的交易系統(tǒng)創(chuàng)建訂單的時候，它只要把消息發(fā)出去就不用管了，等所有的事情都處理完再回調(diào)它就可以了，就不會關(guān)注你如何調(diào)用。
圖為分布式消息的處理過程。在內(nèi)部我們主要用的消息是NOTIFY/METAQ。現(xiàn)在我們總體上都會在一個消息中間件上合并，其實并不需要這么多的中間件。應(yīng)用場景就是分布式最終一致性、應(yīng)用解耦、異步、并行等一系列問題。從整個物理部署也可以看出來，每個都是集群的，有name server、producer、consumer等，這又解決了一個穩(wěn)定性問題。我們單點沒有這個問題，隨便一個server掛掉，其實我們整個還是可以通信的，不會影響到業(yè)務(wù)的穩(wěn)定性。
隨著我們整個分布式架構(gòu)的演進，架構(gòu)變得異常復(fù)雜，依賴關(guān)系也變得異常復(fù)雜。這時候我們就想能不能可視化線上的問題，方便我們知道究竟發(fā)生了什么、它們之間的調(diào)用關(guān)系和調(diào)用鏈路是什么樣。于是乎就產(chǎn)生了分布式追蹤（EAGLEEYE）。
有了EAGLEEYE，我們就能清楚地知道一個請求過來，是怎么樣從入口一直傳遞到最后，中間都經(jīng)歷了什么，然后哪一塊可能是有問題的。像圖中這樣報錯位置會標紅，我們就可以清晰的知道是哪個系統(tǒng)出的問題。我們不需要再像以前一樣，大家各在排查自己的系統(tǒng)，導(dǎo)致我們處理問題的時間比較長。
異地多活
我們整個架構(gòu)演進到了4.0架構(gòu)，其實到分布式架構(gòu)看似我們已經(jīng)解決掉了業(yè)務(wù)上的問題。但是，我們會遇到新的問題，比如說資源問題、業(yè)務(wù)擴展性還有就是容災(zāi)問題。資源中最重要的問題就是資源受限，當(dāng)我們的機房都在一個地方，這個地方并不能無限擴展，隨著我們服務(wù)器數(shù)量越來越多，那么這個地方可能就放不下我們的服務(wù)器。
比如2013年我們買到機器之后，杭州的機房沒有地方去放。隨著我們搞雙十一活動，伴隨著銷售額和秒級峰值都有很大的提升，我們的成本也會有一定的提升，我們最終也會遇到單地域資源的限制；第二個是擴展性，有些業(yè)務(wù)可能不能只在這一個地方部署，因為別人訪問我會比較慢，需要部署到國外，這時候業(yè)務(wù)有一個異地部署的需求；第三個就是一個容災(zāi)的需求，畢竟天災(zāi)人禍都在所難免。比如說同樣是在2013年，杭州是40度的高溫，我們的機房差點被限電，還好最終沒有限。但是這也給了我們一個警示，就是我們必須要對我們的架構(gòu)進行演進。如果不演進的話，總有一天我們的資源會不夠。
架構(gòu)演進就是不把雞蛋放到同一個籃子里面，我們開始把我們的業(yè)務(wù)劃分出各個邏輯的單元，可以把它們放到各個地方，然后讓我們整個系統(tǒng)分散到全球，各個系統(tǒng)之間也沒有過強的依賴，當(dāng)某一個地域出現(xiàn)問題之后，不會影響到其他地方，我們只需要把流量切換一下就可以。現(xiàn)在我們應(yīng)用的就是這套架構(gòu)。
我們按照業(yè)務(wù)的維度，把業(yè)務(wù)劃分成各個邏輯單元。比如說第一個要做單元化的是交易單元，我們就把整個交易鏈路劃分出來，放到各個邏輯單元里面，然后在水平方向上進行拆分，然后把數(shù)據(jù)再在水平上做一個區(qū)分。單元內(nèi)的數(shù)據(jù)就不要發(fā)跨單元。如果跨單元就會出現(xiàn)一些問題，比如說容災(zāi)問題，如果A掛掉之后，可能不止影響到A，其他單元也會受到影響。如果發(fā)生跨單元調(diào)用，延時也會比較長，對于最終用戶下單的體驗也是非常差的。所以我們要遵循單元封閉的邏輯，讓每一個單元內(nèi)的調(diào)用關(guān)系都封閉在自己的單元內(nèi)，不要發(fā)生跨單元。
在技術(shù)架構(gòu)上，我們對技術(shù)做了一個分層，并且定了幾個原則，除了單元封閉原則之外，還有全局路由，全局路由解決的是全局用戶流量的分配，當(dāng)一個用戶流量進來之后，它會按照我們的路由規(guī)則分配到相應(yīng)的單元里面去。當(dāng)用戶流量進來，會跳到CDN，CDN知道其屬于哪個單元。然后到了某一單元之后，接入層會判斷其是否屬于這個單元，如果不屬于，會讓其跳到正確的單元里面去。如果屬于這個單元就繼續(xù)往下走，直到走到數(shù)據(jù)庫這一層。如果數(shù)據(jù)庫這一層出現(xiàn)了問題，我們做的是數(shù)據(jù)庫寫失敗，也不能夠讓其寫成功，所以數(shù)據(jù)要一致。
這時候?qū)τ跀?shù)據(jù)一致又出現(xiàn)了新的問題，比如說我們按照買家訂單寫到各個單元里面，但是賣家如何發(fā)貨呢？賣家其實是放到各個中心里面的，買家的所有下單數(shù)據(jù)都要同步到賣家這里。我們的模式就是最終一致性，就是對時間不是很敏感，我可以慢慢的同步，比如說，買家下了單，過了一兩秒之后才能同步到賣家那里，其實這個時間是大家都能夠接受的。對于強一致類型的數(shù)據(jù)，我們就跨單元，在同一個地點去撿數(shù)據(jù)。就是圖上面紅色部分——強中心依賴，所以這是我們交易鏈中核心——跨單元依賴。
我們整個單元化的項目經(jīng)歷了三年。2013年我們開始在杭州做了兩個POC驗證，驗證一下同城按照這種邏輯單元隔離開來，看看能否調(diào)用成功。2014年我們在杭州、上海近距離的兩個城市之間做了異地多活的嘗試。2015年我們開始在千里之外的地域去部署三地四單元架構(gòu)，其中一個單元是云單元，這是我們?yōu)榱私档统杀?，我們開始使用云機器來搞我們雙十一的大促。到2016年、2017年我們的單元數(shù)越來越多，分布的越來越廣，每一個單元都可以做一些相應(yīng)的嘗試。
這就是我們整個異地多活的架構(gòu)，異地多活解決的就是容災(zāi)問題、資源問題還有業(yè)務(wù)的擴展性問題。只要我們發(fā)現(xiàn)資源不夠了，我們只需要創(chuàng)建一個新的單元，就可以把容量擴上去。首先調(diào)用就把資源統(tǒng)一了，建站平臺通過調(diào)用就可以快速搭建一個單元。當(dāng)這個單元通過全鏈路壓測之后，我們整個單元就可以通入使用，這樣容量的問題就得到了解決。那么容災(zāi)的問題通過全局路由就可以解決。當(dāng)某個單元出了問題之后，我們只要快速的把流量切換出去就可以。業(yè)務(wù)擴展性是整個架構(gòu)天然具備的，我們已經(jīng)在千里之外把這個單元部署過了。
高可用問題也是我們面臨的一個比較大的問題，在2013年以前雙十一前幾分鐘的成功率是很低的，很多人是無法購物的。但是在2013年之后，通過全鏈路壓側(cè)這樣一個技術(shù)，能夠提前模擬雙十一零點這一刻的洪峰流量，使得我們能夠提前把問題解決掉，所以說整個購物體驗越來越順滑。高可用在整個雙十一備戰(zhàn)過程中起到一個非常核心的作用。
當(dāng)我們的業(yè)務(wù)在分布式和異步化之后，而且流量猛烈上漲之后，我們遇到的最大問題是容量評估：就是我也不知道我需要準備多少機器來抗這些流量，我也不知道我上下游依賴的應(yīng)用應(yīng)該準備多少流量，因為我根本不太清楚我們之間詳細的調(diào)用是什么樣子的。用戶來的時候不同的調(diào)用鏈路可能調(diào)用彼此的次數(shù)不一樣，所以說容量是很難評估的。所以我們首先模擬雙十一零點這一時刻的流量，把這個流量制造出來，看一下場景。通過我們制造的數(shù)據(jù)，提前把我們雙十一的問題暴漏出來。
高可用體系本身就是一套體系，它們之間彼此依賴，是閉環(huán)的。比如說我們一個單元的容量只有十萬，當(dāng)我容量超過十萬的時候該怎么辦呢？其實在雙十一的時候，如果數(shù)據(jù)超過十萬，系統(tǒng)會出現(xiàn)一個頁面告訴你正在排隊——限流。限流是怎么產(chǎn)生的呢？其實就是為了使我們能夠更好的服務(wù)于我們能夠服務(wù)的用戶范圍。對一個業(yè)務(wù)設(shè)定了一個閾值之后，當(dāng)流量超過了閾值，就開始進行限流。這個時候如果我想提升自己的彈性，應(yīng)該把那些沒有達到的閾值、也就是水位比較低的應(yīng)用，把它的機器彈過來，彈到水位比較高的應(yīng)用。
除了這些之外，其實我們的高可用還有很多，比如說關(guān)于容量能力，我剛才提到了壓測，全鏈路和單鏈路，還有線上的單機壓測，容量評估。靜態(tài)架構(gòu)有灰度發(fā)布、Eagleeye跟蹤。運行態(tài)有xflush/alimonitor、業(yè)務(wù)防止損BCP/DCP/Holo、限流降級Sentinel、開關(guān)平臺Switch、預(yù)案系統(tǒng)Preplan、流量調(diào)度Failover等，還有應(yīng)用資源管理應(yīng)用彈性伸縮Athena、資源調(diào)度Zeus、運行環(huán)境隔離Moses等。
這樣我們高可用體系就形成一個閉環(huán)。其中一個場景就是，比如我們進行壓測，這邊會限流，這該怎么辦呢？這時候彈性開始往外彈，把整個水位調(diào)勻，這樣會使我們通過壓測。第二個場景就是當(dāng)我一個應(yīng)用掛了之后，我把流量切到另外一個地方去了，就去觸發(fā)限流，如果這時候我們還有資源，我們應(yīng)該利用彈性，把水位彈上來。
新起點
云會變成如同水電煤一樣的基礎(chǔ)資源，越來越多的業(yè)務(wù)會在云上展現(xiàn)，這些業(yè)務(wù)中會有很多經(jīng)歷如同淘寶一樣的發(fā)展，我們展，我們將加速這些業(yè)務(wù)的發(fā)展進程，創(chuàng)造更大價值，用技術(shù)驅(qū)動業(yè)務(wù)，把我們的技術(shù)能力輸出到云上去。
現(xiàn)在我們不只服務(wù)于我們的雙十一，我們也想為其它企業(yè)提供技術(shù)服務(wù)，用技術(shù)驅(qū)動他們，讓他們也能只關(guān)心業(yè)務(wù)就好，不用去過多的關(guān)心底層是如何實現(xiàn)的。上面是一些在云端的產(chǎn)品，在阿里云上可以直接看到，像DRDS、EDAS、MQ等。
