作者：子柳，唐三（云棲社區(qū)）

阿里已經(jīng)不單單有電商業(yè)務(wù)，今天我們涉獵的非常廣泛，布局也非常多。阿里從一家電商公司開始，如果業(yè)務(wù)已經(jīng)覆蓋到了各個(gè)行業(yè)，圖為4年前，2015年的布局。

按照這樣的業(yè)務(wù)發(fā)展速度，如果沒有一套完整的技術(shù)體系支撐，勢(shì)必會(huì)影響整個(gè)業(yè)務(wù)的發(fā)展。

可以看到我們的技術(shù)是分層的,在最上的是業(yè)務(wù)，中間部分是中間件、搜索和大數(shù)據(jù)等中臺(tái)系統(tǒng)。整個(gè)的大中臺(tái)體系就是中中間這層通用的技術(shù)能夠快速支持上層業(yè)務(wù)的快速發(fā)展。只要是用發(fā)中臺(tái)的技術(shù)體系，都能夠在上面快速的搭建自己的業(yè)務(wù)。

整個(gè)中臺(tái)包括部分如圖，除了中間件、搜索，還有一些數(shù)據(jù)分析。中間件在業(yè)務(wù)研發(fā)的過程中起到非常重要的作用。這是在我們整個(gè)技術(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開始，跟大家分享這一段歷程。

整個(gè)淘寶網(wǎng)從開始想去創(chuàng)建，到真正上線，總共經(jīng)歷了一個(gè)多月的時(shí)間。那這一個(gè)多月的時(shí)間都做了些什么呢？

第一件事情，我們開始做技術(shù)選型，決定我們后續(xù)怎么發(fā)展；第二件事情，如何在一個(gè)多月的時(shí)間，讓我們的網(wǎng)站上線我們購(gòu)買了一套基于LAMP架構(gòu)的電商網(wǎng)站，并且拿到源代碼，我們對(duì)其進(jìn)行二次開發(fā)，比如界面的UI改動(dòng)，上下title的改動(dòng)，其中最大的改動(dòng)就是我們對(duì)它的數(shù)據(jù)庫做了讀寫分離。

隨著業(yè)務(wù)量的增長(zhǎng)，就會(huì)發(fā)現(xiàn)一些瓶頸，主要來自于數(shù)據(jù)庫。當(dāng)時(shí)的數(shù)據(jù)庫是MySQL4，還不夠穩(wěn)定，數(shù)據(jù)庫經(jīng)常會(huì)出現(xiàn)死機(jī)。因此，我們直接把數(shù)據(jù)庫換成oracle，通過PHP和oracle直接去連接進(jìn)行操作，但PHP不支持連接池，即使使用一些開源的PHP中間件，讓PHP去連接oracle，還是非常不穩(wěn)定，連接池的中間件經(jīng)常卡死。

然后我們開始考慮將技術(shù)體系轉(zhuǎn)成Java，因?yàn)镴ava在企業(yè)級(jí)的應(yīng)用中，有著比較成熟的生態(tài)。轉(zhuǎn)化的過程中也還是很坎坷的：第一，我們是一個(gè)線上正在運(yùn)行的系統(tǒng)；第二，系統(tǒng)當(dāng)時(shí)正在大規(guī)模的增長(zhǎng)。所以說把系統(tǒng)替換成Java，最好的方法就是分塊替換。同時(shí)發(fā)現(xiàn)，oracle的寫入量還是比較大的，當(dāng)時(shí)還做了一個(gè)search，把產(chǎn)品搜索和店鋪搜索放到search里面，這樣每一次的請(qǐng)求都打到數(shù)據(jù)庫里面了，這樣我們就完成了1.0架構(gòu)到2.0架構(gòu)的演進(jìn)。

