Yupoo! 的网站技术架构

Yupoo! 的网站技术架构
作者:Fenng | 可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明
网址:http://www.dbanotes.net/arch/yupoo_arch.html
又有机会爆料国内 Web 2.0 网站的架构了。这次是 Yupoo! 。非正式的采访了一下Yupoo!(又拍网) 的创建人之一的阿华（沈志华）同学，了解了一些小道消息。
作为国内最大的图片服务提供商之一，Yupoo! 的 Alexa 排名大约在 5300 左右。同时收集到的一些数据如下：
带宽：4000M/S (参考)
服务器数量：60 台左右
Web服务器：Lighttpd, Apache, nginx
应用服务器：Tomcat
其他：Python, Java, MogileFS 、ImageMagick 等
首先看一下网站的架构图：

该架构图给出了很好的概览(点击可以查看在 Yupoo！ 上的大图和原图，请注意该图版权信息)。
关于 Squid 与 Tomcat
Squid 与 Tomcat 似乎在 Web 2.0 站点的架构中较少看到。我首先是对 Squid有点疑问，对此阿华的解释是"目前暂时还没找到效率比 Squid 高的缓存系统，原来命中率的确很差，后来在 Squid 前又装了层Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去，所以命中率彻底提高了"
对于应用服务器层的 Tomcat，现在 Yupoo! 技术人员也在逐渐用其他轻量级的东西替代，而 YPWS/YPFS 现在已经用 Python 进行开发了。
名次解释：
YPWS--Yupoo Web Server YPWS 是用 Python开发的一个小型 Web 服务器，提供基本的 Web 服务外，可以增加针对用户、图片、外链网站显示的逻辑判断，可以安装于任何有空闲资源的服务器中，遇到性能瓶颈时方便横向扩展。
YPFS--Yupoo File System 与 YPWS 类似，YPFS 也是基于这个 Web 服务器上开发的图片上传服务器。
【Updated: 有网友留言质疑 Python 的效率，Yupoo 老大刘平阳在 del.icio.us 上写到 "YPWS用Python自己写的，每台机器每秒可以处理294个请求, 现在压力几乎都在10％以下"】图片处理层
接下来的 Image Process Server 负责处理用户上传的图片。使用的软件包也是ImageMagick，在上次存储升级的同时，对于锐化的比率也调整过了(我个人感觉，效果的确好了很多)。”Magickd“是图像处理的一个远程接口服务，可以安装在任何有空闲 CPU资源的机器上，类似 Memcached的服务方式。
我们知道 Flickr 的缩略图功能原来是用 ImageMagick 软件包的，后来被雅虎收购后出于版权原因而不用了（?）；EXIF 与 IPTC Flicke 是用 Perl 抽取的，我是非常建议 Yupoo! 针对 EXIF 做些文章，这也是潜在产生受益的一个重点。
图片存储层
原来 Yupoo! 的存储采用了磁盘阵列柜，基于 NFS方式的，随着数据量的增大，”Yupoo! 开发部从07年6月份就开始着手研究一套大容量的、能满足 Yupoo!今后发展需要的、安全可靠的存储系统“，看来 Yupoo! 系统比较有信心，也是满怀期待的，毕竟这要支撑以 TB计算的海量图片的存储和管理。我们知道，一张图片除了原图外，还有不同尺寸的，这些图片统一存储在 MogileFS 中。
对于其他部分，常见的 Web 2.0 网站必须软件都能看到，如 MySQL、Memcached 、Lighttpd 等。Yupoo!一方面采用不少相对比较成熟的开源软件，一方面也在自行开发定制适合自己的架构组件。这也是一个 Web 2.0 公司所必需要走的一个途径。
非常感谢一下 Yupoo! 阿华对于技术信息的分享，技术是共通的。下一个能爆料是哪家?
--EOF--
这篇 【Yupoo! 的网站技术架构 】来自dbanotes.net | del.icio.us |雅虎收藏+
ByFenng on January 26, 2008 9:51 PM|Permalink |TrackBacks (0) |Arch|Edit
ShareThis
0 0 0 0

ClickComments: 点击评论
|



很有趣

Generator |Trampoline |外贸英才网 |Vinyl fence
Vertical Packaging Machine |Digital Blood Pressure Monitor

