分类归档: 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–

PlentyOfFish 网站架构学习

采取 Windows 技术路线的 Web 2.0 站点并不多，除了 MySpace ，另外就是这个 PlentyOfFish。这个站点提供 “Online Dating” 服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人Markus Frind）的站点价值 10 亿，估计要让很多人眼热，更何况 Markus Frind 每天只用两个小时打理网站–可操作性很强嘛。

之所以选择 Windows .NET 的技术路线是因为 Markus Frind 不懂 LAMP 那一套东西，会啥用啥。就这样，也能支撑 超过 3000 万的日点击率(从这个数字也能看出来人类对自然天性的渴望是多迫切)。Todd Hoff 收集了很多关于 PlentyOfFish 架构的细节。记录一下感兴趣的部分。

带宽与CPU

PlentyOfFish 比较特殊的一个地方是 几乎不需要 Cache，因为数据变化过快，很快就过期。我不知道这是因为 ASP.NET 的特点带来的架构特点，还是业务就是这个样子的。至于图片，则是通过 CDN 支撑的。对于动态出站(outbound)的数据进行压缩，这耗费了 30% 的 CPU 能力，但节省了带宽资源。我最近才知道，欧美的带宽开销也不便宜。

负载均衡

微软 Windows 网络负载均衡(Network Load Balancing) 的一个缺陷是不能保持 Session 状态(我没有用过这玩意儿，不能确认)，价格也不便宜，而且复杂；网络负载均衡对 Windows 架构的站点又是必须–IIS 的总连接数是有限制的。PlentyOfFish 用的是 ServerIron

(Conf Refer)，ServerIron 使用简单，而且功能比 NLB 更丰富。

数据库

一共三台 SQL Server，一台作为主库，另外两台只读数据库支撑查询。数据库性能监控用的是“Windows 任务管理器”。因为 Cache没啥用，所以要花大力气优化 DB。每个页面上调用 DB 次数越少越好，越简单越好，这是常识，不过不是每个人都体会那么深而已。

微软好不容易找到了一个宣传案例，所以在 Channel 9 上有一个 PlentyOfFish 的访谈。

PlentyOfFish 取自天涯何处无芳草(Plenty of fish in the sea)的意思，还挺有文化的。从这一点上看，比国内那些拉皮条的网站好一些。

–EOF–