【IT168 专稿】今天我们的主角，是一家网页设计公司。这家网页设计公司很特别，设计网页之余，公司用闲暇时间做出了举世瞩目的平台——Ruby on Rails(RoR)。没错，这家公司就是大名鼎鼎的37 Signals。几年来，37 Signals的标签似乎就是Ruby on Rails，但是这个单一的标签似乎已经结束了，37 Signals又开始了奇异的旅程，37 Signals利用Ruby on Rails平台制作了Basecamp、 Highrise、Backpack和 Campfire在线管理软件，所有这四款产品上市后都好评如潮，这也使37 Signals被《时代》杂志称作“非常好的网络新星”。这几款产品都有共同的特点，就是基于网络，www.37signals.com就是这些应用的载体，今天我们就来分析一下www.37signals.com的后台架构。

    可能有些读者不是特别了解37 signals应用的运行模式，简单的说，37 Signals利用自己的数据中心，为各个领域的用户提供项目管理等服务，也就是流行的SaaS(软件即服务)模式。换言之，企业不必搭建自己的数据中心，而只要有PC，并且将PC联网即可一定程度上替代复杂的ERP、CRM服务。这样一来，极大地减轻了用户数据中心成本，不过业务数据的压力也随之转移到了像37 Signals 这样的SaaS提供商的服务器上。与企业自己的数据中心只处理自己的业务不同，37 Signals必须处理成百上千用户的数据和应用请求，这也对37 Signals的数据中心有非常高的要求——服务器决不能宕机，甚至不能出一点小差错，否则大量的用户数据将受到威胁。另外一方面，37 Signals只是一家小公司，2年前才只有8个成员，其中甚至有4个人还是外地SOHO工作的。虽然公司非常袖珍，但是业务发展得异常迅猛，37 Signals的服务器的流量有多大呢？能承受与日俱增的业务压力么？

    上图就是37 Signals的2007年流量图，为了使读者更加明晰，这次我们不用alexa，而采用compete的月度访问人数表格，我将网易163与之作了对比(在此我们仅比较37signals的登陆页，此比较不包括登陆后跳转的其他页面)。可以看到07年中旬两个月间，37 Signals的使用者迅速，超过了国内大牌的www.163.com，可见其业务量之大，与163不同的是37 Signals的Web应用要求更高，如果163个别文章链接有问题，我们都可以理解，毕竟163只是一家媒体，但是如果37 Signals的Basecamp的某处链接出现问题，那么将可能涉及企业关键数据信息，影响重大。

    实际上，37 Signals的数据量非常惊人：

    在Basecamp (基于Web的项目管理)中

    * 2,000,000 个用户帐户
    * 1,340,000 个项目
    * 13,200,000 个计划事项(to-do items)
    * 9,200,000 条消息
    * 12,200,000 个评论
    * 5,500,000 条时间追踪目录
    * 4,000,000 个里程碑

    在 Backpack (个人/中小企业信息管理)中，有

    * 1,000,000 个页面
    * 6,800,000个计划事项(to-do items)
    * 1,500,000 条记录
    * 829,000 个图表
    * 370,000 个文件

    整体存储状况 (2007年11月统计)

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

    应对这样的数据量，截止到07年11月，37 Signals采用了：总计30台服务器，其中有简单的1CPU的文件服务器，也有8CPU SMP的应用服务器，整体计算下来，大约有100个CPU和200GB的内存。这个时候，公司发现自己的服务器越来越多，30个服务器的安排已经很复杂，不像几台服务器时那么容易了，所以公司决定采取一些办法来简化服务器管理。其中重要的办法就是全面部署虚拟化。目前该公司已经在部署Xen软件，按照37 Signals的计划，到2008年2月份，虚拟化部署基本结束，届时，处理当前的业务需求只需要16台服务器，一共92个CPU核心，和230GB内存。