云計(jì)算是一種新型的計(jì)算模式。其顯著優(yōu)勢(shì)之一是云計(jì)算用戶可以隨時(shí)隨地的使用來自互聯(lián)網(wǎng)的服務(wù)，并且按使用量付費(fèi)。在需要增加(或減少)計(jì)算能力時(shí)，可立即獲得(或釋放)資源，而在傳統(tǒng)數(shù)據(jù)中心(非私有云環(huán)境)中，用戶卻需要采購(gòu)硬件，安裝配置操作系統(tǒng)和中間件軟件，再部署應(yīng)用。兩種方式在運(yùn)維工作上的差異一目了然，這正是云計(jì)算能夠受到業(yè)界熱捧和追逐的主要原因之一。那么，云計(jì)算是完美無缺的么？不盡然如此。在云計(jì)算的世界里，運(yùn)維工作不再由云計(jì)算用戶承擔(dān)，轉(zhuǎn)而交給虛擬化和自動(dòng)化技術(shù)以及云計(jì)算提供商來承擔(dān)。

　　同時(shí)，云計(jì)算用戶在享受彈性資源擴(kuò)張或收縮的同時(shí)，也在一定程度上失去了對(duì)其使用資源的控制權(quán)，而如果云服務(wù)供應(yīng)商的服務(wù)出現(xiàn)故障，或者云服務(wù)供應(yīng)商由于商業(yè)運(yùn)作的失敗或其他原因而關(guān)門倒閉時(shí)，云計(jì)算用戶就可能會(huì)面臨巨大的風(fēng)險(xiǎn)。

　　2011年4月21日至22日是值得云計(jì)算從業(yè)者紀(jì)念的日子。Amazon的IaaS服務(wù)出現(xiàn)故障，導(dǎo)致許多商業(yè)網(wǎng)站的服務(wù)中斷，影響非常嚴(yán)重。據(jù)Amazon官方網(wǎng)站稱，受影響最嚴(yán)重的網(wǎng)站中有Reddit， Foursquare和Quora等。此事件發(fā)生后，人們一時(shí)陷入慌亂，對(duì)云計(jì)算可用性的擔(dān)心驟然升溫。同時(shí)，也有人乘機(jī)夸大云計(jì)算的弊端，并宣稱“云計(jì)算已死”(這讓筆者想起當(dāng)年關(guān)于“SOA已死”的論戰(zhàn))。炒作行為是可以理解的，我們自然不用去理會(huì)。但是，作為云計(jì)算用戶，我們需要思考的是，如何保證即便在云服務(wù)不可用的情況，我們的應(yīng)用架構(gòu)仍然能夠屹立不倒？本文正是站在云計(jì)算用戶的角度試圖探討這一問題。

　　“4- 21”事故分析

　　Amazon將其基礎(chǔ)設(shè)施劃分為“區(qū)域(Region)”，這些區(qū)域好比一個(gè)個(gè)數(shù)據(jù)中心。例如，US-East-1是Amazon位于北弗吉尼亞的數(shù)據(jù)中心，而US-West-1則是位于硅谷的數(shù)據(jù)中心。每個(gè)數(shù)據(jù)中心又被劃分成多個(gè)可用分區(qū)(后簡(jiǎn)稱為AZ)，AZ就好比資源池，它由一組物理和邏輯資源組成。

　　Amazon的提供的虛擬機(jī)是EC2(Elastic Compute Cloud)。而其存儲(chǔ)服務(wù)是EBS(Elastic Block Storage)。EBS是基于網(wǎng)絡(luò)高性能且高可用的塊(block)級(jí)別的持久化存儲(chǔ)服務(wù)。EBS可以掛接到某一個(gè)EC2實(shí)例上作為其文件系統(tǒng)使用。

　　當(dāng)用戶獲得一個(gè)EC2分區(qū)實(shí)例時(shí)，同時(shí)會(huì)得到一塊存儲(chǔ)區(qū)。不過，該存取區(qū)是透明的，而且其生存周期與EC2實(shí)例是同步的。當(dāng)EC2實(shí)例銷毀時(shí)，該存儲(chǔ)區(qū)也一同銷毀，基于此，需要持久化的用戶數(shù)據(jù)是不應(yīng)該放在該存儲(chǔ)上。

