Yupoo! 的网站技术架构

最新推荐文章于 2024-08-28 16:14:15 发布

anghlq

最新推荐文章于 2024-08-28 16:14:15 发布

阅读量1.5k

点赞数

分类专栏：程序设计 WEB编程文章标签： lighttpd apache python web服务服务器 google

程序设计同时被 2 个专栏收录

125 篇文章 0 订阅

订阅专栏

WEB编程

59 篇文章 0 订阅

订阅专栏

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--

、、、、、、、、、、、、、、、、、、、、、、

有这么多的朋友关心，谢谢大家。

lighttpd+squid这套缓存是放在另外一个机房作为cdn的一个节点使用的，图中没描绘清楚，给大家带来不便了。
squid前端用lighttpd没用nginx，主要是用了这么久，没出啥大问题，所以就没想其他的了。
URL Hash的扩展性的确不好，能做的就是不轻易去增减服务器，我们目前是5台服务器做一组hash.

lvs每个节点上都装nginx，主要是为了反向代理及处理静态内容，不过apache已显得不是那么必需，准备逐渐去掉。

我们处理图片都是即时的，我们目前半数以上的服务器都装了magickd服务，用来分担图片处理请求。

Squid缓冲服务，可能是代理服务器，或者搜索引擎的快照

Squid是一种用来缓冲Internet数据的软件。它是这样实现其功能的，接受来自人
们需要下载的目标（object）的请求并适当地处理这些请求。也就是说，如果一个人想
下载一web页面，他请求Squid为他取得这个页面。Squid随之连接到远程服务器（比如
：http：//squid.nlanr.net/）并向这个页面发出请求。然后，Squid显式地聚集数据
到客户端机器，而且同时复制一份。当下一次有人需要同一页面时，Squid可以简单地
从磁盘中读到它，那样数据迅即就会传输到客户机上。当前的Squid可以处理HTTP，FT
P，GOPHER，SSL和WAIS等协议。但它不能处理如POP，NNTP，RealAudio以及其它类型的以及其它类型的
东西。

Nginx ("engine x") 是一个高性能的 HTTP 和反向代理服务器，也是一个 IMAP/POP3/SMTP 代理服务器。

Lighttpd是一个德国人领导的开源软件，其根本的目的是提供一个专门针对高性能网站，安全、快速、兼容性好并且灵活的web server环境。具有非常低的内存开销，cpu占用率低，效能好，以及丰富的模块等特点。lighttpd是众多 OpenSource轻量级的web server中较为优秀的一个。支持 FastCGI, CGI, Auth, 输出压缩(output compress), URL重写, Alias等重要功能，而 Apache之所以流行，很大程度也是因为功能丰富，在lighttpd上很多功能都有相应的实现了，这点对于apache的用户是非常重要的，因为迁移到lighttpd就必须面对这些问题。

LVS是一个开源的软件,可以实现LINUX平台下的简单负载均衡。

双机集群(HA)系统
LATCH HA 是X0;linux Latch 系列的高可靠性的服务器集群系统解决方案。

Lighttpd+Squid+Apache搭建高效率Web服务器

davies 发表于 2006 年 09 月 9 日

架构原理

Apache通常是开源界的首选Web服务器，因为它的强大和可靠，已经具有了品牌效应，可以适用于绝大部分的应用场合。但是它的强大有时候却显得笨重，配置文件得让人望而生畏，高并发情况下效率不太高。而轻量级的Web服务器Lighttpd却是后起之秀，其静态文件的响应能力远高于Apache，据说是Apache的2-3倍。Lighttpd的高性能和易用性，足以打动我们，在它能够胜任的领域，尽量用它。Lighttpd对PHP的支持也很好，还可以通过Fastcgi方式支持其他的语言，比如Python。

