原贴:http://www.dbanotes.net/arch/imobile_web_arch_gaochunhui.html

手机之家网站架构--对话高春辉

作者: Fenng | 可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明
网址: http://www.dbanotes.net/arch/imobile_web_arch_gaochunhui.html

这次去北京参加 CSDN SD 2.0 ，没发现高春辉的身影，原来是忙着做手机之家的架构升级呢。

从老高的近期工作总结中看到：

目前的技术状况是基于自行设计的 PHP 框架，跑在 PHP 5.2 + MySQL 5.1 下，PHP 使用 Fastcgi 模式，WebServer 选择了 Nginx。搜索功能基于 Lucene 开发。缓存代理使用 Varnish。

对老高进行了一次非正式采访，聊了不少内容，整理了一下和大家分享。(谁是高春辉? 这个不要介绍了吧，请 Google! )

1) 历史情况

Fenng: 原来大约是用什么? 框架用的什么？
高春辉: 你说老系统？Apache 1.3 , DB 是 MySQL 4.0。新框架是团队自己写的，定制了一些东西吧，主要强调的是性能和方便、简单。另外把针对 YSlow 的优化也做进去了。
Fenng: 单说现在用的框架，大约投入了多少个人/天 ?
高春辉: 从全年开始考虑写，一直不断的写 -- 具体时间不好说。反正是不少了 :)
Fenng: 看了你 Blog 中的描述，有个小疑惑：没使用面向 DB 的 Cache 层?
高春辉: 我文中说的 Data accessor 就算是了。目前是拿 PHP 做的，Client+Server 集成在一起。后面第二期准备拿 Java 来写 Server 端。

2) 遭遇 PHP Bug

Fenng: 你提到的 502 错误不会是 PHP Fastcgi 内存爆了的原因吧？
高春辉: 不是，是 PHP 和 APC Bug 的问题。换新版就好了，你可以看 PHP 5.2.7 的 Buglist。里面列了一个在 Fastcgi 下父进程不能执行 shutdown module 方法的问题。主要是这个原因。APC 也有问题，它的Lock在大并发下非常容易挂掉。换上还没发布的测试版就好了。现在挺稳定的。一台机器跑了700万次请求了。
Fenng: 你遇到的是这个问题吧? Bug 45423
高春辉: Yes Here is the APC bug link : http://pecl.php.net/bugs/bug.php?id=5280 还附带这个问题。当时发现原因之后，非常郁闷，呵呵。
Fenng: 现在用 5.2.8 了?
高春辉: 嗯。5.2.7/5.2.8 反正没啥区别，就修正了一个bug。

3) DB 压力

Fenng: "原有的两台数据库平均总和超过 2000QPS 的查询次数，目前仅有 150+150+250= 550QPS 左右了" 这个 150+150+250 怎么来得？三台？
高春辉: 现在变成三台机器了 :)
Fenng: 哈
高春辉: 是原来的 1/4 吧。
Fenng: 你 Blog 中提到 "由于新系统未经大规模流量实际验证，即使再有信心", 前面有没有做过压力测试?
高春辉: 做过，但是那个问题不是马上就暴露的。而是要运行一段时间才会出。所以我强调的是实际验证。

4) 过程挑战

Fenng: 问个比较俗的事儿,最近一段时间给你压力最大的事儿是啥？招聘？项目发布？
高春辉: 人!
Fenng: 人员协调？还是人力招聘？
高春辉: 人永远是问题，好的人不够用，差一点的人不想用，呵呵。
Fenng: 国内 PHP 好手还是太少吧？
高春辉: 嗯。太多人缺乏对大规模的研究和实践了。而且这次有些思路的转变是对 Java 的引入。之前是考虑 99% PHP 实现。现在考虑 PHP 只做前端。JAVA 做服务器后端。这样混合编程才算是比较发挥各自的优势。
Fenng: 你们有很多事务的东西？
高春辉: 不是事务多，而是 PHP 本身就不适合做服务器端的内容。包括性能也很慢。比如开始发给你的链接(Fenng 注：之前发给我一个 Session 信息统计的地址)，那个 Session Server 就是拿 Java 做的。之前 PHP 的版本，一次请求要两位数(ms)以上，现在一次只要1.5ms，差距很大。

