【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内存。
    除了部署Xen虚拟化，37 Signals 也部署了memcached。这是一个高性能的分布式的内存对象缓存系统，是一个PHP开源项目，它的缓存处理是分布式的，也就是可以允许不同主机上的多个用户同时访问这个缓存系统， 这种方法解决了共享内存只能是单机的弊端， 同时也减缓了37 Signals大量客户数据库检索的压力。此外，37 Signals通常使用ActiveRecord框架制作的query，不过鉴于不同情况，有时候还是会采用find_by_sql。另外，由于37Signals就是RoR之父，所以当开发的时候，也会适当修改Rails以满足新的要求。37Signals的存储则是采用了亚马逊的S3（Simple Storage Service）来做图片存储，这是一种在线存储的模式，在国内还较少使用。我还用探针程序观察了一下，37Signal的Web 服务器是 apache的1.3.29。

    我们发现，37 Signals非常相信虚拟化能够带来的优势，而且也相信虚拟化不会损害公司业务的可靠性，由于自身技术实力非常突出，所以虚拟化过程也没有采用VMware，而是开源的Xen。整体而言，对于37Signals的流量，30台服务器已经算少的了，而虚拟化将进一步减少服务器数量，更重要的是，简化了未来的扩展，毕竟37Signals的增长速度实在太快了。除了虚拟化，整个系统平台由Ruby on Rails、Memcached、MySQL、和S3 共同搭建，可见37Signals公司决定彻底将轻质化进行到底。

    事实证明，整个37Signals服务器及配置非常合理，而且足够简化。用户使用过程中得到的是非常简单清晰的Web应用，而且十分快捷。虽说有很多用户可能共享一台服务器，但是目前还没有出现任何安全事故。

    轻质化的思想，不论在37Signals设计的RoR、或是应用Basecamp、Highrise、又或是服务器配置都非常明确。也正是37Signals一系列准确的轻质化策略使得公司不断成长。我们也可以借鉴37Signals的各种策略，简化我们数据中心的服务器配置，得到更高的效率。

    参考资料来源：
    www.highscalability.com
    www.37signals.com
    www.compete.com
    www.webhosting.info
    www.wiki.cn