毕竟Lighttpd是轻量级的服务器，功能上不能跟Apache比，某些应用无法胜任。比如Lighttpd还不支持缓存，而现在的绝大部分站点都是用程序生成动态内容，没有缓存的话即使程序的效率再高也很难满足大访问量的需求，而且让程序不停的去做同一件事情也实在没有意义。首先，Web程序是需要做缓存处理的，即把反复使用的数据做缓存。即使这样也还不够，单单是启动Web处理程序的代价就不少，缓存最后生成的静态页面是必不可少的。而做这个是 Squid的强项，它本是做代理的，支持高效的缓存，可以用来给站点做反向代理加速。把Squid放在Apache或者Lighttpd的前端来缓存 Web服务器生成的动态内容，而Web应用程序只需要适当地设置页面实效时间即可。

即使是大部分内容动态生成的网站，仍免不了会有一些静态元素，比如图片、JS脚本、CSS等等，将Squid放在Apache或者Lighttp前端后，反而会使性能下降，毕竟处理HTTP请求是Web服务器的强项。而且已经存在于文件系统中的静态内容再在Squid中缓存一下，浪费内存和硬盘空间。因此可以考虑将Lighttpd再放在Squid的前面，构成 Lighttpd+Squid+Apache的一条处理链，Lighttpd在最前面，专门用来处理静态内容的请求，把动态内容请求通过proxy模块转发给Squid，如果Squid中有该请求的内容且没有过期，则直接返回给Lighttpd。新请求或者过期的页面请求交由Apache中Web程序来处理。经过Lighttpd和Squid的两级过滤，Apache需要处理的请求将大大减少，减少了Web应用程序的压力。同时这样的构架，便于把不同的处理分散到多台计算机上进行，由Lighttpd在前面统一把关。

在这种架构下，每一级都是可以进行单独优化的，比如Lighttpd可以采用异步IO方式，Squid可以启用内存来缓存，Apache可以启用MPM 等，并且每一级都可以使用多台机器来均衡负载，伸缩性很好。

实例讲解

下面以daviesliu.net和rainbud.net域下面的几个站点为例来介绍一下此方案的具体做法。daviesliu.net域下有几个用 mod_python实现的blog站点，几个php的站点，一个mod_python的小程序，以后可能还会架设几个PHP和Django的站点。而服务器非常弱，CPU为Celeron 500，内存为PC 100 384M，因此比较关注Web服务器的效率。这几个站点都是采用虚拟主机方式，开在同一台机器的同一个端口上。

Lighttpd服务于80端口，Squid运行在3128端口，Apache运行在81端口。

Lighttpd的配置

多个域名采用/var/www/domain/subdomain 的目录结构，用evhost模块配置document-root如下：

evhost.path-pattern = var.basedir + "/%0/%3/"

FtpSearch中有Perl脚本，需要启用CGI支持，它是用来做ftp站内搜索的，缓存的意义不大，直接由lighttpd的mod_cgi处理：

$HTTP["url"] =~ "^/cgi-bin/" { # only allow cgi's in this directory
dir-listing.activate = "disable" # disable directory listings
cgi.assign = ( ".pl" => "/usr/bin/perl", ".cgi" => "/usr/bin/perl" )
}

bbs使用的是phpBB，访问量不大，可以放在lighttpd(fastcgi)或者apache(mod_php)下，暂时使用 lighttpd，设置所有.php的页面请求有fastcgi处理：

fastcgi.server = ( ".php" => ( ( "host" => "127.0.0.1", "port"=> 1026, "bin-path" => "/usr/bin/php-cgi" ) ) )

blog.daviesliu.net 和 blog.rainbud.net 是用mod_python编写的blogxp程序，所有静态内容都有扩展名，而动态内容没有扩展名。blogxp是用python程序生成XML格式的数据再交由mod_xslt转换成HTML页面，只能放在Apache下运行。该站点采用典型Lighttpd+Squid+Apache方式处理：

$HTTP["host"] =~ "^blog" {
    $HTTP["url"] !~ "/." {
        proxy.server = ( "" => ( "localhost" => ( "host"=> "127.0.0.1", "port"=> 3128 ) ) ) #3128端口为
    }
}

