AICon 上海站|90%日程已就绪,解锁Al未来! 了解详情
写点什么

要快速伸缩?重新架构吧!

  • 2008-06-25
  • 本文字数:1692 字

    阅读完需:约 6 分钟

虽然经受“/. 效应”的考验常被人拿来说事,但其实 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!

2008-06-25 17:271242
用户头像

发布了 225 篇内容, 共 67.9 次阅读, 收获喜欢 52 次。

关注

评论

发布
暂无评论
发现更多内容

大模型训练中断,断点续传助力快速恢复

百度开发者中心

人工智能 深度学习 大模型

基于大模型训练的编程助手

百度开发者中心

人工智能 大模型 智能代码助手

代码出错了,IDE竟然不报错?太诡异了....

互联网工科生

ide 代码 ChatGPT

企业数字化转型,应该先从哪开始?

优秀

企业数字化转型

教育场景数字化中音视频小程序的发展

Onegun

在线教育 教育 教育科技

一文详解 Java 限流接口实现

阿里技术

Java 分布式限流 限流算法 应用级限制 限流接口

阿里巴巴中国站1688商品详情API实时数据获取:从零基础到精通的全程指南

Noah

分布式日志追踪ID实战 | 京东物流技术团队

京东科技开发者

如何做代币分析:以 OCEAN 币为例

Footprint Analytics

区块链 加密货币 代币

NeurIPS'23 Paper Digest | PromptTPP: Prompt Pool 与时序点过程模型的持续学习

可信AI进展

机器学习 持续学习 Prompt prompt learning 时序模型

软件测试开发/全日制丨Web端测试—JavaScript讲解 学习笔记

测试人

软件测试

Spring 应用合并之路(一):摸石头过河 | 京东云技术团队

京东科技开发者

医疗设备管理二维码:扫码查看使用说明、填写消毒记录

草料二维码

二维码 草料二维码 医疗设备 医疗设备管理

3 分钟为英语学习神器 Anki 部署一个专属同步服务器

米开朗基杨

中间件是开箱即用的吗?为什么要开发中间件adapter?

华为云开发者联盟

开发 华为云 华为云开发者联盟

如何实现APP安全加固?加固技术、方法和方案

Geek_66e2f3

基于ETLCloud的MySQL到SqlServer实时同步解决方案

RestCloud

MySQL 数据同步 ETL SqlServer

要快速伸缩?重新架构吧!_Ruby_Gavin Terrill_InfoQ精选文章