場景內容
雲計算因其軟件上的按需付費模式而大獲成功，它創造了一種伸縮性模型：
- 如果有兩個公司，它們正好在相反的時區裏，白天都需要10臺服務器，晚上減少到1臺。那麼一個雲計算服務商需要11臺服務器就能同時爲這兩個公司提供服務——在任何一個時間點，拿出10臺給一家公司用，1臺給另一家。
- 如果這兩家公司都使用自己的機器，他們每家都要買10臺（總共20臺）。其中9臺機器會在夜裏閒置。
- 時區可不是來共享這些閒置資源的唯一理由：
- 運算需求同樣是一個很好的應用場景。有些公司會在聖誕節時需要很強的運算能力，而另外一些公司則是在財政年度結束時需要，等等。
- 有些公司很可能是不能預知何時需要多少資源。例如slashdot效應。不管是哪種情況都是通過共享來讓他人使用你的空閒資源。這就使按需付費成爲可能。
- 你可以把這種概念擴展到整個平臺成本上——應用程序服務器，數據庫和應用。
關於伸縮性的最重要的一點就是——根據負載的情況，白天給公司提供服務的9臺機器在夜間自動縮減到1臺。而這一臺之外的其它8臺機器開始給其它公司提供服務。雲計算的這種能夠允許兩個租戶（或更多）共享業務處理能力的特性就叫做過程共享的多重租賃。
那麼爲什麼要無狀態的系統架構呢？
假設個場景，就說白天時間有1000個用戶分佈在10臺機器上，每臺機器大概服務100個用戶。在一個有狀態的系統結構中，每臺機器都只爲在本機登 錄併產生了會話(session)的那100個用戶服務。這個由http負載均衡來實現，叫做會話粘連(session stickiness)。
當夜間到來時，讓我們假設有900個用戶退出系統，其他的100個用戶仍然在線。理想情況下，只需1臺機器就可以爲所有的這些人提供服務。然而，這100個用戶可能會分佈在所有的這10臺機器上，每臺10人。所以，縮減到一臺機器是不可能的，這樣一來，伸縮性就給限制了。
解決這個問題的一個方法就是把10臺機器的所有會話狀態都複製到一起。這樣一來，任何一臺機器都可以爲這些用戶服務。但每臺機器就會用掉10倍的內 存來保留所有用戶的會話狀態。這些會降低服務器的可用性，因爲一旦有更多的用戶使用時，集羣中就需要加入更多的服務器。當你共享多重租賃的應用中的租戶突 然暴增時，你就沒法應付了。
無狀態化後情況會如何變化?
在無狀態的應用中，你可以在任何一個地方執行用戶的請求——會話粘連(session stickness)不再是個問題。當用戶從1000減到100後，你可以立即釋放9臺服務器，調給其它公司使用，只用1臺爲這100個用戶服務。.
這聽起來很簡單。而實際操作起來卻不是那麼容易。所有的應用都需要狀態。如果應用服務器不去處理這些狀態，你就必須想其它的辦法。數據庫就是一個明 顯的問題。當前的數據庫已經在擴展問題上遇到了足夠的麻煩了，再加上狀態管理，那是絕對不可行的。所以NoSQL纔要“分佈式”存儲。
在PaaS服務商中你會看到這是一種常見的架構模式：
- Google App Engine – 無狀態請求 + Big Table
- Microsoft Azure – web角色 + Azure存儲/SQL
- 當然了，還有我們公司 – OrangeScape，它是運行在GAE/Amazon EC2 之上的。
- 我估計VMforce也是這樣的 – Spring stateless session beans + Force.com DB
那就都雲計算吧！有狀態的應用+SQL數據庫已成昨日黃花了。(抱歉！實在忍不住。)
翻譯來源：外刊IT評論
；)