隨著整個(gè)業(yè)務(wù)的發(fā)展，我們又迎來了新問題，洪峰流量給我們帶來了巨大的挑戰(zhàn)，電商行業(yè)在國(guó)內(nèi)已經(jīng)逐步開始盛行，我們的流量直線上漲，電商的人口紅利也開始上漲。隨著流量的上漲，我們面臨著服務(wù)器和數(shù)據(jù)庫的壓力。

從技術(shù)角度來看，我們面臨著兩個(gè)問題：

首先是淘寶上描述商品的圖片特別多，圖片問題非常嚴(yán)重，主要取決于我們采用的是商用存儲(chǔ)，成本非常高，最高級(jí)別版本也很難存儲(chǔ)下我們所有的圖片；

其次在淘寶上瀏覽的所有交易都有交易快照，這也是非常耗費(fèi)存儲(chǔ)成本的；

第三，雖然數(shù)據(jù)庫替換成了oracle，隨著數(shù)據(jù)量的增大，我們所有的請(qǐng)求都打到數(shù)據(jù)庫上面，這時(shí)數(shù)據(jù)庫的存儲(chǔ)也快達(dá)到了極限，壓力也非常大。

所以我們開始對(duì)架構(gòu)升級(jí)。第一，我們?cè)黾恿藘?nèi)存cache，cache主要是解決數(shù)據(jù)庫壓力過大的問題，我們自己研制了一套Key/Value 分布式緩存（TAIR），就是在數(shù)據(jù)庫前端加了一個(gè)內(nèi)存cache，緩解了我們數(shù)據(jù)庫的壓力。第二，我們?cè)黾恿朔植际轿募到y(tǒng)（TFS），之前的文件系統(tǒng)在商用的時(shí)候，成本太高，服務(wù)器的量非常大，所以我們研發(fā)了自己的一套文件系統(tǒng)。

隨著我們的業(yè)務(wù)量逐漸增大，人也越來越多，這就導(dǎo)致開發(fā)維護(hù)成本特別高，當(dāng)時(shí)我們是all-in-one系統(tǒng)，所有人改所有的代碼都是在這一個(gè)系統(tǒng)里面，就會(huì)出現(xiàn)以下問題：

• 技術(shù)團(tuán)隊(duì)規(guī)模500人左右，維護(hù)變得越來越復(fù)雜

• 單一War應(yīng)用，應(yīng)用包一直增長(zhǎng)，更新業(yè)務(wù)特性越來越慢；數(shù)據(jù)逐步形成多個(gè)孤島，無法拉通

• 基于傳統(tǒng)應(yīng)用開發(fā)架構(gòu)，業(yè)務(wù)爆發(fā)，彈性不足，單點(diǎn)故障影響巨大

還有性能問題。隨著前端業(yè)務(wù)量的增大，服務(wù)器逐漸增多的時(shí)候，oracle也出現(xiàn)了連接數(shù)的瓶頸。所以我們必須開始做新的架構(gòu)，讓整個(gè)架構(gòu)往前走一步。

于是，我們邁向了3.0架構(gòu)。系統(tǒng)進(jìn)行拆分變小，拆分系統(tǒng)主要是把系統(tǒng)分層。把系統(tǒng)分成三類：

第一類是c類，是中心類，比如說會(huì)員、商品、店鋪等等，基于這些中心上面開發(fā)各自的系統(tǒng)。比如說商品詳情、交易下單；

還有一些公共的類，是p類，比如交易平臺(tái)，這是從業(yè)務(wù)上進(jìn)行拆分。幾個(gè)比較知名的項(xiàng)目，比如千島湖項(xiàng)目（拆分出交易中心、類目屬性中心）、五彩石項(xiàng)目（拆分出店鋪中心、商品中心、評(píng)價(jià)中心）。

