点滴之间 聚沙成金

经典web架构.doc

从最大盗版源之一的百度的文库里下载的一篇文章，很不错，值得参考。向原作者致敬，也向发此文档的同学表感谢。

下面是纯文字版，完整版（带图片）参看上面附件。

——————————————————————————–

 

 

这个架构的特点和一些流程的说明：

 

1、主域名和图片域名分离

域名分离可以使流量分离，缓存策略分离等等，好处诸多。bbs初期一定要做好规划，将图片用另外的域名独立服务，即使没有足够机器，域名也要先分开。另外，图片服务器可以使用有别于主域名的另一个域名，一个好处是可以减少读取cookie对图片服务器的压力，另一个是提高安全性，避免cookie泄露。

 

2、使用LVS作为前端、二级代理和数据库的访问入口

使用LVS作为入口，比其他任何一种方式都来得更优质。首先LVS的负载能力很强，因为它工作在网络协议的第4层，使用虚拟ip技术，所以它本身并不担负任何流量的处理，仅仅是一个封包转发的功能；第二，LVS的配置相对简单而且稳定，一般去调整的几率比较低，也减少了因人为等因素而出现故障；第三，LVS可以处理任何端口的负载均衡，所以它基本可以做所有服务的负载均衡和容错。在这个架构中，除了处理http的80端口之外，LVS也处理了数据库mysql的3306端口，在数据库这个应用中是采用的双机热备策略。

 

3、使用nginx+squid作为最前端的缓存组合

在这个架构中，是最能体现app_nginx_squid_nginx架构的优势的。在这个架构中的bbs运行在缓存上，用户每发布一张帖子，都需要使用purge指令清除该帖子的缓存，如果是squid在最前端，那么每次发布一张帖子，都需要在所有的squid中调用purge指令，这样在机器比较多的时候，purge将成为一个巨大的压力。

所以在这里将nginx放在最前端并使用手工url_hash的方式分流，将经常需要purge的帖子页面和列表页面按一个url对应一台squid的策略，分布到各台squid上，并提供了一台或一组backup的squid，个别squid出现异常时将自动使用backup的机器继续提供一段时间的服务直到其正常。在这样的架构下，purge就不再是关键问题，因为一个url只会对应到一台机器上，所以purge的时候，后端app_server找到对应的机器就可以了。

可以看到在前端中还有一台nginx(purge)的机器，这台机器是专用于purge的，只要发送purge指令和需要清除的url到这台机器，就可以找到相应的服务器并清除缓存了。另外，purge时还需要清理backup机器上的缓存，所以无论前端机器增加到多少，purge指令只会在2台机器上执行，如果backup机器使用到2-3台，purge指令就会在3-4台机器上执行，仍然在可接受范围之内。

nginx作为前端，另有的好处：

1)        使用nginx的日志统计点击量非常方便

2)        nginx也可作为缓存，一般可以直接负责favicon.ico和logo等固定的小图片

 

4、基于nginx的中层代理

nginx中层代理的优势，在：

nginx和squid配合搭建的web服务器前端系统

这篇文章中有解释。

在这个架构中，假如后端的app_server上把帖子页和列表页直接生成了静态页面，那么使用中层代理再做一次url_hash，将可以解决后端app_server的硬盘容量的压力，但是如果使用到url_hash的话，那做容错就相对麻烦了。所以建议不要采用生成静态页的方式，后端的压力一般不会非常的大，所以没有必要生成静态页。假如前端squid的命中率实在太低下，造成大量穿透，可以考虑使用二级代理暂顶。

5、基于LVS的数据库双机热备

