云計算是一種新型的計算模式。其顯著優(yōu)勢之一是云計算用戶可以隨時隨地的使用來自互聯(lián)網(wǎng)的服務，并且按使用量付費。在需要增加（或減少）計算能力時，可立即獲得（或釋放）資源，而在傳統(tǒng)數(shù)據(jù)中心（非私有云環(huán)境）中，用戶卻需要采購硬件，安裝配置操作系統(tǒng)和中間件軟件，再部署應用。兩種方式在運維工作上的差異一目了然，這正是云計算能夠受到業(yè)界熱捧和追逐的主要原因之一。那么，云計算是完美無缺的么？不盡然如此。在云計算的世界里，運維工作不再由云計算用戶承擔，轉而交給虛擬化和自動化技術以及云計算提供商來承擔。同時，云計算用戶在享受彈性資源擴張或收縮的同時，也在一定程度上失去了對其使用資源的控制權，而如果云服務供應商的服務出現(xiàn)故障，或者云服務供應商由于商業(yè)運作的失敗或其他原因而關門倒閉時，云計算用戶就可能會面臨巨大的風險。

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

“4- 21”事故分析

Amazon將其基礎設施劃分為“區(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）。而其存儲服務是EBS（Elastic Block Storage）。EBS是基于網(wǎng)絡高性能且高可用的塊（block）級別的持久化存儲服務。EBS可以掛接到某一個EC2實例上作為其文件系統(tǒng)使用。

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

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

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

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