伴隨著技術(shù)架構(gòu)的改動(dòng)，我們的業(yè)務(wù)結(jié)構(gòu)也開始進(jìn)行改動(dòng)，開始成立了相應(yīng)的團(tuán)隊(duì)。上圖的下半部分就介紹了我們架構(gòu)的演變過程。開始時(shí)，是all in one，1~10在維護(hù)一個(gè)項(xiàng)目。第二個(gè)階段是10~1000人維護(hù)的MVC架構(gòu)，實(shí)現(xiàn)了前后端分離，各司其職。第三個(gè)階段是RPC，就是把各個(gè)系統(tǒng)進(jìn)行拆分，然后各個(gè)系統(tǒng)之間進(jìn)行通信。第四個(gè)階段就是SOA這樣一個(gè)模式。

重點(diǎn)分享RPC的發(fā)展歷程。我們把應(yīng)用拆成才c類、p類、垂直團(tuán)隊(duì)類。這些應(yīng)用本來就是在一個(gè)大應(yīng)用里面，他們之間可以很自然地進(jìn)行通信，可以直接進(jìn)行相互調(diào)用。但是拆分之后，我們的應(yīng)用如何進(jìn)行相互調(diào)用？

我們開發(fā)了輕量級(jí)的HSF框架，它是基于Java interface 的RPC框架，使得開發(fā)系統(tǒng)時(shí)就像開發(fā)本地應(yīng)用一樣去正常的調(diào)用Java。使用這個(gè)框架可以真正遠(yuǎn)程的調(diào)用到其他的系統(tǒng)上面。

隨著應(yīng)用逐漸發(fā)展，我們會(huì)依賴中間件或者各個(gè)產(chǎn)品之間相互依賴。為了解決Jar包沖突的問題，我們研究出了Pandora容器。這個(gè)容器能把所有的加包做隔離，當(dāng)發(fā)生Jar包沖突的時(shí)候，它知道優(yōu)先加載哪個(gè)，這樣，我們就把Jar包沖突的問題解決了，那服務(wù)發(fā)現(xiàn)怎么辦呢？比如：一個(gè)應(yīng)用A如何知道應(yīng)用B里面有多少臺(tái)機(jī)器呢，你的ip又是什么？最簡(jiǎn)單的方式就是靜態(tài)列表，記錄下ip，做輪詢策略，先調(diào)用A的1號(hào)機(jī)，再調(diào)用2號(hào)機(jī)。這樣就沒法實(shí)現(xiàn)一個(gè)動(dòng)態(tài)的發(fā)現(xiàn)。所以在這個(gè)過程中，我們有一個(gè)動(dòng)態(tài)的配置中心（configserver），在你服務(wù)上線的時(shí)候，作為provider把服務(wù)放到configserver上去，當(dāng)需要消費(fèi)這個(gè)服務(wù)的時(shí)候，會(huì)看哪些服務(wù)可以調(diào)用，然后把這個(gè)列表拿到。

Configserver會(huì)自動(dòng)把相應(yīng)的provider的ip推送到consumer上面。然后consumer會(huì)自動(dòng)發(fā)現(xiàn)provider的服務(wù)，然后彼此會(huì)發(fā)生一個(gè)相互調(diào)用關(guān)系。如果configserver掛掉之后，你的provider是掛不上去的，但是已經(jīng)發(fā)上去的服務(wù)是不受影響的，因?yàn)閏onfigserver已經(jīng)把相應(yīng)的服務(wù)推送到consumer上面。當(dāng)我們把分布式系統(tǒng)變得龐大之后，其實(shí)各個(gè)系統(tǒng)各司己職就好了。

