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

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

　　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的經驗，對云計算用戶端架構的建議。接下來，我們看看他們是怎么做的。

　　來自一線的經驗

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

　　云環境和傳統數據中心不同，需改變思考問題的方法

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

　　共租是難以實現的

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

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

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

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

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

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

　　測試能夠發現架構的瓶頸，有些架構決定和設計決定，在圖紙上看似完美，但是一旦應用到大規模的實際情形，就不那么奏效了。

　　堅韌與信念，永不言棄

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

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

　　但凡某關鍵功能現在由一臺服務器負責，就切換成兩臺。

　　但凡發現哪里缺乏可靠性，就建立其可靠性。

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

　　設計替代方案，使我們的服務始終保持運行，即便我們先前認為關鍵的服務突然失效。

　　SmugMug也分享了他們的經驗，他們網站未受影響的原因在于以下四點：

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

　　其架構從設計之初就考慮了故障。他們的每個實例，或一個AZ中的任意一組實例，可以瞬間倒下，系統會很快恢復。

　　在這次事故中，他們沒有使用EBS。因為他們一直不放心EBS的性能和持久性，所以一直沒有使用它。基于同樣的原因，他們也沒有使用RDS。

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

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

　　分散到多個AZ。

　　分散到多個區域(Region)。

　　分散到多個云計算供應商。

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

　　從架構上考慮故障。

　　熟知應用的哪些地方可能會出現故障。

　　系統組件化。

　　對組件進行測試。

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

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

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

　　設定較短超時時間，快速重試。

　　保持服務接口的冪等性。

　　服務細粒度，無狀態。

　　寬松的一致性要求。

　　云端應用架構設計的建議

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

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

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

　　在架構設計中考慮故障的可能性。

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

　　應用系統的組件化和服務化。

　　使用SOA架構方法構建應用系統，將應用功能劃分成細粒度、無狀態的組件，并將組件封裝成服務，將同一服務的不同實例分散到多個實例中運行，從而提高服務整體的可用性。

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

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

　　小結

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