环境架设   /   108

关于本系列文章的说明:
原作者冯大辉(Fenng)在自己博文中声明《大型 Web2.0 站点构建技术初探 》一文系抄袭,查看声明请点击

我们都看到 Flickr 的成功,而又有多少”精英”们了解过 Flickr 背后的过程是多么充满艰险。

Flickr 是全 CGI 的动态构架,并以一种 .gne 的脚本作为 CGI 程序语言。不管网站制作菜鸟还是高手都会疑惑:gne 是哪种程序语言?答案:gne 不是一种语言,Flickr 是以极为经典的 PHP + MySQL 方式实现的,在被 Yahoo 收购服务器搬入美国之前,使用了 21 台(69.90.111.101-121) Apache/PHP 做 Web、23 台图片服务器、另有 MySQL 服务器组成的数据库集群的服务器数量未知。现在估计使用的是 Yahoo 的负载均衡系统,对外只有一个 Web 的 IP 和图片服务器的 IP 了。

那为何 .php 的文件要改成 .gne 呢?以往有大型网站为向后兼容性考虑,隐藏以程序语言命名的脚本文件扩展名,比如 Baidu 隐藏了 .php(Google 的 http 服务器是自己写的,整合了脚本程序,个别页面是 .py–Python);还有一些网站是改成自己网站名相关的扩展名,如 MSN 的群组则是 .msnw,榕树下是 .rs。

那 Flickr 的 gne 是什么意思?我在维基百科的 Flickr 条目上找到了答案(中文 Flickr 条目上没有写明) 。原来 GNE 是 Game NeverEnding 的缩写,Flickr 的开发者 Ludicorp 在 2002-2004 年一直在开发这套以 Game NerverEnding 为名称的大型多人在线角色扮演游戏–一套基于浏览器的 Web 游戏系统,个人以为应该就是当年九城的虚拟城市。但是开发近 3 年后该计划不得不破产,最终只发布了一个 Beta 版,而 Ludicorp 将这套系统稍加移植,就有了 Flickr。呵呵,原来 gne 是一个项目的名称。关于 GNE 的一些连接:http://del.icio.us/schee/gne

早期的 Flickr 想做成在类似聊天室的地方让网友分享、交流自己的照片,注重社区形式和保护照片不被外部引用,可能是看到了 Hello 的模式吧。但是聪明的 Flickr 团队不久就改变了策略,淡化了传统的社区形式–如聊天室、而加强了现在使其功成名就的 Tag 组织形式,一种更自由更随兴更轻松好玩的大社区形式,或者叫它广义社区吧,我随便叫的,可能太学究,看着别太在意就是了。另外,将原来照片只能在 Flash 内浏览的限制区除了,并大力推荐用户将照片引用到自己的 Blog,这无疑对于挑战传统相册系统有决定性意义。减少 Flash 后的网页更多地引进了新兴的 Ajax 技术,使界面操作变得非常 Cool。

这就是 Flickr 的历史,清晰地看到了他们对于优秀产品的执著。有了技术和经验积累,加上不断坚持,总有一天时来运转,你的产品会成为新潮流的里程碑。

还有一句话要告诉 Yupoo 等:把 Flickr 想成一个有 Tag 功能的在线相册就已经错远了;复制粘贴者们想当然将 Flickr 去其糟粕取其精华,结果无关紧要的拿来了,将令人激动的优点都去掉了,结果剩下什么?

在西雅图扩展性的技术研讨会上,YouTube 的 Cuong Do 做了关于 YouTube Scalability 的报告。视频内容在 Google Video 上有(地址),可惜国内用户看不到。

Kyle Cordes 对这个视频中的内容做了介绍。里面有不少技术性的内容。值得分享一下。(Kyle Cordes 的介绍是本文的主要来源)

简单的说 YouTube 的数据流量, “一天的YouTube流量相当于发送750亿封电子邮件.”, 2006 年中就有消息说每日 PV 超过 1 亿,现在? 更夸张了,”每天有10亿次下载以及6,5000次上传”, 真假姑且不论, 的确是超乎寻常的海量. 国内的互联网应用,但从数据量来看,怕是只有 51.com 有这个规模. 但技术上和 YouTube 就没法子比了.

1. Web 服务器

YouTube 出于开发速度的考虑,大部分代码都是 Python 开发的。Web 服务器有部分是 Apache, 用 FastCGI 模式。对于视频内容则用 Lighttpd 。据我所知,MySpace 也有部分服务器用 Lighttpd ,但量不大。YouTube 是 Lighttpd 最成功的案例。(国内用 Lighttpd 站点不多,豆瓣用的比较舒服。by Fenng)

2. 视频

视频的缩略图(Thumbnails)给服务器带来了很大的挑战。每个视频平均有4个缩略图,而每个 Web 页面上更是有多个,每秒钟因为这个带来的磁盘 IO 请求太大。YouTube 技术人员启用了单独的服务器群组来承担这个压力,并且针对 Cache 和 OS 做了部分优化。另一方面,缩略图请求的压力导致 Lighttpd 性能下降。通过 Hack Lighttpd 增加更多的 worker 线程很大程度解决了问题。而最新的解决方案是起用了 Google 的 BigTable,这下子从性能、容错、缓存上都有更好表现。看人家这收购的,好钢用在了刀刃上。

出于冗余的考虑,每个视频文件放在一组迷你 Cluster 上,所谓 “迷你 Cluster” 就是一组具有相同内容的服务器。最火的视频放在 CDN 上,这样自己的服务器只需要承担一些”漏网”的随即访问即可。YouTube 使用简单、廉价、通用的硬件,这一点和 Google 风格倒是一致。至于维护手段,也都是常见的工具,如 rsync, SSH 等,只不过人家更手熟罢了。

3. 数据库

YouTube 用 MySQL 存储元数据–用户信息、视频信息什么的。数据库服务器曾经一度遇到 SWAP 颠簸的问题,解决办法是删掉了 SWAP 分区! 管用。

最初的 DB 只有 10 块硬盘,RAID 10 ,后来追加了一组 RAID 1。够省的。这一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,参见这里). 在扩展性方面,路线也是和其他站点类似,复制,分散 IO。最终的解决之道是”分区”,这个不是数据库层面的表分区,而是业务层面的分区(在用户名字或者 ID 上做文章,应用程序控制查找机制)

YouTube 也用 Memcached.

很想了解一下国内 Web 2.0 网站的数据信息,有谁可以提供一点 ?

网络发现者(aiwei.us)是梁道科技旗下以企业建站,微信开发,视觉设计为主要服务项目的互联网品牌。

我们为企业提供各类互联网平台项目的咨询顾问服务。依靠丰富的互联网实践经验,我们为企业从项目可行性分析,执行策略及方案等方方面面提供合理化建议。