37signals 是除了 Twitter 以外的又一个高流量 Ruby on Rails 架构的示例。

数据

数据来源（2007）：Ask 37signals: Numbers?

约30台服务器组成的 cluster，从 1 CPU 的文件服务器到 8 CPU 的应用服务器，加起来大慨 100 CPUs 和 200GB 内存（正计划把服务器数量减到16台，92 CPUs 和 230GB 内存，性能更高，架构更简单更易管理）。
客户总共上传约 5.9TB 的数据

Stack

以下是 37signals 用到的一些 stack：

Apache
HAProxy
Ruby on Rails
Mongrel
Memcached
MySQL
Xen
Amazon S3

值得注意的是用到了 Xen 虚拟技术和 Amazon S3 云存储。Memcached 现在已是高访问量网站的标准配置了，就不介绍了。有意思的是，DHH 在 Interview with David Heinemeier Hansson 提到，随着技术的发展，硬件越来越便宜，如果能用硬件解决问题就尽量用硬件，除非绝对必要，否则 shard 数据库来分载流量很痛苦。所以 37signals 不太赞成随便 shard，他们现在的主程序就跑在1台 128GB 的主服务器上，然后有多个备份服务器支持，主服务器不久会扩充到 256GB。VPSee 推测他们的 load balancing 是 Xen 之间的 load balancing，不是物理服务器之间的分载。

HAProxy

37signals 用 HAProxy 作为他们的 load balancer，用在前端 Apache 和后端 Mongrels 之间，HAProxy 能有效的把流量分散到不同的 Mongrels 服务器上，如果其中一个 Mongrel 倒了，并不影响整个网站的运行（failover）。类似的 load balancing 和 failover 工具有很多，37signals 解释了几条为什么选择 HAProxy 作为他们的 load balancer：
1、速度，HAProxy 非常非常快；
2、占资源少，他们的一个运行在 Xen 上的 HAProxy 处理每秒约700次的请求只占用约 %5 CPU 和 40MB 内存;
3、HAProxy 改变配置后即生效，不用断开连接；
4、如果 Mongrels 很忙来不及处理的话，HAProxy 可以把请求暂时放在 queue里。

Xen

为了便于服务器的管理 37signals 使用了 Xen 虚拟技术，把服务器数量从30台左右减少到16台。DHH 在一篇回帖里提到他们在使用 Xen：

Tim, we use Xen. Wonderful system. Strongly recommended for anyone building out a cluster.

Amazon S3

37signals 把图片等用户上传的静态文件存储在 Amazon S3 上，这是一个非常棒的想法，把自己不是很核心的东西外包出去，不用自己的服务器资源，大大减少了服务器硬件，软件，存储，网络带宽，人力维护等方面的成本，可以让自己把主要精力放在核心功能的开发上。

这种用自己服务器维护核心程序和数据 ，把非核心程序和数据外包出去运行在其他公司服务器上的方式可能是未来云计算（Cloud Computing）的一种发展趋势。