在这个架构中，因为大量的并发和访问量都由前端的缓存处理掉了，所以后端的mysql主要压力来自于数据的写入，所以压力并不是非常大，并且负载比较稳定，一般不会随着访问量上升而提高过快，估计目前一台64位的机器，加满内存并使用高速的硬盘，前端负载数亿访问量时数据库都不会出现性能问题。在数据库这方面应主要考虑故障恢复，因为数据库崩溃的话，按照一般使用备份恢复的做法，耗时很长而且难免丢失数据，是很棘手的问题。使用双机热备的方案，出现故障时首先可由一台时刻同步着的备用数据库即刻充当主数据库，然后卸下的数据库可以有充分的时间对其进行维修，所以是个很安全有效的办法。

当然，数据库的优化还是要细心做的，参考：

mysql性能的检查和调优方法

细心地调一遍，性能会好很多。

 

6、图片服务器

图片服务器我在这个架构中没有特别详细的介绍，在大型的bbs系统下，图片常常会出现容灾现象——图片数量严重超过了单台前端服务器容纳能力，导致前端服务器命中率低下。处理容灾问题也是非常棘手的，往后会有更详细的介绍。

 

7、简单的点击量统计办法

1)        1/使用js的script标签访问另一（台）组服务器的空文件，然后定期向数据库更新

2)        2/在前端的nginx上直接开启日志功能，按需要统计点击量的链接规则进行记录，然后定期更新数据库

 

——————————————————————————–

当前比较适用的海量小文件系统架构方案

[2010-04-13 11:10:14]

——————————————————————————–

现在的网站越做越大了，存储的东西越来越多，如何解决这些文件存储也成了新的难题。如果把这些文件都完全采用大硬盘存储来解决，并不是一个好主意，因为数据量越大风险就越高，虽然文件能存得下，但是故障率相应会较高，另外重建耗费时间也比较长。所以最好的办法是尽可能考虑分布式存储，把文件想办法利用网络分散到多个机器上。

从我所了解的存储结构来看，分布式存储大致可以分为几种：

 

1、类googlefs的分布式文件系统

因为目前googlefs没有开源，所以网上出现的分布式文件系统都是利用google的方案自行实现的。这个方案的优点是可用性比较高，基本上基于硬盘的应用都可以处理，可用范围就比较广泛。我看了gfs、gfs2、ocfs2、FastDFS、MogileFS的一些相关介绍，大致有一些认识。

首先是文档比较少而出现的问题倒不少；然后是目前这些还没有一个能称得上是稳定版本，如果有的话，估计也就是其中一些收费的版本。因为磁盘存储乃是致关重要，所以目前建议还是不要轻易把这些东西部署到重要的地方。假如非常想使用的话，最好是做好充分测试，确保它的功能完全能够满足需要；然后还要想办法在传统的文件系统中做好完全的备份，以免造成损失。

另外可以提的一个东西是memcached，这个东西实现了内存的分布式共享，稳定度貌似比以上这些分布式文件系统要稳定。不过是完全基于内存的，如果数据量不是很大，可以一试。

 

2、手工使用文件路径分散存储

这个结构通常使用在web静态文件中，就以这种情形作为例子。

如果这些文件数量比较大，可以通过分散文件路径，把某个文件的访问指定到特定的一台或几台服务器上。例如：

 

1)采用域名的分散策略

例如使用a.xxx.com/b.xxx.com…来区分标记为a或b的一系列文件，这些文件存储的时候，依然按照标记，存到a或b的服务器上。这个策略将区分机器的任务交由dns服务器来执行，扩容时会相应轻松。这需要web项目初期就规划好这些东东，后期才转用域名策略的成本比较高甚至不可以实现。

 

2)采用目录的分散策略

假如域名初期并没有规划使用域名策略，那么可以采用代理服务器来进行目录级的划分。比如一般存储大量文件时，因为文件系统的限制以及效率问题，都会按照一定规则划分了很多级的目录，按这些目录拆分机器也并不是困难的事情。这种架构的问题在于代理服务器的性能和可靠性问题，需要在这点上稍下一点功夫。

 