Oracle其實(shí)也產(chǎn)生了性能瓶頸，而MySQL經(jīng)過了多年發(fā)展，已經(jīng)非常的成熟和穩(wěn)定了。我們考慮把數(shù)據(jù)庫做拆分，也就是去IOE。對(duì)MySQL進(jìn)行拆分，其實(shí)就是按照一定的規(guī)則去分庫分表。拆分首先就是讀寫分離，然后做垂直拆分，還有水平拆分。垂直拆分主要是按業(yè)務(wù)來拆分，當(dāng)垂直拆分到一定程度之后，有一些大業(yè)務(wù)還是不能承擔(dān)這樣的數(shù)據(jù)量，我們只能水平做分庫分表，做sharding的拆分。分庫分表就基于某一些主鍵算，如果主鍵符合什么樣的條件，就Sharding到什么服務(wù)器上面。但是讓每一個(gè)業(yè)務(wù)系統(tǒng)去做的成本是非常高的，一定要有一個(gè)中間通用的東西，能夠解決數(shù)據(jù)庫水平拆分的問題。

所以我們開發(fā)了一套數(shù)據(jù)庫的中間件叫TDDL。TDDL就是在中間件層面支持?jǐn)?shù)據(jù)庫的水平拆分，業(yè)務(wù)就是在寫單庫一樣，你不需要感知太多的東西，但是我已經(jīng)把數(shù)據(jù)分散到各個(gè)數(shù)據(jù)庫里面去了。當(dāng)時(shí)還有一個(gè)系統(tǒng)是CORONA，CORONA今天我們已經(jīng)把他放到云上面去了，它遵循標(biāo)標(biāo)準(zhǔn)的JDBC協(xié)議，應(yīng)用在寫代碼的時(shí)候還是遵循標(biāo)準(zhǔn)的JDBC協(xié)議，完全不需要感知任何的東西，用的也是標(biāo)準(zhǔn)的JDBC包。把請(qǐng)求送到我們的server上面，server去做Sharding處理，整個(gè)對(duì)應(yīng)用是完全沒有感知的。

有了分庫分表，我們?nèi)绾伟裲racle的數(shù)據(jù)遷移到MySQL？對(duì)此，我們開發(fā)了幾個(gè)中間件，第一個(gè)就是“愚公”，把oracle里面的數(shù)據(jù)通過“愚公”一點(diǎn)一點(diǎn)地遷移到MySQL里面去，放到各個(gè)庫里面，同時(shí)保證我們的業(yè)務(wù)不受影響；當(dāng)我們把數(shù)據(jù)庫做分庫分表之后，我們還需要在數(shù)據(jù)庫和緩存之間做一些trigger，當(dāng)數(shù)據(jù)變了，需要觸發(fā)一個(gè)事件，可能以前我們需要通過寫一個(gè)程序來實(shí)現(xiàn)，現(xiàn)在我們也沉淀了一套中間件系統(tǒng)——精衛(wèi)，它會(huì)監(jiān)聽每個(gè)數(shù)據(jù)庫的變化，當(dāng)數(shù)據(jù)庫每個(gè)記錄發(fā)生變化之后，它就觸發(fā)一個(gè)事件，接聽到這個(gè)事件之后，業(yè)務(wù)方可以根據(jù)自己的業(yè)務(wù)需求寫一個(gè)精衛(wèi)的worker，然后放到精衛(wèi)里面去，觸發(fā)相應(yīng)的邏輯。

最典型的就是觸發(fā)cache邏輯。隨著我們IDC架構(gòu)之后，當(dāng)我們的數(shù)據(jù)在單點(diǎn)寫完之后，其他的地域如何感知到數(shù)據(jù)的變化呢？就是通過精衛(wèi)這樣一個(gè)系統(tǒng)實(shí)現(xiàn)的。當(dāng)數(shù)據(jù)庫變化了，精衛(wèi)會(huì)觸發(fā)失效cache，當(dāng)業(yè)務(wù)請(qǐng)求再過來的時(shí)候，就會(huì)把cache里面的數(shù)據(jù)填充成最新的數(shù)據(jù)，然后能夠讓業(yè)務(wù)看到最新的數(shù)據(jù)，就不會(huì)出現(xiàn)當(dāng)A單元數(shù)據(jù)變動(dòng)了，然后B單元和C單元的cache沒有生效的情況。

