# FaceStat 的祸根与智慧赢得了胜利 > 原文： [http://highscalability.com/blog/2008/6/9/facestats-rousing-tale-of-scaling-woe-and-wisdom-won.html](http://highscalability.com/blog/2008/6/9/facestats-rousing-tale-of-scaling-woe-and-wisdom-won.html)  卢卡斯·比瓦尔德（Lukas Biewald）分享了一次令人着迷的[大满贯，他的](http://www.lukasbiewald.com/?p=153) [FaceStat](http://facestat.com/) 网站（上传图片并由大众判断）如何被 Yahoo 的链接重击 导致其网站上几乎瞬间出现 650,000 页浏览量跳升的主页。 雅虎花费了大量的精力来确保自己的属性能够处理来自主页的真正大量流量。 将 Internet 的[大眼睛](http://www.poster.net/lord-of-the-rings-ii/lord-of-the-rings-ii-eye-of-sauron-4900244.jpg)转向毫无疑问的新生儿站点，一定是尿布准备就绪的体验。 Theo Schlossnagle 在[中对这些事件进行了怪异的预言，因为标点符号对网站体系结构的影响](http://highscalability.com/implications-punctuated-scalabilium-website-architecture)：随着变化无常的互联网寻求新的娱乐方式，大规模，意外和突然的流量高峰将变得更加普遍（我的摘要）。 完全是 FaceStat 的情况。 这也是我们首次使用 Ruby on Rails 竞争对手 Merb 编写的应用程序。 对于那些认为 Ruby 是问题的人，他们的体系结构现在提供的服务是原始负载的 100 倍。 我们出色的 FaceStat 研究金如何抵御 Yahoo 的猛攻？ 关于 FaceStat 架构的详细信息并不多，因此不是这样。 让我感兴趣的是，这是 Theo 流量高峰现象的及时例子，而我也被团队处理挑战的能力吸引了我。 很少有人能这么快做得更好。 实际上，让我们将 Theo 的规则应用于如何处理这些情况到 FaceStat： * **保持警惕：构建自动化系统，以快速（不到 60 秒）检测并查明这些问题的原因。** 最初没有，但他们正在建立更多的监视以更好地处理未来情况。 更好的监控会在问题真正被警告之前很久就使他们警觉到问题。 也许更多的潜在客户可能已转换为实际客户。 您将永远无法获得足够的监控！* **做好准备：系统地了解服务的瓶颈。** 由于系统相对简单，新颖且变化迅速，我的假设是他们完全意识到系统的缺点，他们只是在忙于添加功能，而不用担心性能和可伸缩性。* **执行分类：了解组成您的网站的各种服务的重要性。** 肯定。 为了响应负载，他们“开始淘汰所有数据库密集型功能”。* **保持冷静：任何未经分析驱动的动作都是在浪费时间和精力。** 从以下引言中可以看出，它们保持了惊人的镇定：“可伸缩地编码并在增加的负载下缓慢增长是一回事，但疯狂地重新构建诸如 FaceStat 之类的活动站点是一整天的事情。” 我不确定他们是如何进行分析的。 总的来说，这是对 Great Eye 始终如一的关注的令人印象深刻的回应。 但并不是所有人都给我留下深刻的印象。一位名叫 Bernard 的评论员说：*很抱歉，但这真是一个愚蠢的故事。 考虑到诸如 slicehost 和 linode 这样便宜的东西，发疯了，您启动了一个 Web 应用程序并且还没有准备好冗余的，高度可伸缩的体系结构……我要说您很遗憾，失望的用户终于回来了。* 评论员将认为这是一个“很好的问题！” 当然，被注意到比被忽略更好。 但是 Lukas 感到遗憾的是，当他为过早注意到而感到遗憾时有一个缺点：*在努力吸引用户访问您的网站后，令人惊讶的是，看到成千上万的人突然被封锁。* 显然，开发人员无法像创建探索性系统那样简单地创建可伸缩系统。 来自 Rackspace 的 Ed 表示，他们可以帮助他们实现阵列自动缩放功能。 而 Rackspace 将是一个很好的解决方案，但费用为每月 500 美元和 2500 美元的安装费。 没有任何一家“放映秀”的创业公司能够承担这些费用。 FaceStat 所处的模式是典型的：*我们发现，类似于 Rails 的平台对于快速建立新站点的原型非常有价值，尤其是因为我们将 FaceStat 作为纯粹的实验开始时却不知道人们是否喜欢它，并且 与后来的功能相比，这是一个非常不同的功能。* 渐进式付费模型对于可伸缩性至关重要，因为这是一开始就可以增强可伸缩性的唯一方法。 即使该行业取得了令人瞩目的进步，我们仍然没有使扩展成为第二性质的软件基础架构。 ## 信息来源 * [快速扩展](http://www.lukasbiewald.com/?p=153)，作者：Lukas Biewald* [FaceStat scales!](http://blog.doloreslabs.com/2008/06/facestat-scales/) on Dlores BLog ## 平台 * [Merb](http://merbivore.com/) 。 与 ORM 无关的基于 Ruby 的 MVC 框架。* [薄](http://code.macournoyer.com/thin/)。 快速，简单的 Ruby Web 服务器。* [Slicehost](http://www.slicehost.com/) 。 托管服务。 能够根据需要快速配置服务器。* [亚马逊的 S3](http://en.wikipedia.org/wiki/Amazon_S3) 。 图像服务器。 延迟很高，但可以处理负载。* [Capistrano](http://capify.org/) 。 自动化部署。* [Git](http://git.or.cz/) 和 [github](http://github.com/) 。 源代码控制系统。 支持高效的同步开发，快速合并和部署。* [上帝](http://god.rubyforge.org/)。 服务器监视和管理。* [Memcached](http://www.danga.com/memcached/) 。 应用程序缓存层。* [PostgreSQL](http://www.postgresql.org/) ## 统计资料 * 六个应用服务器。* 一台大型数据库机。 ## 架构 * FaceStat 是一个写繁重的应用程序，并且对数据执行涉及的计算。* S3 用于减轻存储图像的责任。 这使他们摆脱了巨大的带宽需求和管理自己的图像的复杂性。* Memcached 卸载了对数据库的读取，以使数据库有更多时间进行写入。 ## 得到教训 * **监视站点**。 您越早知道问题，可以更快地解决它。 不要依赖用户电子邮件或来自异常处理程序的电子邮件，否则您将永远无法解决问题。* **通过错误页面**与您的用户通信。 有意义的错误页面显示您正在关心并且正在解决问题。 对于大多数人来说，第二次机会就足够了。* **使用缓存的静态生成的首页**。 很难击败它的性能。* **大型网站在提及较小的网站**时可能要提请注意。 只要有一封简短而礼貌的电子邮件，说明您的世界很快就会倒过来，就可以了。* **与整体架构**相比，高级平台确实没有关系。 处理写入，读取，缓存，部署，监视等的方式相对独立于框架，这是解决重要问题的方式。* **Ruby 和 Merb** 支持快速原型设计，以实验和创建与他们想要的系统完全不同的系统。 据博客称，这并不奇怪，因为他们正在 VPS 上运行 FaceStat。 如此，确实有人说对了，“知识就是智慧” ----- [http://underwaterseaplants.awardspace.com”](<a rel=) >海洋植物 [http ：//underwaterseaplants.awardspace.com/seagrapes.htm“](<a rel=) >海葡萄... [http://underwaterseaplants.awardspace.com/seaweed.htm”](<a rel=) >海藻