5) 再说网站架构

Fenng:提供给我一份网站架构拓扑图吧 ?
高春辉:这是实际的，包括 IP 了,供参考吧:

Fenng: 你们网站规模都这么大了!
高春辉: (笑)

Fenng: 考虑到安全问题，我只把缩略图放到网站上吧。估计没人能看清楚 :)
高春辉: 好。我们目前还是做了一些感觉比较不错的小东西的。比如 Data accessor、Session server、YUI compress server 等等吧。
Fenng: YUI compress server 应该是借鉴了 Yahoo YUI, 然后针对静态文件进行压缩的吧？
高春辉: 就是用 YUI Compressor 做的，只是做成了一个 Daemon 服务，而不是命令行的方式来处理。
Fenng: Data accessor 或者其他组件是否准备开源?
高春辉: 关键是只有到规模才需要它。恐怕大部分网站还是觉得麻烦得多吧。
Fenng: 统计分析和监控也是自己写程序？
高春辉: 那倒还没来得及下大功夫，只是做了一些简单的脚本。

6) 图片处理问题

Fenng: 提一个小建议：我发现主题频道这里的图片仍然有拉伸，我个人觉得拉伸是网站必须要慎重对待的问题，用户体验非常不好。
高春辉: 应该是 Imagemagick 使用的问题。我还在继续修正，不过相信不是大问题。
Fenng: 这么说图片处理用了 Imagemagick ?
高春辉: 嗯。有图形处理后端 Server。

高春辉: 你可以看看手机之家论坛(http://bbs.imobile.com.cn/)的页面源代码...
Fenng: 现在(网站)的速度可真不是一般的快...YSlow 上的表现惊人, 差不多是国内网站我看到的最高分了。
高春辉: 其实全都都是动态请求，包括你看到的任何一个图片/JavaScript/CSS ...
Fenng: 你们的图片都是如何处理的？我看到似乎是动态拿过来？在DB里？然后Cache到缓存里么？
高春辉: 全部放到数据库里。作为备份。你在前台看到的都是动态处理的，通过 ID 进行关联。前面有两级缓存。数据库的内容相当于备份。这么做的我认为的好处是不用备份上百万个小文件了。而只是备份几百个大文件就行了。速度会提高非常多；而且那种静态损坏的几率就没有了，因为数据库本身会做数据的校验，我们也都保留的验证数据。

Fenng: 这是个反潮流的做法啊,我的猜测是每天数据量变化不大？
高春辉: 目前一天顶多也就是几百兆的增加，应该是可以承受的。而且即使量大也没关系，我可以具体到一个表拆到一个机器上跑。
Fenng: 可这样的话 EXIF 信息就不用了？
高春辉: 所有的信息都可以有一个 Metainfo 表进行保存。而且可以从新生成，假设你的文件信息解析程序有更新的话。
Fenng: 这是我这几年来看到的第一例。不过合适就好。
高春辉: Metainfo表,当然也可以由各应用自己解析自己保存。目前 FileStorage 已经保存了 1.1TB 的文件数据了。当前拆成了 256 个小表，每个表4G左右大小。
Fenng: 文件层用什么文件系统？XFS?
高春辉: 数据库都是 CentOS 5.2 64 bit 的系统。文件系统用 Ext3。其实没你想像的那么大的 I/O 压力，只要两级缓存有了。根本到不了数据库这里。而且前端的两级缓存都是可以多台机器一起跑冗余的。
只要配置就行了。以后备份和故障恢复也很简单。
Fenng: 这一点很有趣。突破传统思维 :)
高春辉: 也是基于之前的教训而琢磨的方法，呵。