鏈接：http://www.365master.com/netdata/newtech/tech/20080918/37192.shtml???? 來源：IT168 作者： 發布時間：2008-09-18
不久前，Amazon網絡服務大規模的癱瘓事件招來了客戶的大量批評和否定。緊接著，作為世界上最大托管存儲商的Rackspace也出現了與Amazon 類似的情況，同樣惹得怨聲載道。由于這兩家的規模龐大，因此影響面甚廣；又由于兩者都采用了云計算的架構，所以人們在抱怨商家服務的同時，不禁懷疑起云計算的可靠性來。
然而，正如任何系統一樣，沒有什么是完美的。當系統故障發生，沮喪的我們應該認識到這是生活的一部分。任何復雜如Amazon網絡服務的系統，沒有人能保證不會發生一點問題。正因為如此，單一、偶然發生的故障問題并不能衡量服務的質量。
那么，云計算真的就不好么？事實當然并非如此，相反，它具有強大的生命力以及美好的前景。
"云"與LAMP
網絡服務起源于L.A.M.P的組合（linux、Apache、MySQL、Perl），直至今日依然強大有效，因此仍是許多流行網站的選擇。LAMP 貴在簡潔之美，這使得上手非常容易。但它卻存在擴展性差的問題：其一為Apache網站服務器的線程與scoket的連接少，因此當面臨負載增加又未合理配置的情況時，網站的運轉就有可能出現故障；其二就是MySQL的關系型數據庫規模有限，因此成了整個系統最大的瓶頸，這個問題尤為突出。
關系型數據庫因為信息表征方式導致了容量的受限。并且，當達到一定規模時，管理還會變得困難。右下圖明顯可見，單一的關系型數據庫與網絡服務器間存在著明顯的性能瓶頸以及單點失效的風險。為解決這一問題，一種名為數據分區的技術可以使關系型數據庫的數據劃分到N個獨立集中去。如果這樣行不通的話，唯一的方法就是放棄關系型數據庫，改用分布式數據庫，而這恰恰就進入了"云"的范疇。
云計算的概念
云計算的想法并不難理解，就是要將應用程序分散布置在由眾多硬件盒組成的一個大型網格中。每個盒子內部系統相同，且規格均一。起平衡整個系統負載作用的負載均衡器發出的指令可以在各個盒間流水般無阻礙的通行，因此看似分散的盒子能運作如一體，迅速做出反應，宛如分散的小水滴在大氣壓作用下凝聚成一體終成浮動的白云，這就是"云"的概念。"云"之美還在于它的擴展性，你可以很容易地向"云"中添加更多的盒子。
在上圖中可以看出，計算云包括了三個最基本的組分：一個網站服務/應用層，一個分布式存儲層，以及一個分布式隊列層。每一個層都可作為"云"本身，也就是說層的每一組分在功能和結構上完全一致。在這最簡單的模型中，web tier就當于LAMP中的bit概念，在"云"中，網絡服務器同樣可以采用Apache，同樣可以運行應用程序的PHP代碼，但與LAMP根本不同的是數據庫不再是MySQL，而采用了分布式存儲系統系統，如Amazon S3, Amazon SimpleDB或Amazon Dynamo。分布式隊列層除了在無法實時操作的情況下需要外，并不是必須的。
"云"最大的優勢是它支持按需變化的運算商務模式。比如說，一個建立在"云"上的能支持1,000~10,000位客戶的網絡服務如果需要將客戶容量提高到10,000,000，那么僅僅只需向"云"中添加盒子的數量。從商業前景來說，這是非常具有吸引力的，因為采用"云"之后很容易計算出系統擴展所需要的成本。
云計算的現狀
"云"計算最好的例子無疑是Google。這個網絡世界的巨頭搭建和控制了數以百計、千計甚至于百萬計的硬件盒，構成了一朵龐大的"云"。但為了應對不斷增長的網絡用戶的服務請求，Google還在一刻不停地擴展著"云"的規模。
當然，Google并不是唯一的實踐者，而是幾乎所有大型的網站包括Amazon, eBay, Yahoo! 和Facebook都采用了各種形式的云計算。尤其是Amazon，憑借著它在分布式計算領域的領先地位，在過去的15年一直完善著這項技術，所以不難理解它要將未來的賭注壓在垂直網站服務上。他們相信未來屬于云計算，掌握了云計算的核心就掌握了生財之道，這一點上沒人比他們做的更好。
云計算的可靠性
對于Amazon的服務崩潰，也許有業內人士會想：如果換成是我做的話，我一定能做的更好。這種設想一直存在于軟件業的發展史中，如計算機語言種類的重復發明、API不斷地推翻重寫，我們總認為比前人更聰明、更富有創新性，但99.9%的事實證明我們是錯的。所以說這次錯不在于Amazon，在我們之前，他們已經投入了巨大的財力和人力來試圖解決這些問題。大規模的運算服務是一個異常復雜和龐大的問題，即使對最具智慧和前途的工程師來說，也需花費數年來弄懂和解決它。
就目前來說，搭建云計算平臺可以通過獨立設計和技術購買兩種手段來實現。除非特定云計算結構需要獨立設計外，大部分情況下，采用Amazon網絡服務的云計算結構能滿足需要。如果要擊敗對手，必須要明白和突出自己的產品的獨特性，否則走重新設計的路線，你會發現你已失去時間和資源。
也許Amazon服務崩潰不僅僅是"云"的問題，是否還應該考慮一下SLA(Service Level Agreements，服務品質協議)？明明SLA上保證的是99.99%的網絡服務可用率，可當服務使用3小時后就陷于癱瘓的情況該如何解釋呢？我們應該知道，無論SLA上怎樣的承諾，它不可能保證電力供應系統和"云"結構的完美無瑕地運作。
所以我們不能盲目相信SLA，而是要動用自己的大腦。評價一個系統性能的穩定性不是看它是否會崩潰，而是預測它出現崩潰現象的頻率。如果Amazon的網絡服務一年內只有3小時的停工期，那么可以認為是完美無缺的；如果是每個月，那么就是不可接受的；如果是每天，那將是令人抓狂的。
未來的發展
Amazon事件不會影響它的網絡服務計劃，更不會阻礙云計算發展的步伐。Amazon一直是云計算的先行者，它建立的大規模平行網站式計算服務正為世界上越來越多的人所接受。我們有理由相信這僅僅只是云計算的開始，它正在從根本上改變著人類運算的方式。
云計算解決了擴展性的問題，供應商們就能把精力集中到自己產品和服務中去。隨著硬件成本、帶寬和服務費用不斷降低，云計算不再縹緲，而是觸手可得，人類將乘著云計算來到了另一個天空。