分类归档: Arch

性能扩展问题要趁早

与国内的 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–

LinkedIn 架构笔记

现在是 SNS 的春天，最近又有消息传言新闻集团准备收购 LinkedIn。有趣的是，LinkedIn 也是 Paypal 黑帮成员创建的。在最近一个季度，有两个 Web 2.0 应用我用的比较频繁。一个是Twitter，另一个就是 LinkedIn。

LinkedIn 的 CTO Jean-Luc Vaillant 在 QCon 大会上做了 ”Linked-In: Lessons learned and growth and scalability“ 的报告。不能错过，写一则 Blog 记录之。

LinkedIn 雇员有 180 个，在 Web 2.0 公司中算是比较多的，不过人家自从 2006 年就盈利了，这在 Web 2.0 站点中可算少的。用户超过 1600 万，现在每月新增 100 万，50％会员来自海外(中国用户不少，也包括我).

开篇明义，直接说这个议题不讲”监控、负载均衡”等话题，而是实实在在对这样特定类型站点遇到的技术问题做了分享。LinkedIn 的服务器多是 x86 上的 Solaris ，关键 DB 用的是 Oracle 10g。人与人之间的关系图生成的时候，关系数据库有些不合时宜，而把数据放到内存里进行计算就是必经之路。具体一点说，LinkedIn 的基本模式是这样的：前台应用服务器面向用户，中间是DB，而DB的后边还有计算服务器来计算用户间的关系图的。

问题出来了，如何保证数据在各个 RAM 块(也就是不同的计算服务器)中是同步的呢? 需要一个比较理想的数据总线(DataBus)机制。

第一个方式是用 Timestamp . 对记录设置一个字段，标记最新更新时间。这个解决方法还是不错的—除了有个难以容忍的缺陷。什么问题？就是 Timestamp 是 SQL调用发起的时间，而不是 Commit 的确切时间。步调就不一致喽。

第二个办法，用 Oracle 的 ORA_ROWSCN (还好是 Oracle 10g). 这个伪列包含 Commit 时候的 SCN(System Change Number)，是自增的，DB 自己实现的，对性能没有影响。Ora_ROWSCN 默认是数据库块级别的粒度，当然也可做到行级别的粒度。唯一的缺点是不能索引(伪列). 解决办法倒也不复杂：增加一个 SCN 列，默认值”无限大”。然后用选择比某个 SCN 大的值就可以界定需要的数据扔到计算服务器的内存里。

ORA_ROWSCN 是 Oracle 10g 新增的一个特性，不得不承认，我过去忽略了这一点。我比较好奇的是，国内的 Wealink、联络家等站点是如何解决这个关系图的计算的呢?

–EOF–

一点题外话：我的 LinkedIn Profile (Mail : [email protected]). Keep in Touch!。
另外建议正在找工作的同学不妨使用一下这类站点(国内的有联络家和若邻)。一般人我不告诉他~~

Yahoo！社区架构

旧金山举行的 QCon 会议带给我们很多新鲜的信息。虽然没机会参加，但是看看各个网站”晒架构”也是个比较过瘾的事情。请参观并收藏这个页面：Architectures you’ve always wondered about。

eBay 的架构和去年相比基本是换汤不换药，倒是 Yahoo! 的 Ian Flint(这位老兄是 Bix 的运营总监. Bix 已被雅虎收购) 这个 PPT Yahoo! Communities Architecture: Unlikely Bedfellows 挺有意思，披露了一些鲜为人知的信息。

Yahoo! 社区包括我们比较熟悉的 del.icio.us、Flickr、Yahoo!群组、Yahoo! Mail、Bix等。相当于 Yahoo！把这些属性相近的应用放到一起运营。这个思路倒是和盛大对游戏的运营有些相近。

架构特点

有两点值得注意：1）层次化 2）模块化。这也是大规模作业下的比较经济的途径。

软件架构

首先是操作系统已经从 FreeBSD 逐渐迁移到 RHEL。这怕是雅虎不得已作出来的决定吧。FreeBSD 的开发力量的确不如 Linux，这也是不争的事实。数据库上 MySQL 与 Oracle 都有。Yahoo! 在 DW/BI 用的是 Oracle，构建了一个超大数据库。诸如 yapache、yts(反向代理服务器)、yfor(提供快速失败接管)、 ymon（监控），还有还有ysquid、ypan(cpan的 Yahoo! 克隆) 这些组件都是通过 yinst 来统计部署。关于 Yapache，请参考我以前写的 Yapache-Yahoo! Apache 的秘密

这是 Bix 与 DB 有关的部署架构:

数据放在 Netapp NAS 上(所以有的时候应用之慢也可以理解了)，通过快照复制到其他数据中心。

Yahoo! Mail 架构：

