Tag Archives: Arch

37Signals 架构

如果没有 37signals ，恐怕也没有 RoR 的如此流行。37signals 对于很多 Geek 来说，是一家非常迷人的公司。他们是网络上的另类新星。

37Signals 在 Signal vs. Noise 上披露了比较详细的运营数据，Ask 37signals: Numbers?

存储数据量

截止到 2007 年 11 月，总存储量统计：

5.9 T 用户上传的数据
888 GB 上传文件 (900,000 请求)
2 TB 文件下载 (8,500,000 请求)

这包括 Basecamp、Highrise、BackPack、Campfire总的数据统计。总的用户量其实并不多，只有 200 万。

这些数据存放在 Amazon S3 上，37Signals 用了这个服务已经一年多了，他们对此比较满意。事实上，Amazon S3 已经成为 Web 2.0 分布式存储的既定事实的解决方案。

服务器状况

37Signals 当前正在部署虚拟化软件产品，当然不用 VMware，而用开源的 Xen。当前大约有 30 台服务器，从单 CPU 的文件服务器到 8 CPU 的应用服务器都有，总共 100 颗 CPU、200GB 内存。预计 XEN 部署完毕后，服务器数量降低到 16 台，92 颗更快的 CPU、230GB 的内存量。这样做的主要目的是管理起来更方便(至于性能是否更好，我个人还是有点怀疑的–Fenng)。

关心 ROR 以及具体一些策略具体实现的朋友不防去看看那个帖子下面的留言。

之前还真的很少有听说哪家 Web 2.0 公司部署 XEN 的，37signals 的这个动作或许是个积极的信号。2007 年也是个”虚拟化”年，相信随着虚拟化的技术成熟，开源力量的壮大，会有更多的公司收益于 XEN 虚拟化架构.

–EOF–

Microsoft.com 后面的小道消息

微软员工 Jeff Alexander 在 Blog 上写了一篇 Microsoft.com: What’s the story? 报料了 Microsoft.com 站点的一些技术架构信息。不料，这篇文章以迅雷不及掩耳盗铃之势被删除了。还好，Google 以迅雷不及掩耳盗铃之势做了快照。

这篇文章有的地方已经做了介绍，题为微软官网Microsoft.com的一些安全防护数据。但还是漏掉了一些信息。

1) 微软的运营团队 Blog。毕竟是官方的运行团队，在 Blog 上介绍了不少经验，非常值得借鉴。

2) HBI 是啥? 才疏学浅，搜索了一下才知道是：High Business Impact 的缩写。很奇怪，很多人看了那片文章而没有对此有疑问，或许大家都已经知道了。我火星。

3）对待杀毒工具( AV，此 AV 非彼 AV，不知道上面翻译的人为啥没提)的态度。众所周知，对于 Windows 服务器的维护来说，病毒问题会让很多人很头疼。微软运营团队的是态度是：只要有可能，还是会进行杀毒的。

另外，我比较好奇的是微软用什么做 Log 解析。Linux + Perl 这一套东西估计他们是不会用的。

最后，我把英文的快照扔到本站临时目录上了，尽可去一窥全豹[请”另存为”，然后 IE 观看]。

–EOF–

Flickr 的访问统计实现以及其他

TechCrunch 前两天报道说 Flickr 针对 Pro 用户新增了一项统计功能。今天有看到 Flickr 的 DBA Dathan Pattishall 描述了一下这个统计功能的实现。

Flickr 统计功能的基本技术信息：

所有的信息统计是实时的
同时用到 MYISAM 与 INNODB 两种引擎
数据因为存储需求跨在 6 个 Cluster 上(12 台服务器，6 台提供服务，6 台做失败接管)
没有用 Memcache

Dathan 提到这是他最耗时的一个项目(似乎有点怨言呀)。因为是实时统计，并且还要不影响整体页面响应速度，所以整个项目非常复杂。一旦 DB 设计搞定后，大部分时间都花在如何创建分布锁上了。

其实就我个人而言，真的不觉得这个功能有什么必要(尤其还是实时统计)。这或许是过度设计的一个例子。Flickr 在被 Yahoo！收购之后，这段时间倒是有点颓势。

说起 Dathan 这老兄，在 MySQL 技术圈子算是大名鼎鼎了。曾先后在 Friendfinder、Friendster 做 DBA，并获得国 05、06 两年的 “MySQL Application of the Year Award“。(看他 Blog 的活跃劲儿，估计今年也差不多。)

这老兄加盟了 Flickr 后，一个礼拜解决了 40％左右的性能问题。从他的简历来看，Flickr 目前每日 DB 的事务超过 10亿，MySQL 运行在 16G 内存、AMD CPU 服务器上，存储采用本地硬盘而没有用 SAN。数据库采用联邦架构，能做到线性扩展，为公司节省成本达 40 万美元(占40%，从而估计 DB 相关硬件成本为 60万美元).

推荐国内每个 Web 2.0 公司的 DBA 持续关注 Dathan 的 Blog，当然，可能大家都已经一直在看了。

–EOF–

性能扩展问题要趁早

与国内的 Web 2.0 Startup 技术人员相比，国外技术人员更乐于分享。分享也是一种更好的宣传手段，如果不是看到了这篇 Scaling an early stage startup，或许我就不会知道这位 Mark Maunder (他还有个中文名字：马孟德) 以及他的 FeedJet。

一般来说，一个刚刚发布的 Web 应用，因为用户量并不多，性能问题可能并不是很明显。可一旦宣传展开，用户增长或许不是线性的而是暴增(从几十个到几万个，相比之下怎不是暴增?)，这时候如果遇到性能问题，毫无疑问会影响初期用户的信任。

Maunder 文档中列举了一个扩展过程，相信这些例子也是他实际遇到的。毕竟 Startup 都是一两个人打通关，不可能所有技术都面面俱到的精通。下面记录一点。

错误的设置

数据库服务器的参数配置问题：导致 MySQL 消耗了大量资源。Apache Keepalive 的设置为不合理，修改为 off。我想这个前提应该还是要选择自己最擅长的技术路线。如果错误的选择另一条不熟悉的技术路线，那么遇到技术时解决问题的速度怕是更让用户恼火。对于 Apache 还应该知道 Httpd.Worker 比 Prefork 消耗更多内存 (httperf 来进行 Benchmark) ，内存也是蛮贵的。

尽可能的缓存动态内容

尽可能的利用数据库的 Cache，利用其他 Cache 工具，如 MemCacheD，来减轻对磁盘的 IO 压力。为了节省成本，很多站点都是用的低速大容量的磁盘，所以，充分利用 Cache 是一个网站成功的必然条件。这样的软件BerkeleyDB 的最高事务处理记录是 90000 事务/秒。

剥离图片与CSS 到单独的服务器

说白了，也是为了减轻磁盘的压力。现在很多 Web 2.0 站点都把图片放到 Amazon S3 上，省心了不少。当然，国内还没这样的服务。

阻止内容引用”窃贼”

现在连那些大站点都在阻止图片被第三方引用，小站点更要提防被大站引用，很容易耗光网站的容量。另外一个要注意的是网络爬虫的频率。

在线观看这篇 Scaling an early stage startup。顺便说一下，最近在 Scribd 上看到了不少有意思的文档。

–EOF–