分享一篇文章，對(duì)于Linux入門學(xué)習(xí)者可能略顯高深，但是仔細(xì)讀的話會(huì)有巨大的收獲。這篇文章來自與阿里巴巴技術(shù)專家在Qcan大會(huì)上的演講，在這次演講中介紹了其近幾年在阿里電商平臺(tái)及阿里云上的高可用設(shè)計(jì)的經(jīng)驗(yàn)，無論是入門還是進(jìn)階都會(huì)很有收獲。

演講全文：

沐劍

大家好，我今天分享的題目是《高可用實(shí)踐：從淘寶到上云的差異》，取這個(gè)標(biāo)題是因?yàn)闀?huì)涉及到兩個(gè)方面內(nèi)容，一方面以淘寶為例子，傳統(tǒng)的IDC的時(shí)候，我們穩(wěn)定性是怎么做的，另外在云計(jì)算背景下，有很多創(chuàng)業(yè)公司是基于阿里云這樣的公有云基礎(chǔ)設(shè)施做研發(fā)，在公有云的環(huán)境下怎么做好我們系統(tǒng)的高可用。

長(zhǎng)期做穩(wěn)定性的人會(huì)有一些職業(yè)病，記得去年冬天有個(gè)周末，我要寄快遞，穿著睡衣在門口填快遞單，那時(shí)候我家里養(yǎng)了一只貓，因?yàn)榕仑埮艹鋈ィ桶验T關(guān)上了。寄完快遞口袋一掏發(fā)現(xiàn)自己沒帶鑰匙，冷靜了3秒鐘，打車到公司剛巧碰到同事，看我穿著睡衣來公司了問我什么情況，我說家里鑰匙忘帶被鎖在門外面了，不過沒事，我還有一把backup鑰匙放在公司。生活中很多時(shí)候都需要有一個(gè)backup。

我的花名叫沐劍，2011年加入淘寶做評(píng)價(jià)系統(tǒng)，2012-2015年在店鋪平臺(tái)，負(fù)責(zé)店鋪的前臺(tái)瀏覽系統(tǒng)和后臺(tái)的RPC服務(wù)，以及一些性能優(yōu)化、雙11保障的事情。到了2015年開始到了TAE團(tuán)隊(duì)，開始負(fù)責(zé)云端架構(gòu)及整體高可用方案，TAE的升級(jí)版EWS現(xiàn)在也在聚石塔上面幫大量ISV和創(chuàng)業(yè)公司解決運(yùn)維部署、自動(dòng)化監(jiān)控和性能分析等等問題。去年我是作為阿里商家事業(yè)部雙11作戰(zhàn)項(xiàng)目研發(fā)的PM。2017年我開始接手商家營銷團(tuán)隊(duì)。在阿里五六年的經(jīng)驗(yàn)，其實(shí)就做了幾件事，比如連續(xù)五年參加了雙十一的核心備戰(zhàn)，然后像去IOE、異地多活，全鏈路壓測(cè)、安全混合云、容器服務(wù)等項(xiàng)目參與設(shè)計(jì)和實(shí)施。

首先我會(huì)從淘寶店鋪角度分享，以前在店鋪是怎么樣做雙11保障的，后面是一些公有云相關(guān)的內(nèi)容。這是一個(gè)淘寶的店鋪系統(tǒng)，這套系統(tǒng)是一個(gè)非常典型的高并發(fā)的瀏覽系統(tǒng)，在前幾年的雙11峰值有20萬次的Web頁面請(qǐng)求，平均一個(gè)頁面對(duì)應(yīng)了20次的RPC調(diào)用，這個(gè)時(shí)候?qū)τ谡麄€(gè)系統(tǒng)的集合來說每秒的QPS是400萬次，這中間就會(huì)涉及到緩存、數(shù)據(jù)庫以及其它二方的RPC調(diào)用，對(duì)于這樣的系統(tǒng)來說，在性能、穩(wěn)定性和體驗(yàn)間要做一個(gè)平衡，既不能純用太多的機(jī)器死扛這個(gè)訪問量，又要保障用戶的體驗(yàn)。

