云计算的可伸缩性迫使App服务无状态化

　　场景内容

　　云计算因其软件上的按需付费模式而大获成功，它创造了一种伸缩性模型：

• 如果有两个公司，它们正好在相反的时区里，白天都需要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数据库已成昨日黄花了。(抱歉！实在忍不住。)

　　[英文出处]：Why does "Elastic" nature of cloud impose "statelessness" constraint on App servers?