“云計算”不等于“托管2.0”
我們要架構云應用程序，但不能讓它變成空中樓閣。如果你采用“托管 2.0”的方式處理云計算，就會造成很嚴重的后果，不信請看下文分析。
HyperStratus咨詢公司最近處理了幾個相似的案例：企業部署在亞馬遜云計算基礎上的應用出現了一些問題。
問題一：應用程序能夠安裝于各系統分類總列表中，并且運行良好，但是如果亞馬遜的彈性云(Elastic Compute Cloud，EC2)實例崩潰或是需要中止程序，該應用程序就會停止運行，直到新版的實例投入運行后才恢復。
問題二：在EC2實例超載的情況下，不能通過添加更多資源來改善應用程序的性能。
問題三：目前只有在完全脫機的狀態下才能夠對應用程序進行升級。
問題四：性能會在數據庫方面遇到瓶頸，但不能通過任何便于管理的方式進行數據庫的復制。
云計算安裝過程中可能遇到的問題
在與這些客戶溝通的過程中，HyperStratus遇到了一個相同的問題：“云計算具有靈活性、可用性。可擴展性等優勢，怎么就解決不了這個問題？為什么應用程序會出現這么多問題？”
問題的根源在于，他們把云計算當做了“托管2.0”，因此吃到了苦頭。
簡單的說，云計算的擴展性與應用程序的擴展性是不同的，除非你架構了云應用程序，否則不可能享有云計算所帶來的好處。HyperStratus的觀點是“要構建云應用程序，但不能讓程序成為空中樓閣。”
那么“構建云應用程序”究竟是什么意思，云與托管2.0究竟有什么不同？從下面這些架構云應用的關鍵原則中獲悉可以找到答案。
要知道到個人計算資源發生什么事情都是可能的。在亞馬遜的云計算中，某一個EC2實例偶爾會出現性能不佳、停止響應甚至崩潰。資源也會出現一定規模的故障。所有云供應商都面臨著這個問題。Google因為它們超低成本的服務器理論而出名，在主板上直接連硬盤驅動器，并且沒有金屬外殼(Google的機器可以稱之為裸身機器)；當一臺機器當機了，Google將其遷移到另外一臺機器上，并且再次做一個備份。因為有著成千上萬臺服務器在運行，失敗是在所難免得，所以google的架構的解決方案時直面失敗，在失敗的時候以更強勁的資源應對。同樣的，應當把個人應用程序運行在云環境中，因為個人的電腦資源更容易出現問題。所以應用程序必須能夠實現在兩個以上EC2實例中運行。
應用程序能夠在兩個以上EC2實例中運行，因此就存在一些潛在的危險。應用程序可能在多個虛擬機之間進行替換，或是設置在兩臺計算機都能夠進入的共享區域。這不是說每個應用程序必須被分隔在它們自帶的實例中，單一的EC2實例可以支持多個應用程序；比如說，在一個單一的實例下可以運行多個不同網站。這確實意味著每個應用程序必須經過編寫才能跨越多個實例。
應用程序要根據云計算環境針對性編寫。這既意味著類同性會話將通過應用程序之前的負載均衡器進行管理，也意味著該應用程序將其自身的會話信息保留在一個共享區域內。這一點可以通過將會話信息保留在由應用程序服務器共享的元數據服務器內來實現，盡管最終這種方法可能會在裝載元數據服務器的過程中遭遇瓶頸。最普遍的解決方法就是將會話信息轉移到性能更加完備的會話分層處理器中。無論如何，會話信息必須要以某種方式滿足應用程序所需要的每個部分。
要確保計算資源具有可擴展性。用戶選擇使用云的一個主要原因是，它能夠使應用程序動態獲取他們想要的資源，根據裝載情況改變資源數量。如果需要人為干擾來增加或減少資源，障礙物就會從計算資源轉化至人類資源，這其實并不是理想狀態。如果不編寫應用程序，資源等級就不能進行動態變化，這時操作員就必須要指派一個固定的資源等級；最終又會回到原有狀態，在實用性和投資之間反復權衡，也就是說，我應該犧牲掉經濟利益還是失掉一部分客戶群？
這些并不是想要阻止人們向“云應用程序”邁進的腳步。編寫應用程序以實現其無需人類介入狀態下的動態縮放并不是微不足道的小事。首先，大多數軟件組件都會假定有人工操作，而不是自動的，你對它進行管理，隨后出現一種“升級配置文件并重新啟動服務器”的解決方案。這十分適合那些極端靜態的應用程序拓撲結構，但卻是動態轉換應用程序拓撲結構的噩夢。
另一個問題就是需要決定如何處理一個應用程序中多版本復制所共享的文檔和物體。它們可以放置在網頁文件系統中，但是性能仍然是個大問題。對于在功能上支持SAN或是NAS的云環境而言，文件可以定位在中心區域，盡管這可能會強制增加一些潛在的危險。文檔的復制版可以放在每個服務器內，盡管這可能會在分配和版本控制方面遇到一些挑戰。最佳的方案就是將所有的文檔全部放置在中心區域內(比如說，放在以Amazon為載體的應用程序S3中)，并在所有虛擬計算機內下載“官方”文件，讓它們在實例化的過程中自行完成安裝。這也有點超出常規，一些非動態環境很少會用到這樣的操作。在大多數環境下的常見方案就是將重點放在硬件(和虛擬計算機)的加固上，并沒有針對動態應用程序拓撲結構制定什么計劃。
目前還沒有確切的數字可以表明到底會有百分之幾的應用程序需要進行動態拓撲結構的裝載。所以并不是每個應用程序都需要升級成“云應用程序”。從另一個角度來說，通常很難預測在一個應用程序的整個使用周期內會進行哪些負載。由于將來應用程序可能會遇到越來越多不可預測的負載和古怪的負載模式，最終設計模式與編寫動態應用程序相結合很有可能會成為一種常規做法——換句話說，每一種應用程序都要經過編寫，這樣在高度動態負載的情況下才會保持穩定。對于那些包含這些負載形式的應用程序而言，它們已經準備投入到使用中去了；而對于那些不包含這些負載形式的應用程序來說，這種性能仍然會存儲備用、保持在未開啟狀態，并在最終需要的時刻派上用場。
對于架構師和軟件工程師們來說，學會當前的設計模式是非常重要的，因為當前經過設計和編寫的應用程序會在幾年內派上用場，而且最終很有可能會在云環境內運行。這就意味著應用程序編寫時應該照顧到“云應用程序”，即使目前并不需要在云環境內進行操作。
【編輯推薦】