從請(qǐng)求鏈路來說，首先DNS把CDN的VIP解析出來，分布在全球不同的區(qū)域，CDN回源到接入層分別經(jīng)過4層和7層的負(fù)載均衡，近幾年會(huì)發(fā)現(xiàn)CDN這個(gè)行業(yè)早已不僅僅局限做CSS/JS等靜態(tài)資源的緩存，也承擔(dān)了一些動(dòng)態(tài)加速和收斂的特性，所以我們是通過CDN做域名收斂，收斂后會(huì)把這個(gè)流量發(fā)到統(tǒng)一接入層，然后到應(yīng)用集群，后面再經(jīng)過應(yīng)用存儲(chǔ)、Cache這些服務(wù)。

當(dāng)我們?cè)谧龇€(wěn)定性的時(shí)候，會(huì)考慮性能和穩(wěn)定性之間是什么關(guān)系，很多人認(rèn)為這兩者是沖突的，比如我要保障一個(gè)東西的性能非常高的時(shí)候，要犧牲掉很多別的東西，可能你要引入一個(gè)非常新的框架或者基礎(chǔ)設(shè)施來提升性能，但它的穩(wěn)定性可能是不那么成熟的，但是從容量規(guī)劃的角度看，只有這套系統(tǒng)性能足夠好，才能承擔(dān)像雙11那樣的大訪問量。

店鋪也是一套經(jīng)歷了很多年的系統(tǒng)，在應(yīng)用層上的優(yōu)化基本上已經(jīng)做到極致了，我們就轉(zhuǎn)變思路，在操作系統(tǒng)層能不能做一些優(yōu)化，這里借助了一個(gè)比較好的工具perf，在操作系統(tǒng)層面告訴你系統(tǒng)調(diào)用的開銷是集中在哪里，從perf上就可以定位到有一個(gè)百分比，可以看到是比如數(shù)組分配還是GC產(chǎn)生了大量的開銷。最初我們發(fā)現(xiàn)是異常帶來的開銷，就會(huì)看為什么這個(gè)系統(tǒng)的異常會(huì)導(dǎo)致20%以上的CPU開銷，最后用BTrace跟了一下異常的構(gòu)造函數(shù)，發(fā)現(xiàn)是我們依賴的開源的三方包里通過異常做控制流，每一次它處理結(jié)束的時(shí)候，就拋一個(gè)EOFException出來，這個(gè)就導(dǎo)致了非常大的開銷，我們就把開源包替換掉了。當(dāng)你依賴一些底層的東西的時(shí)候，如果對(duì)原理不太了解會(huì)給你帶來一些意料之外的事情。JVM里是有一個(gè)常量池存儲(chǔ)字符串常量的地方，就是一個(gè)哈希表，如果說這個(gè)表的大小不足夠大，就會(huì)從哈希查詢變成鏈表查詢，性能就會(huì)特別低。

再談一個(gè)warm up的問題，當(dāng)我們應(yīng)用剛剛啟動(dòng)的時(shí)候，還沒有把字節(jié)碼編譯成native code，延遲非常高，用戶就得到一個(gè)有損的服務(wù)。我們現(xiàn)在在內(nèi)部的JVM做一個(gè)功能，會(huì)采集線上系統(tǒng)的調(diào)用，把熱點(diǎn)方法收集下來做分析，在應(yīng)用把真實(shí)流量掛上去之前，已經(jīng)預(yù)先把所有的熱點(diǎn)方法編譯成native code保證這個(gè)性能。開源界也有其他的方案，比如Azul的Zing有個(gè)ReadyNow，IBM的J9有個(gè)AOT，也是做類似的事情。另外這里我放了一個(gè)Github的鏈接，這個(gè)agent能夠讓你在perf界面里直接看Java Method的開銷。

談到緩存，Cache里有一些小技巧，在做雙十一備戰(zhàn)時(shí)發(fā)現(xiàn)一個(gè)店鋪的基礎(chǔ)服務(wù)平時(shí)日常就每天有100億的調(diào)用量，當(dāng)時(shí)是幾十臺(tái)機(jī)器估了一下可能要成倍增長(zhǎng)，成本是非常高的，怎么解決這個(gè)問題，當(dāng)時(shí)寫了個(gè)富客戶端，讓業(yè)務(wù)方先去查我們分布式Cache，如果命中就直接返回來，如果不命中再走我們的服務(wù)端查。這種情況下，只要你能夠保證命中率足夠高，比如98%的命中率，就意味著只有2%是需要后端服務(wù)器承擔(dān)剩下的請(qǐng)求，用非常少的服務(wù)器去承擔(dān)非常大的流量，這是成本和性能間的權(quán)衡。