　　一般而言，運(yùn)行網(wǎng)站和產(chǎn)品的云計(jì)算用戶至少需要申請(qǐng)一個(gè)EC2實(shí)例和一個(gè)EBS存儲(chǔ)。在EC2上運(yùn)行應(yīng)用和數(shù)據(jù)庫(kù)，而數(shù)據(jù)則存儲(chǔ)在EBS中。但是，若要將EBS存儲(chǔ)掛接到EC2實(shí)例上，二者必須在同一AZ中(如圖1.a所示)。用戶也可以直接使用Amazon提供的RDS(Relational Database Service)，它是一個(gè)運(yùn)行著MySQL的EC2實(shí)例，此時(shí)應(yīng)用和數(shù)據(jù)就可分別位于不同的AZ中(如圖1.b所示)。當(dāng)然，將應(yīng)用和存儲(chǔ)分開還有其他方法，本文不再贅述。

　　“4-21”事故中，位于US-East-1區(qū)域的EBS存儲(chǔ)和Amazon RDS服務(wù)都出現(xiàn)了問題。表現(xiàn)出來的現(xiàn)象是：不在US-East-1區(qū)域的用戶未受影響，未使用EBS和RDS的用戶不受影響。一般情況下，使用EBS或RDS是非常普遍的現(xiàn)象，因?yàn)榇蠖鄶?shù)軟件或網(wǎng)站都依賴于數(shù)據(jù)存儲(chǔ)，所以，即便運(yùn)行應(yīng)用的EC2未受影響，也會(huì)由于應(yīng)用需要訪問已出現(xiàn)問題的ESB或RDS上的數(shù)據(jù)，仍然會(huì)導(dǎo)致服務(wù)不可用或服務(wù)變慢的問題。

　　Amazon事故的的發(fā)生加速了人們對(duì)云可用性的思考，也進(jìn)一步凸顯了好的應(yīng)用架構(gòu)的優(yōu)勢(shì)，多家企業(yè)紛紛通過博客分享了他們使用Amaozon AWS的經(jīng)驗(yàn)，對(duì)云計(jì)算用戶端架構(gòu)的建議。接下來，我們看看他們是怎么做的。

　　來自一線的經(jīng)驗(yàn)

　　早在2010年12月，在線影片租賃提供商N(yùn)etFlix的技術(shù)博客上就發(fā)表了文章《使用AWS的5大經(jīng)驗(yàn)》。在這篇文章中，他們給出了以下5條建議：

　　云環(huán)境和傳統(tǒng)數(shù)據(jù)中心不同，需改變思考問題的方法

　　許多傳統(tǒng)數(shù)據(jù)中心的應(yīng)用部署和運(yùn)維經(jīng)驗(yàn)在云中不再適用，所以不能用傳統(tǒng)的解決方法去解決云中出現(xiàn)的問題。比如，在自己的數(shù)據(jù)中心里，使用基于內(nèi)存的session管理就是很好的方法，因?yàn)槊總€(gè)硬件實(shí)例出現(xiàn)故障的可能性微乎其微。然而，AWS實(shí)例的出錯(cuò)率卻高很多，所以需要不同高可用方案。

　　共租是難以實(shí)現(xiàn)的

　　在云環(huán)境中設(shè)計(jì)面向用戶的軟件時(shí)，主要工作是降低整體上響應(yīng)的延時(shí)。由于AWS是基于資源(硬件、網(wǎng)絡(luò)、存儲(chǔ)等)共享模式構(gòu)建的，共租會(huì)引起各個(gè)層次上吞吐量的波動(dòng)。或者你放棄任何特殊的操作，或者在AWS里管理好資源，這等于放棄了共租。

　　避免失敗的最好方法是不停地出錯(cuò)

　　Netflix的技術(shù)人員喜歡將自己的軟件架構(gòu)稱之為蘭博架構(gòu)，不論在何種情況下，每個(gè)系統(tǒng)必須靠自己存活。他們?cè)谠O(shè)計(jì)分布式系統(tǒng)時(shí)考慮了其所依賴的其他系統(tǒng)的故障并且能夠容忍故障。

　　他們?cè)贏WS中創(chuàng)建了一個(gè)被稱為“搗亂猴”的系統(tǒng)。該“搗亂猴”的任務(wù)就是隨意殺死軟件架構(gòu)中的任意實(shí)例和服務(wù)。他們的原則是，即便局部出錯(cuò)了，他們的系統(tǒng)和架構(gòu)仍然要整體上保持正確，只有這樣，才能躲過預(yù)料之外的故障。

　　測(cè)試就要做真實(shí)情況的模擬，不能兒戲!