先是垂直拆分后是水平拆分，接下來就是對(duì)應(yīng)用的拆分。應(yīng)用拆分是通過HSF這個(gè)RPC框架解決應(yīng)用之間的調(diào)用，解決同步調(diào)用，接下來還有異步調(diào)用。例如，我要?jiǎng)?chuàng)建一個(gè)訂單，訂單后面依賴了200多個(gè)系統(tǒng)，如果按照同步調(diào)用一步步進(jìn)行下去，可能最終返回的返回時(shí)間會(huì)非常長(zhǎng)，這時(shí)候怎么辦呢？我們會(huì)選擇并發(fā)，A去調(diào)用B、去調(diào)用C、去調(diào)用D的這種HSF直接調(diào)用。但這時(shí)存在一個(gè)問題，如果說下游依賴的200多個(gè)系統(tǒng)中有一個(gè)系統(tǒng)被掛起了，就使整個(gè)請(qǐng)求被掛起了，然后接下來就很難進(jìn)行了，而且這時(shí)如果對(duì)方的系統(tǒng)出現(xiàn)了嚴(yán)重的問題，會(huì)使我后續(xù)的請(qǐng)求都被掛起，最終也會(huì)把我的系統(tǒng)拖垮。這個(gè)時(shí)候我們需要一個(gè)異步解耦的方式，那么就產(chǎn)生了消息中間件。

消息中間件就是當(dāng)A要去調(diào)用的時(shí)候，然后就會(huì)發(fā)一個(gè)消息，然后下游的系統(tǒng)開始訂閱這條消息，各自去處理各自的，處理完之后把結(jié)果返回給中間件，這樣就完成了異步通信過程。那么如果其中某一個(gè)系統(tǒng)發(fā)生了問題，前端的交易系統(tǒng)創(chuàng)建訂單的時(shí)候，它只要把消息發(fā)出去就不用管了，等所有的事情都處理完再回調(diào)它就可以了，就不會(huì)關(guān)注你如何調(diào)用。 

圖為分布式消息的處理過程。在內(nèi)部我們主要用的消息是NOTIFY/METAQ。現(xiàn)在我們總體上都會(huì)在一個(gè)消息中間件上合并，其實(shí)并不需要這么多的中間件。應(yīng)用場(chǎng)景就是分布式最終一致性、應(yīng)用解耦、異步、并行等一系列問題。從整個(gè)物理部署也可以看出來，每個(gè)都是集群的，有name server、producer、consumer等，這又解決了一個(gè)穩(wěn)定性問題。我們單點(diǎn)沒有這個(gè)問題，隨便一個(gè)server掛掉，其實(shí)我們整個(gè)還是可以通信的，不會(huì)影響到業(yè)務(wù)的穩(wěn)定性。

隨著我們整個(gè)分布式架構(gòu)的演進(jìn)，架構(gòu)變得異常復(fù)雜，依賴關(guān)系也變得異常復(fù)雜。這時(shí)候我們就想能不能可視化線上的問題，方便我們知道究竟發(fā)生了什么、它們之間的調(diào)用關(guān)系和調(diào)用鏈路是什么樣。于是乎就產(chǎn)生了分布式追蹤（EAGLEEYE）。

有了EAGLEEYE，我們就能清楚地知道一個(gè)請(qǐng)求過來，是怎么樣從入口一直傳遞到最后，中間都經(jīng)歷了什么，然后哪一塊可能是有問題的。像圖中這樣報(bào)錯(cuò)位置會(huì)標(biāo)紅，我們就可以清晰的知道是哪個(gè)系統(tǒng)出的問題。我們不需要再像以前一樣，大家各在排查自己的系統(tǒng)，導(dǎo)致我們處理問題的時(shí)間比較長(zhǎng)。