在緩存方面，我們很少會(huì)關(guān)心緩存的高可用是怎么部署的，它是一個(gè)偏運(yùn)維的內(nèi)容，我把緩存的部署簡(jiǎn)化成一個(gè)雙機(jī)房的模型，因?yàn)樗诟呖捎美锸亲詈?jiǎn)單的場(chǎng)景。對(duì)于緩存來說有兩種經(jīng)典部署模式，第一種叫共享集群部署，在IDC里我的應(yīng)用是分機(jī)房部署的，Cache集群也是分機(jī)房部署，對(duì)于應(yīng)用服務(wù)器來說，兩邊的Cache對(duì)他來說邏輯上是一個(gè)集群，會(huì)往IDC 1的Cache寫一半過去，往IDC 2也寫一半過去，這種部署的好處在于，機(jī)房間網(wǎng)絡(luò)斷掉的時(shí)候，有一半的數(shù)據(jù)是在緩存的，保證一半的數(shù)據(jù)能夠命中，不會(huì)直接死掉，另外對(duì)成本上相對(duì)比較友好，沒有浪費(fèi)任何一個(gè)Cache的節(jié)點(diǎn)，這個(gè)Cache本身是復(fù)用的。但是也正如剛才說的問題，如果中間斷掉了，有一半的命中率是有損的，所以就誕生了另外的一個(gè)部署模式，就是獨(dú)立部署，不管你哪個(gè)機(jī)房掛掉，命中率是基本不變的，兩邊同時(shí)保持了98%的命中率，但是它是成本不友好的，兩邊要同時(shí)部署，同時(shí)承擔(dān)副本的作用，并且失效時(shí)，要同時(shí)失效另外一個(gè)IDC 2，這樣才保證一致性。

在緩存上，我認(rèn)為一切東西都可以被緩存的，通常我們認(rèn)為緩存跟實(shí)際數(shù)據(jù)庫里存在的東西可能是不一樣的，有幾毫秒的延遲或者怎么樣，所以我們?cè)O(shè)計(jì)一個(gè)系統(tǒng)的時(shí)候，對(duì)一致性要求非常高的時(shí)候，會(huì)傾向于不用緩存，用數(shù)據(jù)庫扛這個(gè)流量。但以MySQL為例，InnoDB里有一個(gè)很重要的緩存Buffer Pool，對(duì)于一個(gè)數(shù)據(jù)庫，在冷庫的情況下用一堆SQL去查它，和慢慢預(yù)熱完再查它的時(shí)候效果是不一樣的，這個(gè)是我們當(dāng)初在做異地多活時(shí)面臨的一個(gè)問題，例如我已經(jīng)有一個(gè)機(jī)房，希望建立一個(gè)新單元去承擔(dān)這個(gè)機(jī)房的流量，當(dāng)我建完這個(gè)單元，把所有的應(yīng)用都部署好了后，把流量切50%過來會(huì)怎么樣，假設(shè)這兩個(gè)單元的機(jī)器數(shù)一樣，這個(gè)單元會(huì)掛，因?yàn)檫@個(gè)數(shù)據(jù)庫是冷的，緩存是空的，不能承擔(dān)之前那個(gè)單元數(shù)據(jù)庫所能承擔(dān)的QPS。

現(xiàn)在業(yè)界有很多叫API網(wǎng)關(guān)或者CDN，他們?cè)谶吘壒?jié)點(diǎn)也做了一層短暫的Cache，可能只Cache 50或者100毫秒，但是當(dāng)你系統(tǒng)受到攻擊的時(shí)候可以拯救你后端的應(yīng)用系統(tǒng)，攻擊引發(fā)的命中率通常比較高，有這50毫秒的緩存，可能后端只有幾百個(gè)QPS過來，那個(gè)流量你是可以承受的。

在高可用里兩個(gè)非常經(jīng)典的做法是限流和降級(jí)，在阿里雙11，有一位老兵說過一句話，他說當(dāng)雙11到來的時(shí)候，任何一個(gè)系統(tǒng)都可能出問題，你要做的是對(duì)你的上游限流，對(duì)你的下游限流。怎么理解，當(dāng)上流的流量超過你的能力的時(shí)候就要限流，當(dāng)下游比如DBA告訴你數(shù)據(jù)庫壓力很大了，那就對(duì)下游限流，只要保證住這個(gè)限流，你基本不會(huì)掛，每個(gè)系統(tǒng)都做到這個(gè)的時(shí)候，整個(gè)系統(tǒng)都是可用的。當(dāng)流量超出你掌控的時(shí)候，這個(gè)做法可以讓你成為這個(gè)暴風(fēng)下的幸存者。