　　在完全依靠AWS之前，他們就使用真實(shí)數(shù)據(jù)對(duì)AWS上的系統(tǒng)做測(cè)試。他們模擬所有發(fā)往數(shù)據(jù)中心的請(qǐng)求，然后發(fā)送到AWS做實(shí)測(cè)。

　　測(cè)試能夠發(fā)現(xiàn)架構(gòu)的瓶頸，有些架構(gòu)決定和設(shè)計(jì)決定，在圖紙上看似完美，但是一旦應(yīng)用到大規(guī)模的實(shí)際情形，就不那么奏效了。

　　堅(jiān)韌與信念，永不言棄

　　你會(huì)碰到許多問題!畢竟云計(jì)算的發(fā)展也沒有幾年，許多方面仍在不斷完善之中。用戶需要改變過去的觀念，放棄過去的固定模式。關(guān)鍵是要保持堅(jiān)忍不拔地戰(zhàn)勝一切困難的意志力，堅(jiān)定對(duì)勝利的信念。

　　Coding Horror博主Jeff Atwood非常贊同“搗亂猴”的思路。他在博文中分享了他的團(tuán)隊(duì)花好幾個(gè)月解決一個(gè)詭異問題的經(jīng)歷。為了跟蹤該問題，他們分析和嘗試了可能導(dǎo)致該問題的所有原因，但是仍然未找到其根本原因。每隔幾天，就會(huì)有服務(wù)器(不知道是那臺(tái))從網(wǎng)絡(luò)中脫離，他們稱此現(xiàn)象為“搗亂猴”又發(fā)怒了。他們被此問題困擾數(shù)月之久，團(tuán)隊(duì)曾陷入崩潰，但是即便在最困難的時(shí)期，他們?nèi)匀徊扇×朔e極的行動(dòng)：

　　但凡某關(guān)鍵功能現(xiàn)在由一臺(tái)服務(wù)器負(fù)責(zé)，就切換成兩臺(tái)。

　　但凡發(fā)現(xiàn)哪里缺乏可靠性，就建立其可靠性。

　　消除所有的依賴，一步一步，直到依賴減到不能再少。

　　設(shè)計(jì)替代方案，使我們的服務(wù)始終保持運(yùn)行，即便我們先前認(rèn)為關(guān)鍵的服務(wù)突然失效。

　　SmugMug也分享了他們的經(jīng)驗(yàn)，他們網(wǎng)站未受影響的原因在于以下四點(diǎn)：

　　部署在AWS中的服務(wù)分布在多個(gè)AZ中。所以，一個(gè)AZ出問題，就可以切換到另一個(gè)AZ。

　　其架構(gòu)從設(shè)計(jì)之初就考慮了故障。他們的每個(gè)實(shí)例，或一個(gè)AZ中的任意一組實(shí)例，可以瞬間倒下，系統(tǒng)會(huì)很快恢復(fù)。

　　在這次事故中，他們沒有使用EBS。因?yàn)樗麄円恢辈环判腅BS的性能和持久性，所以一直沒有使用它。基于同樣的原因，他們也沒有使用RDS。

　　他們尚未達(dá)到100%的云計(jì)算。

　　此外，對(duì)于100%純度的云應(yīng)用，作者給出以下建議：

　　分散到多個(gè)AZ。

　　分散到多個(gè)區(qū)域(Region)。

　　分散到多個(gè)云計(jì)算供應(yīng)商。

　　意識(shí)到分散帶來的附加工作和復(fù)雜度，始終保持清醒認(rèn)識(shí)。

　　從架構(gòu)上考慮故障。

　　熟知應(yīng)用的哪些地方可能會(huì)出現(xiàn)故障。

　　系統(tǒng)組件化。

　　對(duì)組件進(jìn)行測(cè)試。

　　保持放松的心態(tài)——故障是常有的事情，泰然處之。

　　Twilio也針對(duì)AWS給出了自己的云架構(gòu)原則，如下：

　　將故障單元限定在單臺(tái)主機(jī)上。

　　設(shè)定較短超時(shí)時(shí)間，快速重試。

　　保持服務(wù)接口的冪等性。

　　服務(wù)細(xì)粒度，無狀態(tài)。

　　寬松的一致性要求。

　　云端應(yīng)用架構(gòu)設(shè)計(jì)的建議