share中有静态页面，也有用mod_python处理的请求，在/cgi/下：

$HTTP["host"] =~ "^share" {
    proxy.server = (
        "/cgi" => ( "localhost" => ( "host"=> "127.0.0.1", "port"=> 3128 ) )
    )
}

Squid的配置

只允许本地访问：

http_port 3128
http_access allow localhost
http_access deny all

启用反向代理：

httpd_accel_host 127.0.0.1
httpd_accel_port 81 #apache的端口
httpd_accel_single_host on
httpd_accel_with_proxy on #启用缓存
httpd_accel_uses_host_header on #启用虚拟主机支持

此方向代理支持该主机上的所有域名。

Apache的配置

配置/etc/conf.d/apache2，让其加载mod_python、mod_xslt、mod_php模块：

APACHE2_OPTS="-D PYTHON -D XSLT -D PHP5"

所有网站的根目录：

<Directory "/var/www">
   AllowOverride All     #允许.htaccess覆盖
    Order allow,deny
    Allow from all
</Directory>

基于域名的虚拟主机：

<VirtualHost *:81>
ServerName blog.daviesliu.net
DocumentRoot /var/www/daviesliu.net/blog
</VirtualHost>

这里明显没有lighttpd的evhost配置方便。

blog.daviesliu.net下的.htaccess设置(便于开发，不用重启Apache):

SetHandler mod_python
PythonHandler blogxp.publisher
PythonDebug On
PythonAutoReload On

<FilesMatch "/.">
    SetHandler None        #静态文件直接由Apache处理
</FilesMatch>

<IfModule mod_xslt.c>
    AddType text/xsl .xsl #防止对xsl文件进行转化
    AddOutputFilterByType mod_xslt text/xml
    XSLTCache off
    XSLTProcess on
</IfModule>
Header set Pragma "cache"
Header set Cache-Control "cache"

在blogxp.publisher里面，还需要设置返回的文档类型和过期时间：

req.content_type = "text/xml"
req.headers_out['Expires'] = formatdate( time.time() + 60 * 5 )

经过这样的配置，所有站点都可以通过80、3128、81三个端口进行正常访问，80端口用作对外的访问，以减少负荷。81端口可以用作开发时的调试，没有缓存的困扰。

性能测试

由于时间和精力有限，下面只用ab2做一个并不规范的性能对比测试(每项都测多次取平均)，评价指标为每秒钟的请求数。
测试命令,以测试lighttpd上并发10个请求 scripts/prototype.js 为例：

ab2 -n 1000 -c 10 http://blog.daviesliu.net:80/scripts/prototype.js

静态内容：prototype.js (27kB)

Con	Lighttpd(:80)	Squid(:3128)	Apache(:81)
1	380	210	240
10	410	215	240
100	380	160	230

可见在静态内容上，Lighttpd表现强劲，而Squid在没有配内存缓存的情况下比另两个Web服务器的性能要差些。

动态页面：/rss (31kB)

Con	Lighttpd(:80)	Squid(:3128)	Apache(:81)
1	103	210	6.17
10	110	200	6.04
100	100	100	6.24

在动态内容上，Squid的作用非常明显，而Lighttpd受限于Squid的效率，并且还要低一大截。如果是有多台Squid来做均衡的话，Lighttpd的功效才能发挥出来。
在单机且静态内容很少的情况下，可以不用Lighttpd而将Squid置于最前面

anghlq

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Yupoo! 的网站技术架构

Yupoo! 的网站技术架构作者: Fenng | 可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明网址: http://www.dbanotes.net/arch/yupoo_arch.html 又有机会爆料国内 Web 2.0 网站的架构了。这次是 Yupoo! 。非正式的采访了一下 Yupoo!(又拍网) 的创建人之一的
复制链接

扫一扫

专栏目录