對(duì)限流降級(jí)的思考，第一限流降級(jí)考驗(yàn)的是什么問題，我認(rèn)為本質(zhì)上考驗(yàn)的是故障自恢復(fù)能力，在平時(shí)工作中會(huì)遇到機(jī)房斷網(wǎng)或者停電，每半個(gè)月都會(huì)做斷網(wǎng)演練，不告訴你發(fā)生什么，就把這個(gè)網(wǎng)切斷，看你的應(yīng)用O不OK，一般是在晚上兩三點(diǎn)，接到很多的機(jī)房報(bào)警，這個(gè)時(shí)候看你的架構(gòu)設(shè)計(jì)的是否足夠可用，如果足夠可用就沒問題，不會(huì)造成什么影響，繼續(xù)睡覺，如果設(shè)計(jì)不好，就得爬起來立即處理。

而開關(guān)降級(jí)最大的作用，比如我們發(fā)現(xiàn)一些線上的問題，第一反映是趕緊回滾，但是當(dāng)你的系統(tǒng)很大的時(shí)候，特別像Java這種，一個(gè)系統(tǒng)啟動(dòng)要啟動(dòng)幾分鐘，你的回滾完成，20分鐘都過去了，這個(gè)過程對(duì)用戶來說都是有損的，而開關(guān)可以在一瞬間把所有的邏輯切到老的。這個(gè)是避免回滾時(shí)間導(dǎo)致的問題。開關(guān)有的時(shí)候能救命，如果沒有這個(gè)開關(guān)的話，避免問題放大就只能回滾，所以開關(guān)是一個(gè)很大的價(jià)值所在。

另外一點(diǎn)非常重要的是，在設(shè)計(jì)一個(gè)技術(shù)方案的時(shí)候，就會(huì)把容災(zāi)的設(shè)計(jì)融入到方案里。比如在設(shè)計(jì)技術(shù)方案的時(shí)候，在最后一章單獨(dú)有一個(gè)容災(zāi)設(shè)計(jì)，這個(gè)節(jié)點(diǎn)里任何服務(wù)掛掉的時(shí)候，你要保持什么樣的方式保持這個(gè)服務(wù)是可用的。

在容災(zāi)設(shè)計(jì)時(shí)有幾點(diǎn)必須考慮，比如我引了一個(gè)新jar包或者調(diào)了一個(gè)新的RPC的服務(wù)、引入了分布式的存儲(chǔ)，以前沒用過也不知道它穩(wěn)不穩(wěn)定，第一想法是它肯定會(huì)掛，它掛了我們?cè)趺醋觯覀儺?dāng)時(shí)在做前臺(tái)系統(tǒng)的異步化的時(shí)候，因?yàn)镽edis支持map的數(shù)據(jù)結(jié)構(gòu)，所以我們就是用Redis的hmget從這個(gè)map里拿出部分的key減少網(wǎng)卡的流量，但即使這個(gè)掛掉了，我們還會(huì)走老的Cache，只不過網(wǎng)卡流量會(huì)大一些，但是對(duì)用戶的服務(wù)是無損的，所以這里要考慮如果它掛了怎么做降級(jí)，有什么樣的恢復(fù)流程。

另外是發(fā)布計(jì)劃，在新系統(tǒng)上線時(shí)就會(huì)關(guān)注這些問題，比如這次有沒有做數(shù)據(jù)遷移，比如以前我是8個(gè)庫不夠用了我拆到16個(gè)庫或者32個(gè)庫，中間一定是有數(shù)據(jù)遷移的，涉及到數(shù)據(jù)遷移一定要有一套對(duì)賬系統(tǒng)保證這個(gè)數(shù)據(jù)是新數(shù)據(jù)和老數(shù)據(jù)是對(duì)得平的，不然一定有問題，因?yàn)槲覀兪亲鼋灰紫嚓P(guān)的，訂單、金額絕對(duì)不能出問題。

另外是你的發(fā)布順序是不是有依賴，如果出了問題的時(shí)候，誰要先回滾，這里是取決于技術(shù)設(shè)計(jì)。另外是否要通過客服公告的方式告訴外部用戶說有5分鐘的不可用，如果真的有用戶打電話有疑問客服同學(xué)可以向用戶解釋。