我們整個(gè)架構(gòu)演進(jìn)到了4.0架構(gòu)，其實(shí)到分布式架構(gòu)看似我們已經(jīng)解決掉了業(yè)務(wù)上的問題。但是，我們會(huì)遇到新的問題，比如說資源問題、業(yè)務(wù)擴(kuò)展性還有就是容災(zāi)問題。資源中最重要的問題就是資源受限，當(dāng)我們的機(jī)房都在一個(gè)地方，這個(gè)地方并不能無限擴(kuò)展，隨著我們服務(wù)器數(shù)量越來越多，那么這個(gè)地方可能就放不下我們的服務(wù)器。

比如2013年我們買到機(jī)器之后，杭州的機(jī)房沒有地方去放。隨著我們搞雙十一活動(dòng)，伴隨著銷售額和秒級(jí)峰值都有很大的提升，我們的成本也會(huì)有一定的提升，我們最終也會(huì)遇到單地域資源的限制；第二個(gè)是擴(kuò)展性，有些業(yè)務(wù)可能不能只在這一個(gè)地方部署，因?yàn)閯e人訪問我會(huì)比較慢，需要部署到國(guó)外，這時(shí)候業(yè)務(wù)有一個(gè)異地部署的需求；第三個(gè)就是一個(gè)容災(zāi)的需求，畢竟天災(zāi)人禍都在所難免。比如說同樣是在2013年，杭州是40度的高溫，我們的機(jī)房差點(diǎn)被限電，還好最終沒有限。但是這也給了我們一個(gè)警示，就是我們必須要對(duì)我們的架構(gòu)進(jìn)行演進(jìn)。如果不演進(jìn)的話，總有一天我們的資源會(huì)不夠。

架構(gòu)演進(jìn)就是不把雞蛋放到同一個(gè)籃子里面，我們開始把我們的業(yè)務(wù)劃分出各個(gè)邏輯的單元，可以把它們放到各個(gè)地方，然后讓我們整個(gè)系統(tǒng)分散到全球，各個(gè)系統(tǒng)之間也沒有過強(qiáng)的依賴，當(dāng)某一個(gè)地域出現(xiàn)問題之后，不會(huì)影響到其他地方，我們只需要把流量切換一下就可以。現(xiàn)在我們應(yīng)用的就是這套架構(gòu)。

我們按照業(yè)務(wù)的維度，把業(yè)務(wù)劃分成各個(gè)邏輯單元。比如說第一個(gè)要做單元化的是交易單元，我們就把整個(gè)交易鏈路劃分出來，放到各個(gè)邏輯單元里面，然后在水平方向上進(jìn)行拆分，然后把數(shù)據(jù)再在水平上做一個(gè)區(qū)分。單元內(nèi)的數(shù)據(jù)就不要發(fā)跨單元。如果跨單元就會(huì)出現(xiàn)一些問題，比如說容災(zāi)問題，如果A掛掉之后，可能不止影響到A，其他單元也會(huì)受到影響。如果發(fā)生跨單元調(diào)用，延時(shí)也會(huì)比較長(zhǎng)，對(duì)于最終用戶下單的體驗(yàn)也是非常差的。所以我們要遵循單元封閉的邏輯，讓每一個(gè)單元內(nèi)的調(diào)用關(guān)系都封閉在自己的單元內(nèi)，不要發(fā)生跨單元。

在技術(shù)架構(gòu)上，我們對(duì)技術(shù)做了一個(gè)分層，并且定了幾個(gè)原則，除了單元封閉原則之外，還有全局路由，全局路由解決的是全局用戶流量的分配，當(dāng)一個(gè)用戶流量進(jìn)來之后，它會(huì)按照我們的路由規(guī)則分配到相應(yīng)的單元里面去。當(dāng)用戶流量進(jìn)來，會(huì)跳到CDN，CDN知道其屬于哪個(gè)單元。然后到了某一單元之后，接入層會(huì)判斷其是否屬于這個(gè)單元，如果不屬于，會(huì)讓其跳到正確的單元里面去。如果屬于這個(gè)單元就繼續(xù)往下走，直到走到數(shù)據(jù)庫這一層。如果數(shù)據(jù)庫這一層出現(xiàn)了問題，我們做的是數(shù)據(jù)庫寫失敗，也不能夠讓其寫成功，所以數(shù)據(jù)要一致。

