“云計算”不等于“托管2.0”

2010-04-28 14:38:26

云計算 我們要架構(gòu)云應(yīng)用程序，但不能讓它變成空中樓閣。如果你采用“托管 2.0”的方式處理云計算，就會造成很嚴(yán)重的后果，不信請看：

在名山等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計 網(wǎng)站設(shè)計制作按需定制,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),成都全網(wǎng)營銷,外貿(mào)網(wǎng)站建設(shè),名山網(wǎng)站建設(shè)費用合理。

我們要架構(gòu)云應(yīng)用程序，但不能讓它變成空中樓閣。如果你采用“托管 2.0”的方式處理云計算，就會造成很嚴(yán)重的后果，不信請看下文分析?！　?/p>

HyperStratus咨詢公司最近處理了幾個相似的案例：企業(yè)部署在亞馬遜云計算基礎(chǔ)上的應(yīng)用出現(xiàn)了一些問題。

問題一：應(yīng)用程序能夠安裝于各系統(tǒng)分類總列表中，并且運行良好，但是如果亞馬遜的彈性云(Elastic Compute Cloud，EC2)實例崩潰或是需要中止程序，該應(yīng)用程序就會停止運行，直到新版的實例投入運行后才恢復(fù)。

問題二：在EC2實例超載的情況下，不能通過添加更多資源來改善應(yīng)用程序的性能。

問題三：目前只有在完全脫機的狀態(tài)下才能夠?qū)?yīng)用程序進(jìn)行升級。

問題四：性能會在數(shù)據(jù)庫方面遇到瓶頸，但不能通過任何便于管理的方式進(jìn)行數(shù)據(jù)庫的復(fù)制。

云計算安裝過程中可能遇到的問題

在與這些客戶溝通的過程中，HyperStratus遇到了一個相同的問題：“云計算具有靈活性、可用性?？蓴U展性等優(yōu)勢，怎么就解決不了這個問題？為什么應(yīng)用程序會出現(xiàn)這么多問題？”

問題的根源在于，他們把云計算當(dāng)做了“托管2.0”，因此吃到了苦頭。

簡單的說，云計算的擴展性與應(yīng)用程序的擴展性是不同的，除非你架構(gòu)了云應(yīng)用程序，否則不可能享有云計算所帶來的好處。HyperStratus的觀點是“要構(gòu)建云應(yīng)用程序，但不能讓程序成為空中樓閣。”

那么“構(gòu)建云應(yīng)用程序”究竟是什么意思，云與托管2.0究竟有什么不同？從下面這些架構(gòu)云應(yīng)用的關(guān)鍵原則中獲悉可以找到答案。

要知道到個人計算資源發(fā)生什么事情都是可能的。在亞馬遜的云計算中，某一個EC2實例偶爾會出現(xiàn)性能不佳、停止響應(yīng)甚至崩潰。資源也會出現(xiàn)一定規(guī)模的故障。所有云供應(yīng)商都面臨著這個問題。Google因為它們超低成本的服務(wù)器理論而出名，在主板上直接連硬盤驅(qū)動器，并且沒有金屬外殼(Google的機器可以稱之為裸身機器)；當(dāng)一臺機器當(dāng)機了，Google將其遷移到另外一臺機器上，并且再次做一個備份。因為有著成千上萬臺服務(wù)器在運行，失敗是在所難免得，所以google的架構(gòu)的解決方案時直面失敗，在失敗的時候以更強勁的資源應(yīng)對。同樣的，應(yīng)當(dāng)把個人應(yīng)用程序運行在云環(huán)境中，因為個人的電腦資源更容易出現(xiàn)問題。所以應(yīng)用程序必須能夠?qū)崿F(xiàn)在兩個以上EC2實例中運行。

應(yīng)用程序能夠在兩個以上EC2實例中運行，因此就存在一些潛在的危險。應(yīng)用程序可能在多個虛擬機之間進(jìn)行替換，或是設(shè)置在兩臺計算機都能夠進(jìn)入的共享區(qū)域。這不是說每個應(yīng)用程序必須被分隔在它們自帶的實例中，單一的EC2實例可以支持多個應(yīng)用程序；比如說，在一個單一的實例下可以運行多個不同網(wǎng)站。這確實意味著每個應(yīng)用程序必須經(jīng)過編寫才能跨越多個實例。

應(yīng)用程序要根據(jù)云計算環(huán)境針對性編寫。這既意味著類同性會話將通過應(yīng)用程序之前的負(fù)載均衡器進(jìn)行管理，也意味著該應(yīng)用程序?qū)⑵渥陨淼臅捫畔⒈Ａ粼谝粋€共享區(qū)域內(nèi)。這一點可以通過將會話信息保留在由應(yīng)用程序服務(wù)器共享的元數(shù)據(jù)服務(wù)器內(nèi)來實現(xiàn)，盡管最終這種方法可能會在裝載元數(shù)據(jù)服務(wù)器的過程中遭遇瓶頸。最普遍的解決方法就是將會話信息轉(zhuǎn)移到性能更加完備的會話分層處理器中。無論如何，會話信息必須要以某種方式滿足應(yīng)用程序所需要的每個部分。