在高可用這個(gè)領(lǐng)域做久了會(huì)有一種直覺，這個(gè)直覺很重要，來源于你的經(jīng)驗(yàn)轉(zhuǎn)換成這種直覺，但是對(duì)于一個(gè)成熟的團(tuán)隊(duì)來說，需要把這種直覺轉(zhuǎn)化為產(chǎn)品或工具。有很多牛人他們的技能都只能叫手藝，你需要把這種手藝轉(zhuǎn)換成產(chǎn)品和工具。

2015年我去做云產(chǎn)品，這里給大家分享下我們是怎么樣幫客戶包括我們的系統(tǒng)在云上是做高可用的。

首先看兩個(gè)經(jīng)典故障案例，第一個(gè)是Gitlab生產(chǎn)數(shù)據(jù)庫刪了，它恢復(fù)了很久，Snapshot等全都沒有生效，做了五六層的備份也都沒有什么用。這個(gè)事情說明第一我們的故障要定期演練，比如中間件在做的線上故障演練，你說你的系統(tǒng)可用性好，我把這個(gè)主庫斷了，虛擬機(jī)掛掉幾臺(tái)試試，做這些演練就可以知道你這個(gè)容災(zāi)體系是不是可靠的，如果沒有這個(gè)演練的話，當(dāng)真正的故障發(fā)生時(shí)你才會(huì)發(fā)現(xiàn)這個(gè)東西是不OK的。

另外一個(gè)很典型的問題，Gitlab對(duì)備份的原理是不夠了解的，比如當(dāng)時(shí)用的PostgreSQL的一個(gè)版本，當(dāng)時(shí)是有問題的，沒有驗(yàn)證，開發(fā)人員對(duì)這個(gè)又不是特別了解的情況下就會(huì)出現(xiàn)這個(gè)問題，這就是為什么要去了解你的依賴以及你依賴的依賴。去年我們做壓測(cè)，有個(gè)應(yīng)用一邊壓測(cè)一邊在優(yōu)化做發(fā)布，發(fā)現(xiàn)第一批發(fā)的起不來了，就只是改了一兩行代碼加日志，他就去看什么原因，最后發(fā)現(xiàn)依賴的某個(gè)jar包依賴一個(gè)配置，而這個(gè)配置在壓測(cè)中被降級(jí)了，一個(gè)jar包就把應(yīng)用啟動(dòng)卡住了。如果在雙十一當(dāng)天或者在平時(shí)業(yè)務(wù)高峰期的時(shí)候發(fā)現(xiàn)這個(gè)問題是來不及修復(fù)的。所以這個(gè)時(shí)候，我們就要求，依賴的二方j(luò)ar包必須看一下里面是怎么實(shí)現(xiàn)的，依賴哪些東西。

反過來說，別人依賴我的客戶端就意味著他不僅依賴著我的服務(wù)還依賴著我的緩存，這個(gè)緩存出了問題對(duì)他也有影響，我們每年雙十一前有一個(gè)強(qiáng)弱依賴梳理，不僅要梳理自己應(yīng)用里面的，還有依賴的所有東西都梳理出來，中間任何一個(gè)節(jié)點(diǎn)掛掉了你應(yīng)該怎么辦，需要給一個(gè)明確答復(fù)。第二個(gè)故障案例是今年發(fā)生的，AWS S3敲錯(cuò)了一個(gè)命令把基礎(chǔ)核心服務(wù)下線了，有一個(gè)對(duì)象索引服務(wù)和位置服務(wù)系統(tǒng)被offline，后來也做了一些改進(jìn)，每次敲的命令有一個(gè)靜默期，讓你有個(gè)反悔的機(jī)會(huì)，線上有個(gè)最小的資源保證服務(wù)。

這個(gè)給我們帶來的啟示是什么，云服務(wù)本身也是會(huì)發(fā)生故障的，比如買了云數(shù)據(jù)庫，我們沒有辦法假設(shè)它是100%可用的，當(dāng)它出現(xiàn)問題我們?cè)趺崔k，是給云廠商提工單說什么時(shí)候能恢復(fù)，還是我自己能夠有一個(gè)容災(zāi)的方案解決這個(gè)問題。從2015年開始，我們?cè)絹碓蕉嗟匕l(fā)現(xiàn)，對(duì)架構(gòu)可用性最大的威脅是什么？在市政施工里一定幾率就會(huì)莫名其妙搞出光纜被挖斷等故障，我們不得不考慮，當(dāng)云服務(wù)本身出現(xiàn)問題我們?cè)撛趺崔k。