自定义搜索
本文相关评论|Comments(15)
yzx110 的评论:
这个。。。。
说的意犹未尽啊，
能打听到一些关键的技术信息就好了，呵呵
感觉架构复杂了点，怎么squid前又是lightppd，然后又是apache。
January 26, 2008 11:22 PM
hushuobadao 的评论:
squid在web2.0中有大规模的应用，flickr在用,wikipedia在用。。国内门户就不用说了。。是一个很常见的web前端加速缓存。。
python写的ws因为脚本语言的动态特性，内存的管理对于性能和可靠性都不是很理想，不知道有没有经常崩掉的。。。
除了带宽最好有一些日pv和uip的参数。。（aleax不靠谱）前端的req/s很重要。。对架构影响大。。
疑问在有了lvs四层交换后，nginx的七层交换是不是有点多余？如果否，那么此处的nginx干嘛使？
应用层是java的，估计逃不出tomcat吧。。。
为保证squid命中率，为啥不用nginx?lighttpd毕竟是单进程的，好崩掉？而且nginx的规则也好写。。
January 26, 2008 11:39 PM
http://www.openidfrance.fr/gaopengbo 的评论:
写的太深奥，不是很懂。
January 27, 2008 2:11 AM
徐林 的评论:
Web 2.0还未正式出来
就已经是风雨满天下了
我还是玩我的博客好了
January 27, 2008 7:26 AM
Horus Lee 的评论:
Fenng大，用纯Python写的Web Server？效率会不会是个问题呢？还是仅仅作为一个客户和后端服务器的一个中间层？
January 27, 2008 10:02 AM
草根网 的评论:
好文，收藏至20ju.com
January 27, 2008 12:01 PM
css 的评论:
网站那么烂 后台架构再好有什么用
January 27, 2008 12:30 PM
东东 的评论:
图片索引和权限控制能介绍下就更好了
January 27, 2008 1:10 PM
小说家文学网 的评论:
大型网站的技术架构的确好庞大
January 27, 2008 7:21 PM
FinalBSD 的评论:
URL Hash扩展性很差吧，增、减服务器要重新hash，Yupoo是怎么解决此问题的
ImageMagick处理图片也是很耗CPU的，不知道是怎么处理的，是即时还是队列的模式
January 27, 2008 10:53 PM
阿华 的评论:
有这么多的朋友关心，谢谢大家。
lighttpd+squid这套缓存是放在另外一个机房作为cdn的一个节点使用的，图中没描绘清楚，给大家带来不便了。
squid前端用lighttpd没用nginx，主要是用了这么久，没出啥大问题，所以就没想其他的了。
URL Hash的扩展性的确不好，能做的就是不轻易去增减服务器，我们目前是5台服务器做一组hash.
我们现在用Python写的Web Server，在效率方面，我可以给个测试数据，根据目前的访问日志模拟访问测试的结果是1台ypws,平均每秒处理294个请求(加载所有的逻辑判断)。
在可靠性上，还不没具体的数据，目前运行1个多月还没有任何异常。
lvs每个节点上都装nginx，主要是为了反向代理及处理静态内容，不过apache已显得不是那么必需，准备逐渐去掉。
我们处理图片都是即时的，我们目前半数以上的服务器都装了magickd服务，用来分担图片处理请求。
January 28, 2008 11:58 AM
weavesky.com 的评论:
不太明白
nginx都有loadbalance，为什么tomcat前面还要加apache
而memcached为什么在tomcat和db&mogilefs的中间，难道应用还穿过memcached去访问db，应该在侧边才对吧
squid hash我觉得应该在域名上做手脚，而不是url上做，也不需要lighttpd在squid前面
而且图片第一次输出是用tomcat的？图片本来抽出来直接squid-lighttpd-mogilefs就行了，现在load一个图片要LVS-Lighttpd-Squid-LVS-Nginx-Apache-Tomcat-Memcached?-MogileFS
January 30, 2008 3:54 PM
阿华 的评论:
@weavesky
有些功能目前还需要使用apache，不过已显得不是那么必需，准备逐渐去掉。
关于memcached，想表达的意思的memcached下面所有的内容，能缓存的都存储在memecached中，目前用到memcached的应用有tomcat、ypws、ypfs。描图时没能表达清楚，见谅。
至于squid hash还是通过域名实现，我觉得没有哪个好哪个差，结合实际的应用选择合适的就是好的
load图片是通过ypws展现的。 Nginx-ypws-MogileFS，前端再加个squid缓存。
January 31, 2008 8:55 AM
阿关 的评论:
阿华你好，希望尽快收到你的回复，谢谢。
看到图介绍的，你们存储使用的mogilfs。后面描述中说到，是自己又开发一套。
很想知道你们大容量存储这块，如何解决的。mogilefs不适合随时读写吧。
June 12, 2008 6:48 PM
阿华 的评论:
阿关,mogilefs比较适合管理不需要修改的小文件(
关于大容量储存，由于mogilefs目前是单库单表模式，很多应用受到限制，如：多机房部署、表记录达到几十亿时的性能等，所以我们开发一套比较适合自己网站架构的分布式存储系统，利用mogilefs作为存储介质，mogilefs可以无限制的横向扩充，不需要再去担心mogilefs的性能问题
June 12, 2008 10:48 PM