　　結(jié)合上文對(duì)Amazon事件的分析以及眾多來自一線工作人員的經(jīng)驗(yàn)和分享。我們不難看出，對(duì)于云計(jì)算用戶來說，單純地祈禱云計(jì)算供應(yīng)商提供100%可靠的云服務(wù)不是解決問題的根本所在。相反，云計(jì)算用戶應(yīng)該從其應(yīng)用和架構(gòu)本身尋找解決問題的根本方法。簡(jiǎn)單總結(jié)如下：

　　充分理解云計(jì)算供應(yīng)商的服務(wù)可用性，在條件允許的情況下準(zhǔn)備相應(yīng)的對(duì)策。

　　以AWS服務(wù)為例，若用戶對(duì)Amazon的EC2，EBS，RDS等服務(wù)的可用性及其依賴關(guān)系有充分的了解，就可以根據(jù)自己的實(shí)際需要為自己的服務(wù)架構(gòu)不同級(jí)別的可用性。在多個(gè)區(qū)域(Region)，AZ(可用分區(qū))，和EC2上分別實(shí)施的高可用方案的可用性級(jí)別是不同的，在不同區(qū)域上建立的高可用方案的可用性級(jí)別最高，基于AZ的次之，EC2上的最低。但是，高可用性越高，其復(fù)雜度和成本越高，反之亦然。用戶可根據(jù)不同的業(yè)務(wù)需求為系統(tǒng)中的不同功能提供不同級(jí)別的高可用性方案。

　　在架構(gòu)設(shè)計(jì)中考慮故障的可能性。

　　不論在傳統(tǒng)的數(shù)據(jù)中心還是在云環(huán)境中，設(shè)計(jì)軟件架構(gòu)師都需要考慮到故障。不同的是，傳統(tǒng)方式下，從軟件到硬件，架構(gòu)師都是可控的，而在云計(jì)算環(huán)境中，使用的云中服務(wù)確實(shí)是不可控的。這就需要在做架構(gòu)設(shè)計(jì)，或采用云服務(wù)時(shí)，充分了解云服務(wù)的可用性，并將此知識(shí)作為架構(gòu)設(shè)計(jì)的輸入之一。

　　應(yīng)用系統(tǒng)的組件化和服務(wù)化。

　　使用SOA架構(gòu)方法構(gòu)建應(yīng)用系統(tǒng)，將應(yīng)用功能劃分成細(xì)粒度、無狀態(tài)的組件，并將組件封裝成服務(wù)，將同一服務(wù)的不同實(shí)例分散到多個(gè)實(shí)例中運(yùn)行，從而提高服務(wù)整體的可用性。

　　在條件允許的情況下，使用多個(gè)云服務(wù)提供商。

　　在云計(jì)算標(biāo)準(zhǔn)尚未成熟的大環(huán)境下，實(shí)現(xiàn)這一理想是困難的。但是，隨著云計(jì)算標(biāo)準(zhǔn)逐漸成熟，在設(shè)計(jì)云端應(yīng)用軟件的架構(gòu)時(shí)，就可考慮在多個(gè)云服務(wù)供應(yīng)商之間實(shí)現(xiàn)高可用性，但是就目前而言，由于各個(gè)云計(jì)算供應(yīng)商的服務(wù)的功能和接口缺乏一致性和標(biāo)準(zhǔn)型，完成可用性的設(shè)計(jì)和實(shí)現(xiàn)是需要付出代價(jià)的。路漫漫其修遠(yuǎn)兮，但希望總在前方。

　　小結(jié)

　　云計(jì)算是當(dāng)前的Bizzword，但是我們需要清楚的認(rèn)識(shí)，和當(dāng)年的SOA一樣，云計(jì)算也不是銀彈，不能解決所有問題。它的好處多，壞處也不少(除了本文提到的可用性不可控之外，還有許多不好的地方，如數(shù)據(jù)的安全性、云端應(yīng)用整合的復(fù)雜性等)，只有清楚地地認(rèn)識(shí)它，還能更好地避開其劣勢(shì)，發(fā)揚(yáng)其優(yōu)勢(shì)。本文結(jié)合Amazon“4-21”事故，談到了如何從架構(gòu)的角度思考云端應(yīng)用，解決因所使用云服務(wù)的可用性問題導(dǎo)致云端應(yīng)用不可用的問題，以期即享受云計(jì)算帶來彈性擴(kuò)展、自動(dòng)供應(yīng)等優(yōu)勢(shì)，又避免因云服務(wù)不可用而導(dǎo)致的用戶體驗(yàn)的下降。希望能給讀者帶來一些參考，也歡迎讀者給出批評(píng)建議。