所以我們需要有一套面向云的高可用架構(gòu)。在很早以前有廠商提出類似SDN的一個(gè)概念，叫SDI——軟件定義基礎(chǔ)設(shè)施，過去我們發(fā)現(xiàn)只有大廠可以做這個(gè)事情，設(shè)計(jì)一套很復(fù)雜的管理系統(tǒng)幫他實(shí)現(xiàn)，這里放一個(gè)路由器，這邊放一臺(tái)虛擬機(jī)，可以通過軟件的控制流去控制這個(gè)東西。但是在云的時(shí)代，資源變得很容易獲得。以阿里云為例子，可以用API隨時(shí)創(chuàng)建新的虛擬機(jī)，新的負(fù)載均衡，或者是新的存儲(chǔ)，都可以通過API隨時(shí)創(chuàng)建隨時(shí)銷毀，這對(duì)于你的基礎(chǔ)設(shè)施的靈活度非常有好處。

以前有的人會(huì)覺得，性能問題或者容量問題應(yīng)該通過性能優(yōu)化的方式解決，通過一些黑科技方式解決，加機(jī)器會(huì)覺得很low。但我覺得一個(gè)問題如果能簡(jiǎn)單用加機(jī)器來解決是很不容易的，意味著對(duì)你的整個(gè)架構(gòu)的水平擴(kuò)展性要求非常高，而且解決效率很高，加機(jī)器就解決了，而對(duì)一些中心化的系統(tǒng)來說就比較麻煩，加機(jī)器都加不了，可能要把機(jī)器關(guān)掉升配置再重新拉起來。所以我們說，在公有云上面，在資源如此容易獲得的情況下要充分利用這個(gè)特性，要做一個(gè)能夠做水平擴(kuò)展的架構(gòu)。

那么第一步要做什么，前兩年很火的容器、微服務(wù)，本質(zhì)上都是解決了是無狀態(tài)的應(yīng)用怎么做自動(dòng)化的擴(kuò)容這個(gè)問題。右邊這個(gè)圖上面，上面是一個(gè)負(fù)載均衡，中間是一個(gè)前端的服務(wù)，后端是一個(gè)無狀態(tài)的后端服務(wù)，底層是MQ、對(duì)象存儲(chǔ)、數(shù)據(jù)庫這些東西，如果我們能夠把前端和后端的無狀態(tài)服務(wù)第一步先容器化，就可以做到當(dāng)流量過來的時(shí)候，只要后端的存儲(chǔ)沒有問題，整套架構(gòu)就是能夠水平擴(kuò)展的。

從去年公開的報(bào)道和故障來看，很多人有個(gè)誤會(huì)是說云廠商的機(jī)器應(yīng)該是不會(huì)掛的，我買了一臺(tái)云廠商的虛擬機(jī)應(yīng)該是隨時(shí)可用的，即使不可用云廠商也要幫我解決熱遷移的問題，熱遷移在業(yè)界是很復(fù)雜的問題，不光涉及到磁盤存儲(chǔ)的遷移，也涉及到內(nèi)存是要做遷移的，可能還要用RDMA。并且對(duì)于傳統(tǒng)的IDC來說，不管物理機(jī)還是虛擬機(jī)都是有可能掛的，對(duì)云也不例外。當(dāng)我們?cè)谑褂霉性品?wù)的時(shí)候，都是會(huì)掛的，這是個(gè)心理準(zhǔn)備。不光是機(jī)器，包括負(fù)載均衡是不是也有可能掛，下面的消息隊(duì)列或者數(shù)據(jù)庫是不是也有可能會(huì)掛，當(dāng)你基于任何東西都可能會(huì)掛的前提設(shè)計(jì)一個(gè)系統(tǒng)的時(shí)候，才能真正做到這個(gè)系統(tǒng)在任何情況下都不會(huì)受底層云服務(wù)的故障影響。

