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

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

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

　　“4- 21”事故分析

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

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

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

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

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

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

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

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

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

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

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

　　在云環(huán)境中設(shè)計面向用戶的軟件時，主要工作是降低整體上響應(yīng)的延時。由于AWS是基于資源(硬件、網(wǎng)絡(luò)、存儲等)共享模式構(gòu)建的，共租會引起各個層次上吞吐量的波動?；蛘吣惴艞壢魏翁厥獾牟僮?，或者在AWS里管理好資源，這等于放棄了共租。

　　避免失敗的最好方法是不停地出錯

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

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

　　測試就要做真實情況的模擬，不能兒戲!

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

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

　　堅韌與信念，永不言棄

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

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

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

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

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

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

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

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

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

　　在這次事故中，他們沒有使用EBS。因為他們一直不放心EBS的性能和持久性，所以一直沒有使用它?；谕瑯拥脑?，他們也沒有使用RDS。

　　他們尚未達到100%的云計算。

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

　　分散到多個AZ。

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

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

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

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

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

　　系統(tǒng)組件化。

　　對組件進行測試。

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

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

　　將故障單元限定在單臺主機上。

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

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

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

　　寬松的一致性要求。

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

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

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

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

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

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

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

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

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

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

　　小結(jié)

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