以上这两个方案，都要自行制定策略实现分散同步传输，传输一般可以归纳为推送和抓取两种办法，同步的话可以采用日志同步（把要同步的数据记入日志，通过日志记录来传输相应文件）、比较同步（使用rsync等同步软件）或即时同步（有新的修改就立刻传输）；另外要实现单点故障剔除的话，首先找一个策略把文件存储到多个节点上，例如，a.xxx.com或目录a的文件相应也存到b和c节点；然后在环境中使用故障剔除技术（lvs或nginx等），就可以解决问题，例如：采用域名的话，可以采用lvs，缺点是使用的机器就会成倍增加；亦可再用一级代理服务器，缺点是会牺牲性能。采用目录的话，因为本身就用到了代理服务器，所以只要存储得当，实现比较容易。

 

——————————————————————————–

csdn.net的系统架构研究

[2010-04-13 11:10:14]

——————————————————————————–

csdn作为国内最大的程序开发社区，影响了足足一代人。它是国内优秀杂志《程序员》的网站，我从前非常喜欢《程序员》这本杂志，里面的文章都非常优秀，那时只有5元钱的我每个月花10块钱买本这样的杂志，看个三五年，都舍不得丢下。

但是今天观察了下csdn站点的架构，发现做的比较简单，看来开发者比较喜欢从程序着手，着重优化代码和数据库，对系统整体架构思考的时间不多。

我着重看了几个二级域名：www、news、bbs/community和blog，其中www、news这些静态文件都有通过squid缓存，用的app_squid架构，然后是dns轮询做分流。

在这里顺便讨论下为什么很多大型网站都喜欢用dns轮询来作首页，而不采用lvs或其它负载均衡策略。这是因为负载均衡都是把所有的访问先集中到一个ip上，因为只有一个ip，所以无意间这个ip的稳定性就关系重大了。ip稳定性会受很多因素影响：n个交换机、线路、机器等等，颇为复杂。而首页很有可能会用到异地的负载均衡，这么来不用dns，方案就很难设计了。现在的常用浏览器和下载软件，都有对dns的故障处理机制，所以dns也是可以屏蔽掉一些故障的，虽然功能不强，但也较为实用；相比之下，即使是lvs也会有很多杂七杂八的问题，反而不如dns性能强和稳定。

csdn静态页前端缓存（2009-05-11)：

Address: 211.100.26.121

Address: 211.100.26.122

Address: 211.100.26.123

Address: 211.100.26.124

这四台机器squid版本：2.6.STABLE14，能够揪出很多问题来：

1)        从文件打开数可见编译参数都是不同的，或是系统配置参数不同？机器分了两批上线吧。

2)        居然没有编译开启epoll，性能看来好不了，重新编译下吧。

3)        缓存没有细致调优，所以这几台机的命中率很低，大量穿透，我估计是重启squid的时候没有清理缓存文件夹造成。

4)        很多内容都没有expires头，这也不能算什么问题，稳定就好，IIs要细致定义expires也很麻烦。

5)        这些静态页面都不支持gzip压缩，浪费了不少带宽，此问题应归罪于IIs和squid的配合问题，可加nginx中层代理处理它。

由此可见csdn的系统管理员对系统都不太上心，从另一个角度讲，系统嘛stable就好，管它优不优化，我觉得这个心态也非常赞。

有兴趣可以参考：

http://sudone.com/linux/squid_mgr.html

这篇文章，然后用：

Squidclient  -p80  -hwww.csdn.net  mgr:info看下。

blog和community这两个多数是动态页面，csdn没有作静态化处理，所以就没有缓存，直接去了后台，最近其增加了nginx，使用nginx来作负载均衡。

在nginx后面有多少台IIs，不能探得出来，回想起从前csdn那非常不稳定的状态，加了个nginx确实好了很多，由于使用了nginx，所以这两个系统支持压缩就变得顺理成章。

