要快速伸缩？重新架构吧！

虽然经受“/. 效应”的考验常被人拿来说事，但其实 Yahoo! 的首页才是互联网上最繁忙的站点。Lukas Biewald 讲述了他的 FaceStat 网站被 Yahoo！首页上榜之后访问人数急速上升到 100,000，因而不得不快速完成伸缩的故事。

星期天早上我坐在厨房里，边看报纸边想着早饭午饭一块儿吃了就在这时候接到了 Chris 的电话。他告诉我他家里的电话有好几通留言，都是说我们的网站 FaceStat 挂了。 FaceStat 是我们 Dolores Labs 用来展示群众资源技术的一个站点，发布一个月以来已经有了一小群追随者。我检查了一下网站的情况，发现它给我返回了 500 错误——10 次请求里大概只有一次能打开真正的页面。于是我登录到应用服务器上，发现磁盘已经满了，log 文件竟然涨到了 20GB！我把 log 文件删了，然后让朋友 Zuzka 查查看我们是不是被 Slashdot 临幸了。

第一反应是建立静态的页面，但他们发现仍不足以在汹涌的潮水中站住脚：

难以置信，我们的 Web 服务器（ nginx ）连静态页面也没办法可靠地显示……Brendan 发现我们已经达到了系统对最大文件打开数的限制——100,000——因为连接也算是打开文件。

接着团队转向要求主机托管商增加服务器资源，增加缓存，并且开始去除一些功能：

Brendan 忙着安装新的机器，我则开始砍掉系统里所有数据库密集的功能，Chris 负责增加缓存……大概中午 1 点网站重新上线，看起来很稳定。

周一负荷继续增大，于是团队增加了 memcached、监控工具，还把数据库移到了另一台更大的机器上：

现在已经是周二的晚上，原来在一台机器上处理的负载，现在已经增长到了 50 倍，网站看上去有点摇摇欲坠。我们有 6 台应用服务器和一台大型的数据库服务器。Chri 和 Brendan 真是了不起的黑客，现在的工具进步也很了不起。 Slicehost 的伸缩速度正是我们需要的。Amazon 的 S3 负担了所有的图片，虽然响应延迟不甚完美，但单凭我们自己绝对解决不了这种带宽问题。 Capistrano 让我们得以随时随处部署和回滚；git 加上 github 让我们得以争分夺秒地分头行动，再把代码合并到一起做部署。 God 保障服务器运行。 memcached 给了我们出色的缓存，而痛苦非常少（基本上……）。

Lukas 总结他们在三天里得到的教训：

编写可伸缩的代码然后随着负载增长慢慢地提高，这是一回事；像我们这样在一两天里疯狂地重新架构一个工作中的网站则是截然不同的另一回事。我想现在网站已经是互联网上能排得上号的了，应该不会再有更大规模的流量突然上升……不过如果再发生这样的事情，我已经在这次经历中学到了一些教训：

（1）做好网站的监测。在此之前已经让异常处理程序发送邮件给我们，但异常很多，所以我并不会认真看，而且事情发生的时候我不在线。预先就为这种负载来伸缩网站显然是不合理的，但我们错在不该依靠好心人查出 Chris 的邮件地址和家庭电话去告诉他……

（2）不要畏惧放上一个错误页面。当我们放上一个页面说明网站挂了并解释原因之后，收到了很多兴高采烈的用户来信。而当我们的网站勉强运行，不但延迟严重还断断续续地死机的时候，我们收到了很多愤怒的用户来信。不切实际的想法让我们在网站真正准备好之前一两个小时就把它上了线。

（3）静态生成的首页是件好东西，memcached 是件了不起的东西。

Brendan O’Connor 在一篇后续文章中谈到了 FaceStat 应用背后的技术：

是的，我们基本上是用 Rails。我们实际上用的从 Rails 衍生出来的 Merb ，它的效率更高一些，底下用的是 Thin 。我们发现 Rails 类的平台对于快速打造新网站的原型真是无价之宝。特别是我们启动 FaceStat 的时候完全是当作一个实验品，根本不清楚人们会不会喜欢，而且最初的功能设想和后来实际的情形差别很大。 Chris 这个 Ruby 专家对于我们的团队也是无价之宝:)。

不过，与整体的架构相比，高层的平台实在不算什么：我们如何使用数据库（postgres）、如何缓存（memcached/merb-cache）、如何分摊负载、如何部署新系统（xen/slicehost），这些才是真正有影响的架构议题。FaceStat 是写操作密集的、要执行的统计计算也相当复杂，种种问题都不可小视。但现在我们所服务的用户比原先的负载提高了将近 100 倍，也就是说我们干得还算不错——至少现在！

查看英文原文： Need to Scale Fast? Just Re-Architect it!