云計算的可伸縮性迫使App服務無狀態化

來源: 外刊IT評論發布時間: 2010-08-22 21:16 閱讀: 882 次推薦: 0 原文鏈接 [收藏]

摘要：云計算因其軟件上的按需付費模式而大獲成功，有狀態的應用+SQL數據庫是否已成昨日黃花？

　　場景內容

　　云計算因其軟件上的按需付費模式而大獲成功，它創造了一種伸縮性模型：

如果有兩個公司，它們正好在相反的時區里，白天都需要10臺服務器，晚上減少到1臺。那么一個云計算服務商需要11臺服務器就能同時為這兩個公司提供服務——在任何一個時間點，拿出10臺給一家公司用，1臺給另一家。
如果這兩家公司都使用自己的機器，他們每家都要買10臺（總共20臺）。其中9臺機器會在夜里閑置。
時區可不是來共享這些閑置資源的唯一理由：
- 運算需求同樣是一個很好的應用場景。有些公司會在圣誕節時需要很強的運算能力，而另外一些公司則是在財政年度結束時需要，等等。
- 有些公司很可能是不能預知何時需要多少資源。例如slashdot效應。不管是哪種情況都是通過共享來讓他人使用你的空閑資源。這就使按需付費成為可能。
你可以把這種概念擴展到整個平臺成本上——應用程序服務器，數據庫和應用。

Statelessness

　　關于伸縮性的最重要的一點就是——根據負載的情況，白天給公司提供服務的9臺機器在夜間自動縮減到1臺。而這一臺之外的其它8臺機器開始給其它公司提供服務。云計算的這種能夠允許兩個租戶（或更多）共享業務處理能力的特性就叫做過程共享的多重租賃。

　　那么為什么要無狀態的系統架構呢？

　　假設個場景，就說白天時間有1000個用戶分布在10臺機器上，每臺機器大概服務100個用戶。在一個有狀態的系統結構中，每臺機器都只為在本機登錄并產生了會話(session)的那100個用戶服務。這個由http負載均衡來實現，叫做會話粘連(session stickiness)。

　　當夜間到來時，讓我們假設有900個用戶退出系統，其他的100個用戶仍然在線。理想情況下，只需1臺機器就可以為所有的這些人提供服務。然而，這100個用戶可能會分布在所有的這10臺機器上，每臺10人。所以，縮減到一臺機器是不可能的，這樣一來，伸縮性就給限制了。

　　解決這個問題的一個方法就是把10臺機器的所有會話狀態都復制到一起。這樣一來，任何一臺機器都可以為這些用戶服務。但每臺機器就會用掉10倍的內存來保留所有用戶的會話狀態。這些會降低服務器的可用性，因為一旦有更多的用戶使用時，集群中就需要加入更多的服務器。當你共享多重租賃的應用中的租戶突然暴增時，你就沒法應付了。