bbs没有使用缓存也都说得过去，但像blog这样的系统，都没有使用缓存，觉得非常遗憾，事实上这两个系统都可以用squid完全缓存，csdn从此就可以非常稳定了，但前面也提到了，开发者通常喜欢从自己写的代码里着手优化，这是思维上的局限性，我自己也花了好多年才跳出这个框框，明白了系统优化要从整体入手这么条简单的道理。csdn使用nginx来负载均衡，也是有所领悟，希望他们能更放得开，更为进步。我希望我喜欢的网站都非常稳定快速，这样我在网上闲逛的时候会更顺心些，像csdn、天涯和网易评论这些东东我都是非常之恨的，不过他们都在进步，算是好事。

因为csdn的前端架构太简单，所以图我也懒得画了，事实上估计csdn也不是简单的东西，好多逻辑都被藏在代码和数据库那头，这不可得知。因为csdn代码层使用的是windows主机和asp.net，既然使用了windows，那么棘手的事肯定不会少，还是要找更好的前端，把这些app服务器盖得严严实实为妙，稍有疏漏的话恢复服务的时间就长了。

 

 

 

 

——————————————————————————–

v.2008.163.com对新架构的尝试

[2010-04-13 11:10:14]

——————————————————————————–

先看看架构图：

 

实际上是app_nginx_squid_nginx的结构，nginx顶在最前面，具体有多少台我就不通告了，然后后面有比nginx更多的squid。

这个架构的特点是扩展了squid的功能，并且可以将很多请求绕过squid，实际应用时仍然出现一点问题，并在此系统的超级负荷下收获了不少经验。

为保商业秘密，只能告诉一个大概数字，此系统带图片的负荷每日在2亿-5亿之间，nginx代理全部机器加起来每秒处理的并发数日常总共是10000左右。

另说说每秒并发如何计算，跟据测试和对比，在web最前端每秒并发=系统的established/web server的keep alive。如果不是前端，那就不那么好算了，在这个系统中squid的established极低，不到10个，所以铁定不能从这个数字去判断了，可以使用squid的mgr:info来查看。

在这样的负荷下工作，平常运行时是没有很大的问题，就是在爆发地震性新闻那一小段时间难于招架。

于是我检查了系统，发现几个问题，并相应对系统进行了优化：

 

1、调整nginx的超时设置

我一般都会把nginx的超时时间设得稍微长一些，免得会抛出504错误，所以一般设为5分钟，但是在高负荷下，nginx总是能探测到很多的超时，经过测试，因为nginx前端堆积过多这些超时的请求，所以nginx的cpu占用率会上涨，最后nginx前端负荷过高，但后面一级的squid应该也负荷同样多的超时请求，但它却好得很。这样看来，nginx代理在处理这些超时请求上还有待提高。所以我调整了超时设置，将超时限定为5秒，这下负载就下来了不少。因为nginx超时后会重新选择一个后端请求，所以对访问影响不大，客户端同时也不会在一个超时请求下等待过长时间，这样就更为友好。

 

2、将图片用nginx缓存

鉴于nginx代理会出现问题，干脆把修改率不大的图片用nginx缓存起来，直接对外访问好了。于是使用proxy_store配置了一下，图片放到/dev/shm内存里，然后写一个shell每小时把这些图片全删掉重取。放在内存里删除文件那是快啊，那么多图片一闪就删完了。

 

这样做下来，nginx的负载就很低了，处理同样的并发量，load average从2直降到了0.2，这时我觉得甚至只用单台nginx都可以工作。

 

ps:

在实际应用中也尝试了nginx的url hash模块，发现这个模块在有squid当机时，它并不会自动切换到另一台，就这个问题看来这个模块暂时还是不好使。

 

——————————————————————————–

天涯bbs系统架构分析

[2010-04-13 11:10:14]

——————————————————————————–

研究，就先从入口开始。

天涯所使用的ip地址

221.11.172.154 海南网通

124.225.65.154 湖南电信

218.77.130.151 海南电信

