云计算的可伸缩性局限性探讨
云计算的可伸缩性
云计算服务因为它的按需付费模式而大获成功，它创造了一种可伸缩性模型：
如果有两个公司，它们正好在相反的时区里，白天都需要10台服务器，晚上只需要1台。那么一个云计算服务商只需要11台服务器就能同时为这两个公司提供服务——在任何一个时间点，拿出10台给一家公司用，1台给另一家。而如果这两家公司都使用自己的服务器，他们每家都要买10台(总共20台)。其中9台服务器会在夜里闲置。
当然，时区并不是使用云计算服务的唯一理由，不同时间内要求的计算能力的不同也是一个重要的原因。有些公司会在圣诞节时需要很强的计算能力，而另外一些公司则是在财政年度结束时需要，等等。
另外有些公司并不能确定自己什么时候需要什么样的计算能力。如果它们选择了云计算服务，不管在什么情况下都可以通过共享来让他人使用你的空闲资源，或者使用别人的空闲资源。这就使按需付费的云计算服务模式变得更加的流行。
这种可伸缩的概念可以扩展到整个平台成本上，包括服务器，数据库以及应用程序。
关于伸缩性的最重要的一点就是——根据负载的情况来进行调整，白天给公司提供服务的9台服务器在夜间自动缩减到1台。而这一台之外的其它8台服务器开始给其它公司提供服务。云计算的这种多重租赁的特性能够允许两个用户(或更多)共享业务处理能力，同时也节约了大量的资源。
可伸缩性的局限性
假设以个场景，就说白天时间有1000个用户分布在10台服务器上，每台服务器大概服务100个用户。在一个有状态的系统结构中，每台服务器都只为在本机登录的那100个用户服务，每台服务器平均分配了这1000个用户的访问。
当夜间到来时，让我们假设有900个用户退出系统，其他的100个用户仍然在线。理想情况下，只需1台服务器就可以为所有的这些人提供服务。然而，这100个用户可能会分布在所有的这10台服务器上，每台10人。所以，缩减到一台服务器是不可能的，这样一来，伸缩性的局限性就表现出来了。
解决这个问题的一个方法就是把10台服务器的所有用户都集中到一台服务器中。这样一来，任何一台服务器都可以为这些用户服务。但是每台服务器中用户的资料必须继续保存着，这就相当于每台服务器会用10倍的内存来保存用户的会话状态。这些会降低服务器的可用性，因为一旦有更多的用户使用时，服务器就显得有些不够了。当云计算服务商的一个客户用户量突然增多的时候，其他的客户也就势必会受到影响。
无状态化服务架构
一些云计算服务商开始使用无状态化架构来解决这一问题。如Google App Engine使用无状态请求 + Big Table;Microsoft Azure使用web角色 + Azure存储/SQL等等。在无状态的应用中，你可以在任何一个地方执行用户的请求，用户的会话状态不再是个问题。当用户从1000减到100后，你可以立即释放9台服务器，调给其它公司使用，只用1台为这100个用户服务。.
这听起来很简单。而实际操作起来却不是那么容易。因为所有的应用都需要状态，而如果服务器不去处理这些状态，你就必须想其它的办法。数据库就是一个明显的问题。当前的数据库已经在扩展问题上遇到了足够的麻烦，如果再加上状态管理，显然是不可行的。所以，分布式的存储就是一个很好的解决办法。
原文出自【比特网】，转载请保留原文链接：http://datacenter.chinabyte.com/88/11577088.shtml