而對(duì)于不同的云服務(wù)來說是有不同的容災(zāi)策略。比如一臺(tái)虛擬機(jī)掛了，通常來說負(fù)載均衡不管是4層還是7層都會(huì)做健康檢查，掛了健康檢查不通自動(dòng)會(huì)把流量切斷。如果我的負(fù)載均衡掛了怎么辦，如果DNS有健康檢查那就方便了，如果沒有的話可能就要設(shè)計(jì)一個(gè)旁路系統(tǒng)解決這個(gè)問題，發(fā)現(xiàn)這個(gè)已經(jīng)不通了，就自動(dòng)把它從DNS上摘掉。

不管是云服務(wù)發(fā)生故障還是自己應(yīng)用發(fā)生故障有個(gè)大原則是如何最快速解決問題，就是一個(gè)字，切。為什么要做異地多活，為什么要把流量往各個(gè)地方引，切流量是解決問題最快的，把壞流量切到好的地方馬上就解決了，如果你要等定位問題解決問題再上線客戶就流失掉了。對(duì)淘寶來說也是一樣，當(dāng)某一個(gè)單元低于我們認(rèn)為的可用性的時(shí)候，我們會(huì)把這個(gè)單元的流量引到另外一個(gè)可用的單元，當(dāng)然前提是那個(gè)單元的容量是足夠的。

彈性是不是萬能的？所有的云服務(wù)都是彈性的，彈性其實(shí)不是萬能的，容量規(guī)劃仍然是有必要的，不然就沒必要做雙十一備戰(zhàn)了。這里有一個(gè)你需要付出的代價(jià)，彈性的過程往往是需要時(shí)間的，那么容量規(guī)劃在這個(gè)環(huán)節(jié)中起到的作用就很重要，當(dāng)真的逼不得已的時(shí)候，我要擴(kuò)容了，怎么保證我擴(kuò)完容之前系統(tǒng)不雪崩？就是要結(jié)合之前的限流，盡可能保障每個(gè)客戶得到他應(yīng)有的服務(wù)，但是也要保障系統(tǒng)的穩(wěn)定性。

Region和Availability Zone這兩個(gè)，當(dāng)實(shí)踐的時(shí)候，購買虛擬機(jī)、負(fù)載均衡或者數(shù)據(jù)庫，一定要選擇多可能區(qū)的服務(wù)，比如阿里云買SLB是可選可用區(qū)的，有個(gè)主可用區(qū)和副可用區(qū)，如果一邊掛了可以切換到另外一邊，RDS也是一樣的。

這幅圖是一套典型基于公有云的一套架構(gòu)，不叫異地多活，應(yīng)該叫跨區(qū)域設(shè)計(jì)。左右兩個(gè)大框是兩個(gè)城市，左邊是北京，右邊是上海，每個(gè)里面又有不同的機(jī)房可用區(qū)去承擔(dān)這個(gè)流量，假如北京的掛掉了，就切，原來是在A可用區(qū)，就切到B可用區(qū)，這時(shí)候A可用區(qū)沒有流量進(jìn)來，通過切換的方式能夠把這個(gè)服務(wù)快速恢復(fù)。下面畫了一個(gè)跨區(qū)域復(fù)制，我們?cè)诋惖囟嗷铐?xiàng)目里，涉及到了跨城市跨數(shù)據(jù)中心的復(fù)制，比如我的北京是提供寫服務(wù)的，上海要提供讀服務(wù)，就要通過這種方式同步數(shù)據(jù)過去。

最后，我們?cè)谡衅福幸恍┲就篮系男』锇椤Ｎ铱吹胶芏嗳俗稣衅福麄兌荚谡f我們想要什么樣的人，需要你具備什么樣的技能，我的想法可能不太一樣，我會(huì)先思考你到我們團(tuán)隊(duì)能得到什么，我能給你什么東西。那么第一可以參與到阿里最前線的作戰(zhàn)經(jīng)驗(yàn)，今年2017年雙十一大促可以跟我們一起做，第二我們團(tuán)隊(duì)內(nèi)部有非常好的氛圍，可以聽到來自阿里巴巴各領(lǐng)域的專家像魯肅、畢玄等大師的分享，第三可以飛速成長(zhǎng)，一對(duì)一師兄帶領(lǐng)，快速度過適應(yīng)期。新零售新技術(shù)，會(huì)創(chuàng)造出下一個(gè)時(shí)代的商業(yè)文明，對(duì)于技術(shù)人員來說我們不光有技術(shù)的思維，也要有業(yè)務(wù)和商業(yè)的思維來培養(yǎng)自己。

最后是我的郵箱，如果大家想交流可以發(fā)郵件給我：mujian.wcc@alibaba-inc.com