这里面居然部署了 Oracle RAC，用来存储 Mail 服务相关的 Meta 数据。非常有趣。

运营维护

监控工具主要用的是 Nagios，用以监控集群。使用标准插件，另外也有自行定制的插件。Nagios 这东西太棒了。主动、被动检查的消息转发是通过 Ymon 来做到。网管上针对 SNMP 的解决方案是用 Yahoo！自己 Y 字头的 Ywatch。这些 Y 字头的东西基本上外面都是找不到的。Yahoo！的技术其实并不那么开放。Google 在运营这方面也好不到什么地方去。趋势图用 Drraw 展现。Drraw 是基于 RRDtool 的 Web 展现工具。

应用服务器的监控是被动的。整个监控系统模块化部署。Nagios 的警告信息转发到 Ywatch 中心控制台。

Note: 上面所有截图版权都属于 Ian (Image COPYRIGHT@IAN) 。如果去看那个 PDF 文件，你或许比我收获更多。我只是让你知道我的想法而已。

–EOF–

财帮子（caibangzi.com）网站架构

财帮子(caibangzi.com) 定位在”基金理财社区”。是国内访问量最大的基于 Ruby on rails 的 startup 项目。“理财”这个词据说是光大银行发明的，且不去管，不可否认的是，目前国内”理财”是个很有潜力的切入点。财帮子网站潜在用户群还是很大的。

1.创建人员

创建者有三人。Robin Lu(石锅拌饭)、Meng Yan ( 孟岩 ) ，还有一位”不写Blog的家伙”。前两位都是技术人员。很早就看过孟岩的 Blog，那时候他还在 Sun。Robin Lu 的 Blog 也一直在我的订阅列表中的，所以财帮子刚成立我就知道的。倒没有细问第三位是技术人员还是负责商务。(Updated: Robin Lu留言说”财帮子那位不写blog的创建者也是工程师，叫赵路，曾经是 Mozilla 项目accessibility模块的module peer.”

2.服务器信息

Web 服务器用的是 Lighttpd ，出于节省成本的目的，服务器是自行组装的。数据库采用的是 MySQL 5，目前还没有使用 Replication. 正准备扩充服务器，服务器数量…暂且保密一下。

3.统计分析及监控

统计分析采用 Google Analytics 和 Awstats 。目前 Alexa 排名是 2 万一点。监控工具用 monit，”以及自己写的一些分析 Proc 的脚本”，再有就是 Unix 性能工具等。(Fenng: 服务器处于规模化之前基本上要这个样子)。

4.优化之路

Robbin 在此前的一篇财帮子性能优化简报披露：“财帮子两个星期以前，遇到严重的性能问题，最终我们采用了相当非主流的部署方案和打了自己补丁的web server，成功度过了难关”，我很好奇这具体是个什么问题。得到的答案是：“Apache的负载均衡是有问题的，算法太简单了，对Ror的应用来说，会造成某一个app instance的阻塞，从而阻塞了所有的request”。

谈及 Cache 的感慨:

Fenng: ... 我个人感觉你们需要Cache服务器， 这一类的站点内容需要 Cache 的太多
Meng Yan: ...Web 2.0网站的 cache 非常重要。我们从Mem的cache，到disk的cache，
再到数据库的cache，架构还不错，否则当前机器撑不住 :)
Fenng: 很多站点扩展作不好，也是Cache没用好
Meng Yan: 是啊，Cache非常重要，非常非常
Fenng: 豆瓣的阿北说他们 Memcached 用的非常爽，命中率非常之高
Meng Yan: 确实，我们的内存cache就是用的memcached，真的很棒

5.挑战

这是就这次采访的最后一个问题。

Fenng:还要采访你一个问题：caibangzi.com 现在运营、开发面临的最大的一个问题是什么? 
Meng Yan:目前可能我们遇到最多的是合作、商务上的事情。真正开发、运营上来说对我们的挑战还不大。

6.后记

这次采访(如果可以说这是采访的话)非常顺利。财帮子从三月底上线，到现在已经积累了一定数量的用户，当然不是十全十美的(我个人就感觉应该提供更多的RSS输出才是，不要太在乎站点流量，流量本身也是开销)，网站也还有很长的路要走。真诚希望财帮子能成为更多人的理财工具(至少我已经开始用了)。

这是我第一次写国内 Web 2.0 网站架构技术。感谢 Meng Yan 提供的第一手信息。关于网站架构，我在这个 Blog 上写过不少国外的站点分析。一直想采访一些国内的 Web 2.0 站点并且能披露点技术信息，相对来说，国内站点还是比较保守，各自闷头折腾。为什么不换个角度，分享、借鉴、壮大，这个方式不也不错麽?

BTW: 如果你有 Web 2.0 站点技术信息要报料，联系我！(要写软文就免了)。

–EOF–