雲端應用架構高可用：雲計算＂傷得起＂？

雲計算是一種新型的計算模式。 其顯著優勢之一是雲計算使用者可以隨時隨地的使用來自互聯網的服務，並且按使用量付費。 在需要增加(或減少)計算能力時，可立即獲得(或釋放)資源，而在傳統資料中心(非私有雲環境)中，使用者卻需要採購硬體，安裝配置作業系統和中介軟體軟體，再部署應用。 兩種方式在運維工作上的差異一目了然，這正是雲計算能夠受到業界熱捧和追逐的主要原因之一。 那麼，雲計算是無瑕疵地的麼?不儘然如此。 在雲計算的世界裡，運維工作不再由雲計算使用者承擔，轉而交給虛擬化和自動化技術以及雲計算供應商來承擔。 同時，雲計算使用者在享受彈性資源擴張或收縮的同時，也在一定程度上失去了對其使用資源的控制權，而如果雲服務供應商的服務出現故障，或者雲服務供應商由於商業運作的失敗或其他原因而關門倒閉時，雲計算使用者就可能會面臨巨大的風險。

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

「4- 21」事故分析

Amazon將其基礎設施劃分為「區域(Region)」，這些區域好比一個個資料中心。 例如，US-East-1是Amazon位於北佛吉尼亞的資料中心，而US-West-1則是位於矽谷的資料中心。 每個資料中心又被劃分成多個可用分區(後簡稱為AZ)，AZ就好比資源池，它由一組物理和邏輯資源組成。

Amazon的提供的虛擬機器是EC2(Elastic Compute Cloud)。 而其存儲服務是EBS(Elastic Block Storage)。 EBS是基於網路高性能且高可用的塊(block)級別的持久化存儲服務。 EBS可以掛接到某一個EC2實例上作為其檔案系統使用。

當使用者獲得一個EC2分區實例時，同時會得到一塊存儲區。 不過，該存取區是透明的，而且其生存週期與EC2實例是同步的。 當EC2實例銷毀時，該存儲區也一同銷毀，基於此，需要持久化的使用者資料是不應該放在該存儲上。

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

「4-21」事故中，位於US-East-1區域的EBS存儲和Amazon RDS服務都出現了問題。 表現出來的現象是：不在US-East-1區域的使用者未受影響，未使用EBS和RDS的使用者不受影響。 一般情況下，使用EBS或RDS是非常普遍的現象，因為大多數軟體或網站都依賴于資料存儲，所以，即便運行應用的EC2未受影響，也會由於應用需要訪問已出現問題的ESB或RDS上的資料，仍然會導致服務不可用或服務變慢的問題。

Amazon事故的的發生加速了人們對雲可用性的思考，也進一步凸顯了好的應用架構的優勢，多家企業紛紛通過博客分享了他們使用Amaozon AWS的經驗，對雲計算使用者端架構的建議。 接下來，我們看看他們是怎麼做的。

(責任編輯：蒙遺善)