这些ip估计是天涯用来分流带宽所使用，在我测试的这个时间，218.77.130.151这个ip有可能正在迁移到124.225.65.154。

接下来是四台一组的squid主机（squid/2.6.STABLE4）每组负责几个板块，统计了一下至少有3组，也就是12台 。一组称之通用，一组称之热门，一组可称之新来的。这些squid组要做到url分流，那么肯定得有一个7层代理拉，根据天涯之前的记录，这个7层代理是F5。其它看了一下，天涯所有的域名、流量和并发量基本上都是通过这两三台F5搞定的，看来F5的能力还是比较强的。不过，抄句话来说就是光喝还没醉过。

然后cache下来就是web主机了，天涯用的是非常流行的windows 2000和Microsoft IIS 5，主机数量根据cache组计应该会有3 台。会不会阔绰的用到3 台sql server不得而知，数据库装在web服务器上的可能性比较高。另外有些板块是不走cache服务器的，那些也会用到机器，这些机器是不是重复利用的，以后有空再慢慢统计。另外天涯还有两个项目，一下还想不起名字，那两个是google提供的完整方案。

天涯的程序大部分是asp，有部分是asp.net，有一部分又是resin跑的jsp。在bbs中，估计是大部分用的asp，然后在几个关键点用jsp来补充，也就是asp jsp的结构，变幻多端，不可学也。IIS6我已经5年没有实用过了，就不加评说。resin的性能不错，不过还不能算稳定服务器。sql server我也多年未用，不过当年我非常的菜，用着这玩意非常不顺，现在我还是非常之菜，偶尔碰到同样感到头疼。

画个架构图送大家收藏吧。

 

 

——————————————————————————–

nginx图片服务器的架构方案

[2010-04-13 11:10:14]

——————————————————————————–

图片服务通常数据容量较大，而且访问也频繁，鉴于此，图片服务就会有两种问题，一是存储问题，二是访问量问题。

存储问题就是硬盘容量问题，花钱买硬盘就可以了，看似简单，但着实也是最苦的问题。按目前探索来看，最好的方式是：在任何时刻遇到硬盘空间不够时，买颗硬盘插上，最多改改配置，就能立刻利用；另外，硬盘要能充分利用，不然图片存储量大再加上备份，很恐怖，最好是每颗硬盘都用上100%的空间。

访问量也是个大问题，如果服务不允许防盗链，那么访问量会引起带宽、服务器压力等问题，有钱的话直接扔CDN，没钱或者有更多的钱，就自己做吧。根据垣古不变的真理“越老的图，访问量也相对较少”这一点，分成两大部分，一边处理最新的图片，一边处理老旧的图片。最新的图片访问量大，但存储量较少；老图片访问量低，但存储量大。

大概分析完了，开始制定方案。

 

一、拟定一个存储目录规则：

在现有的/a/b/abcde.jpg这样的hash方式下多加一个日期的目录变成：/200810/16/a/b/abcde.jpg或者/2008/10/16/a/b/abcde.jpg。按日期制定这个目录规则后，就可以按年月来拆机器了。

 

二、分机器，分硬盘

按之前的计划，分成两个组，一组服务器用lvs做负载均衡负责新图片；另一组服务器做旧图片访问和备份。新图机器找几台好点的服务器，SCSI硬盘；旧图机器没太大要求，PC机就行，找够硬盘就可以，现在IDE的1T硬盘也不太贵，最好再搭个raid就省事了，最主要是这些机器要多。

 

照这个图，搭一搭

 

说明一下：

1.         图片服务通过lvs作为入口，处理能力上还是有保障的。

2.         利用nginx直接对外服务，不必用squid。

3.         图中的红线是指主nginx会将/2006和/2007年的图片分别代理到两台存档服务器，如果发现主nginx的cpu占用比较大，那么可以考虑使用nginx的proxy_store将图片存到主服务器上，定期清理。