要確保計算資源具有可擴展性。用戶選擇使用云的一個主要原因是，它能夠使應(yīng)用程序動態(tài)獲取他們想要的資源，根據(jù)裝載情況改變資源數(shù)量。如果需要人為干擾來增加或減少資源，障礙物就會從計算資源轉(zhuǎn)化至人類資源，這其實并不是理想狀態(tài)。如果不編寫應(yīng)用程序，資源等級就不能進(jìn)行動態(tài)變化，這時操作員就必須要指派一個固定的資源等級；最終又會回到原有狀態(tài)，在實用性和投資之間反復(fù)權(quán)衡，也就是說，我應(yīng)該犧牲掉經(jīng)濟利益還是失掉一部分客戶群？

這些并不是想要阻止人們向“云應(yīng)用程序”邁進(jìn)的腳步。編寫應(yīng)用程序以實現(xiàn)其無需人類介入狀態(tài)下的動態(tài)縮放并不是微不足道的小事。首先，大多數(shù)軟件組件都會假定有人工操作，而不是自動的，你對它進(jìn)行管理，隨后出現(xiàn)一種“升級配置文件并重新啟動服務(wù)器”的解決方案。這十分適合那些極端靜態(tài)的應(yīng)用程序拓?fù)浣Y(jié)構(gòu)，但卻是動態(tài)轉(zhuǎn)換應(yīng)用程序拓?fù)浣Y(jié)構(gòu)的噩夢。

另一個問題就是需要決定如何處理一個應(yīng)用程序中多版本復(fù)制所共享的文檔和物體。它們可以放置在網(wǎng)頁文件系統(tǒng)中，但是性能仍然是個大問題。對于在功能上支持SAN或是NAS的云環(huán)境而言，文件可以定位在中心區(qū)域，盡管這可能會強制增加一些潛在的危險。文檔的復(fù)制版可以放在每個服務(wù)器內(nèi)，盡管這可能會在分配和版本控制方面遇到一些挑戰(zhàn)。最佳的方案就是將所有的文檔全部放置在中心區(qū)域內(nèi)(比如說，放在以Amazon為載體的應(yīng)用程序S3中)，并在所有虛擬計算機內(nèi)下載“官方”文件，讓它們在實例化的過程中自行完成安裝。這也有點超出常規(guī)，一些非動態(tài)環(huán)境很少會用到這樣的操作。在大多數(shù)環(huán)境下的常見方案就是將重點放在硬件(和虛擬計算機)的加固上，并沒有針對動態(tài)應(yīng)用程序拓?fù)浣Y(jié)構(gòu)制定什么計劃。

目前還沒有確切的數(shù)字可以表明到底會有百分之幾的應(yīng)用程序需要進(jìn)行動態(tài)拓?fù)浣Y(jié)構(gòu)的裝載。所以并不是每個應(yīng)用程序都需要升級成“云應(yīng)用程序”。從另一個角度來說，通常很難預(yù)測在一個應(yīng)用程序的整個使用周期內(nèi)會進(jìn)行哪些負(fù)載。由于將來應(yīng)用程序可能會遇到越來越多不可預(yù)測的負(fù)載和古怪的負(fù)載模式，最終設(shè)計模式與編寫動態(tài)應(yīng)用程序相結(jié)合很有可能會成為一種常規(guī)做法——換句話說，每一種應(yīng)用程序都要經(jīng)過編寫，這樣在高度動態(tài)負(fù)載的情況下才會保持穩(wěn)定。對于那些包含這些負(fù)載形式的應(yīng)用程序而言，它們已經(jīng)準(zhǔn)備投入到使用中去了；而對于那些不包含這些負(fù)載形式的應(yīng)用程序來說，這種性能仍然會存儲備用、保持在未開啟狀態(tài)，并在最終需要的時刻派上用場。

對于架構(gòu)師和軟件工程師們來說，學(xué)會當(dāng)前的設(shè)計模式是非常重要的，因為當(dāng)前經(jīng)過設(shè)計和編寫的應(yīng)用程序會在幾年內(nèi)派上用場，而且最終很有可能會在云環(huán)境內(nèi)運行。這就意味著應(yīng)用程序編寫時應(yīng)該照顧到“云應(yīng)用程序”，即使目前并不需要在云環(huán)境內(nèi)進(jìn)行操作。

【編輯推薦】

1. 中小企業(yè)選擇:數(shù)據(jù)中心托管還是云計算?
2. 云計算和主機托管有哪幾點不同?
3. 看云計算如何解決高性能計算資源調(diào)度問題

分享題目：“云計算”不等于“托管2.0”
轉(zhuǎn)載注明：http://www.5511xx.com/article/dhoohed.html