這時(shí)候?qū)τ跀?shù)據(jù)一致又出現(xiàn)了新的問題，比如說我們按照買家訂單寫到各個(gè)單元里面，但是賣家如何發(fā)貨呢？賣家其實(shí)是放到各個(gè)中心里面的，買家的所有下單數(shù)據(jù)都要同步到賣家這里。我們的模式就是最終一致性，就是對(duì)時(shí)間不是很敏感，我可以慢慢的同步，比如說，買家下了單，過了一兩秒之后才能同步到賣家那里，其實(shí)這個(gè)時(shí)間是大家都能夠接受的。對(duì)于強(qiáng)一致類型的數(shù)據(jù)，我們就跨單元，在同一個(gè)地點(diǎn)去撿數(shù)據(jù)。就是圖上面紅色部分——強(qiáng)中心依賴，所以這是我們交易鏈中核心——跨單元依賴。

我們整個(gè)單元化的項(xiàng)目經(jīng)歷了三年。2013年我們開始在杭州做了兩個(gè)POC驗(yàn)證，驗(yàn)證一下同城按照這種邏輯單元隔離開來，看看能否調(diào)用成功。2014年我們?cè)诤贾?、上海近距離的兩個(gè)城市之間做了異地多活的嘗試。2015年我們開始在千里之外的地域去部署三地四單元架構(gòu)，其中一個(gè)單元是云單元，這是我們?yōu)榱私档统杀?，我們開始使用云機(jī)器來搞我們雙十一的大促。到2016年、2017年我們的單元數(shù)越來越多，分布的越來越廣，每一個(gè)單元都可以做一些相應(yīng)的嘗試。

這就是我們整個(gè)異地多活的架構(gòu)，異地多活解決的就是容災(zāi)問題、資源問題還有業(yè)務(wù)的擴(kuò)展性問題。只要我們發(fā)現(xiàn)資源不夠了，我們只需要?jiǎng)?chuàng)建一個(gè)新的單元，就可以把容量擴(kuò)上去。首先調(diào)用就把資源統(tǒng)一了，建站平臺(tái)通過調(diào)用就可以快速搭建一個(gè)單元。當(dāng)這個(gè)單元通過全鏈路壓測(cè)之后，我們整個(gè)單元就可以通入使用，這樣容量的問題就得到了解決。那么容災(zāi)的問題通過全局路由就可以解決。當(dāng)某個(gè)單元出了問題之后，我們只要快速的把流量切換出去就可以。業(yè)務(wù)擴(kuò)展性是整個(gè)架構(gòu)天然具備的，我們已經(jīng)在千里之外把這個(gè)單元部署過了。

高可用問題也是我們面臨的一個(gè)比較大的問題，在2013年以前雙十一前幾分鐘的成功率是很低的，很多人是無法購(gòu)物的。但是在2013年之后，通過全鏈路壓側(cè)這樣一個(gè)技術(shù)，能夠提前模擬雙十一零點(diǎn)這一刻的洪峰流量，使得我們能夠提前把問題解決掉，所以說整個(gè)購(gòu)物體驗(yàn)越來越順滑。高可用在整個(gè)雙十一備戰(zhàn)過程中起到一個(gè)非常核心的作用。