4.         图中有一台存储分配服务器，作为图片服务更新图片的统一入口，有新图片或者修改图片的话，由这台服务器负责将图片放到正确的服务器上去。

5.         旧图片服务器当前用年份来划分，每年增加两台服务器，亦可是加两块硬盘，注意，不要相信raid，一定要有两台机器，地理上分在两个城市则更好。

6.         因为旧数据2006和2007年的数据基本上是没有变化的，所以假如硬盘够大，那么可以把两年的数据合并在一起。

7.         如果细心定制，那么旧图片服务器的硬盘100%塞满是可以的，旧数据的容量基本上不会大幅增长，小小预留1-2G空间就可以了。

使用这个架构的话，到了2009年，我会把2008年的数据想办法迁到旧图服务器上，硬盘不够的话，加硬盘就可以了。如果图片量实在太大，主服务器连一年的数据都装不下，那可以用启用月份来划分；如果一个月都装不下了，那也太夸张了，那就启用日期吧；如果一天的数据都装不下，那就◎＃￥％……※。

 

——————————————————————————–

网站系统二级缓存架构应用

[2010-04-13 11:10:14]

——————————————————————————–

架构图示：

 

1、合并穿透

当前端一级缓存采用了两台以上的squid后，同一个访问量较大的链接，假设其三分钟更新一次，每台squid就会每三分钟向后台发送一个请求更新这个链接，那么很显然两台squid就会每三分钟发送两个请求，n台squid就是n个。因此在负荷很重的系统中，在不停增加squid的同时，后台服务器的压力也会不停增长。这时使用二级缓存就可以将数台squid的穿透再做一层合并，假设是一台机做二级缓存，那么前端n台squid对同一链接的n次穿透，在经过这级squid后，就变成了1个请求发向后台，对后台服务器来说，压力就可以保持稳定。

 

2、保护

在出现某些异常情况时，前端缓存可能会全部失效，譬如前端缓存由于重启或其它原因清理了数据，squid这样的软件碰着bug时也会导致缓存失效。这时请求就会集成一股很大的冲击波，后台服务器扛不住的话一下就被击垮了。架上二级缓存后，二级缓存至少拥有相当于前端一台缓存的负荷能力，因此前端失效一台缓存后二级缓存是肯定能稳当地接下工作的，日常使用中因为前端缓存并不会跑在100%性能下，因此就算两三台前端缓存的量全穿过来二级缓存也能顶下，于此同时后台服务器的访问量仍然是保持稳定的。

 

3、可变

二级缓存在机器配置和服务器软件上未必和一级缓存是一个样的，甚至并不是一台机而是一个架构，这样二级缓存就能起到更多的作用。举几个例子：

 

1）nginx->proxy_store

nginx的proxy_store可以为静态地址提供高性能的缓存，而且还防住了类似xx.html?abc这种糟糕链接的穿透，在某网站的新闻和跟帖的架构中大量采用此种搭配。

 

2）nginx->squid

nginx的proxy_store虽然有较高的性能，但它只能缓存静态地址或rewrite后的地址，不能缓存带?和参数的那种链接，因此用nginx搭配squid也是一种方案，相比于proxy_cache来说，squid更为成熟，而且可以很方便地扩容。在动态地址较多的场合可以考虑此种搭配。

 

3）图片架构

图片服务是最容易出现容灾问题的地方，url_hash固然能解决容灾，但是它会在用户和cache之间多放一层纯代理，在超巨型系统中，多那么一层纯代理会有很大可能惹出麻烦来，而将这层纯代理放在架构的另一个地方——二级缓存，这个方案会更易于为人所接受。这时，前端缓存主要就负责处理并发，只用内存来存储，容灾就算达到很极端的情形，一个地址只缓存了几秒就被强制剔除，也可以拦住很多的请求了；而二级缓存就主要负责处理穿透，通过url_hash和很多硬盘来提供巨大的存储容量和IO性能，将请求全部挡在这一层；后台就轻松地保护好数据即可。