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

场景内容

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

  • 如果有两个公司,它们正好在相反的时区里,白天都需要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倍的内存来保留所有用户的会话状态。这些会降低服务器的可用性,因为一旦有更多的用户使用时,集群中就需要加入更多的服务器。当你共享多重租赁的应用中的租户突然暴增时,你就没法应付了。

无状态化后情况会如何变化?

在无状态的应用中,你可以在任何一个地方执行用户的请求——会话粘连(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? ]
分享这篇文章:

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

  1. ben says:

    怎么把APP转换成无状态那?

  2. 李勇 says:

    再彻底点,我们的业务需要干脆听从云计算的要求得了。
    基本点要搞清楚,技术平台永远是为上层的应用,上层的业务需求服务的,不能本末倒置。

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据