當(dāng)我們的業(yè)務(wù)在分布式和異步化之后，而且流量猛烈上漲之后，我們遇到的最大問題是容量評(píng)估：就是我也不知道我需要準(zhǔn)備多少機(jī)器來抗這些流量，我也不知道我上下游依賴的應(yīng)用應(yīng)該準(zhǔn)備多少流量，因?yàn)槲腋静惶宄覀冎g詳細(xì)的調(diào)用是什么樣子的。用戶來的時(shí)候不同的調(diào)用鏈路可能調(diào)用彼此的次數(shù)不一樣，所以說容量是很難評(píng)估的。所以我們首先模擬雙十一零點(diǎn)這一時(shí)刻的流量，把這個(gè)流量制造出來，看一下場(chǎng)景。通過我們制造的數(shù)據(jù)，提前把我們雙十一的問題暴漏出來。

高可用體系本身就是一套體系，它們之間彼此依賴，是閉環(huán)的。比如說我們一個(gè)單元的容量只有十萬，當(dāng)我容量超過十萬的時(shí)候該怎么辦呢？其實(shí)在雙十一的時(shí)候，如果數(shù)據(jù)超過十萬，系統(tǒng)會(huì)出現(xiàn)一個(gè)頁面告訴你正在排隊(duì)——限流。限流是怎么產(chǎn)生的呢？其實(shí)就是為了使我們能夠更好的服務(wù)于我們能夠服務(wù)的用戶范圍。對(duì)一個(gè)業(yè)務(wù)設(shè)定了一個(gè)閾值之后，當(dāng)流量超過了閾值，就開始進(jìn)行限流。這個(gè)時(shí)候如果我想提升自己的彈性，應(yīng)該把那些沒有達(dá)到的閾值、也就是水位比較低的應(yīng)用，把它的機(jī)器彈過來，彈到水位比較高的應(yīng)用。

除了這些之外，其實(shí)我們的高可用還有很多，比如說關(guān)于容量能力，我剛才提到了壓測(cè)，全鏈路和單鏈路，還有線上的單機(jī)壓測(cè)，容量評(píng)估。靜態(tài)架構(gòu)有灰度發(fā)布、Eagleeye跟蹤。運(yùn)行態(tài)有xflush/alimonitor、業(yè)務(wù)防止損BCP/DCP/Holo、限流降級(jí)Sentinel、開關(guān)平臺(tái)Switch、預(yù)案系統(tǒng)Preplan、流量調(diào)度Failover等，還有應(yīng)用資源管理應(yīng)用彈性伸縮Athena、資源調(diào)度Zeus、運(yùn)行環(huán)境隔離Moses等。

這樣我們高可用體系就形成一個(gè)閉環(huán)。其中一個(gè)場(chǎng)景就是，比如我們進(jìn)行壓測(cè)，這邊會(huì)限流，這該怎么辦呢？這時(shí)候彈性開始往外彈，把整個(gè)水位調(diào)勻，這樣會(huì)使我們通過壓測(cè)。第二個(gè)場(chǎng)景就是當(dāng)我一個(gè)應(yīng)用掛了之后，我把流量切到另外一個(gè)地方去了，就去觸發(fā)限流，如果這時(shí)候我們還有資源，我們應(yīng)該利用彈性，把水位彈上來。

云會(huì)變成如同水電煤一樣的基礎(chǔ)資源，越來越多的業(yè)務(wù)會(huì)在云上展現(xiàn)，這些業(yè)務(wù)中會(huì)有很多經(jīng)歷如同淘寶一樣的發(fā)展，我們展，我們將加速這些業(yè)務(wù)的發(fā)展進(jìn)程，創(chuàng)造更大價(jià)值，用技術(shù)驅(qū)動(dòng)業(yè)務(wù)，把我們的技術(shù)能力輸出到云上去。

現(xiàn)在我們不只服務(wù)于我們的雙十一，我們也想為其它企業(yè)提供技術(shù)服務(wù)，用技術(shù)驅(qū)動(dòng)他們，讓他們也能只關(guān)心業(yè)務(wù)就好，不用去過多的關(guān)心底層是如何實(shí)現(xiàn)的。上面是一些在云端的產(chǎn)品，在阿里云上可以直接看到，像DRDS、EDAS、MQ等。