使用开源软件，设计高性能可扩展网站

导读：

　　上次我们以LiveJournal为例详细分析了一个小网站在一步一步的发展成为大规模的网站中性能优化的方案，以解决在发展中由于负载增长而引起的性能问题，同时在设计网站架构的时候就从根本上避免或者解决这些问题。

　　今天我们来看一下在网站的设计上一些通常使用的解决大规模访问，高负载的方法。我们将主要涉及到以下几方面：

　　1、 前端负载

　　2、 业务逻辑层

　　3、 数据层

　　在LJ性能优化文章中我们提到对服务器分组是解决负载问题，实现无限扩展的解决方案。通常中我们会采用类似LDAP的方案来解决，这在邮件的服务器以及个人网站，博客的应用中都有使用，在Windows下面有类似的Active Directory解决方案。有的应用（例如博客或者个人网页）会要求在二级域名解析的时候就将用户定位到所属的服务器群组，这个时候请求还没到应用上面，我们需要在DNS里解决这个问题。这个时候可以用到一款软件bind dlz，这是bind的一个插件，用于取代bind的文本解析配置文件。它支持包括LDAP，BDB在内的多种数据存储方式，可以比较好的解决这个问题。

　　另外一种涉及到DNS的问题就是目前普遍存在的南北互联互通的问题，通过bind9内置的视图功能可以根据不同的IP来源解析出不同的结果，从而将南方的用户解析到南方的服务器，北方的用户解析到北方的服务器。这个过程中会碰到两个问题，一是取得南北IP的分布列表，二是保证南北服务器之间的通讯顺畅。第一个问题有个笨办法解决，从日志里取出所有的访问者IP，写一个脚本，从南北的服务器分别ping回去，然后分析结果，可以得到一个大致准确的列表，当然最好的办法还是直到从运营商那里拿到这份列表(update:参见这篇文章)。后一个问题解决办法比较多，最好的办法就是租用双线机房，同一台机器，双IP，南北同时接入，差一些的办法就是南北各自找机房，通过大量的测试找出中间通讯顺畅的两个机房，后一种通常来说成本较低，但效果较差，维护不便。

　　另外DNS负载均衡也是广泛使用的一种负载均衡方法，通过并列的多条A记录将访问随即的分布到多台前端服务器上，这种通常使用在静态页面居多的应用上，几大门户内容部分的前端很多都是用的这种方法。

　　用户被定位到正确的服务器群组后，应用程序就接手用户的请求，并开始沿着定义好的业务逻辑进行处理。这些请求主要包括两类静态文件(图片，js脚本,css等)，动态请求。

　　静态请求一般使用squid进行缓存处理，可以根据应用的规模采用不同的缓存配置方案，可以是一级缓存，也可以是多级缓存，一般情况下cache的命中率可以达到70%左右，能够比较有效的提升服务器处理能力。Apache的deflate模块可以压缩传输数据，提高速度，2.0版本以后的cache模块也内置实现磁盘和内存的缓存，而不必要一定做反向代理。

　　动态请求目前一般有两种处理方式，一种是静态化，在页面发生变化时重新静态页面，现在大量的CMS，BBS都采用这种方案，加上cache，可以提供较快的访问速度。这种通常是写操作较少的应用比较适合的解决方案。

　　另一种解决办法是动态缓存，所有的访问都仍然通过应用处理，只是应用处理的时候会更多的使用内存，而不是数据库。通常访问数据库的操作是极慢的，而访问内存的操作很快，至少是一个数量级的差距，使用memcached可以实现这一解决方案，做的好的memcache甚至可以达到90%以上的缓存命中率。10年前我用的还是2M的内存，那时的一本杂事上曾经风趣的描述一对父子的对话：

　　儿子：爸爸，我想要1G的内存。

　　爸爸：儿子，不行，即使是你过生日也不行。

　　时至今日，大内存的成本已经完全可以承受。Google使用了大量的PC机建立集群用于数据处理，而我一直觉得，使用大内存PC可以很低成本的解决前端甚至中间的负载问题。由于PC硬盘寿命比较短，速度比较慢，CPU也稍慢，用于做web前端既便宜，又能充分发挥大内存的优势，而且坏了的话只需要替换即可，不存在数据的迁移问题。

　　下面就是应用的设计。应用在设计的时候应当尽量的设计成支持可扩展的数据库设计，数据库可以动态的添加，同时支持内存缓存，这样的成本是最低的。另外一种应用设计的方法是采用中间件，例如ICE。这种方案的优点是前端应用可以设计的相对简单，数据层对于前端应用透明，由ICE提供，数据库分布式的设计在后端实现，使用ICE封装后给前端应用使用，这路设计对每一部分设计的要求较低，将业务更好的分层，但由于引入了中间件，分了更多层，实现起来成本也相对较高。

　　在数据库的设计上一方面可以使用集群，一方面进行分组。同时在细节上将数据库优化的原则尽量应用，数据库结构和数据层应用在设计上尽量避免临时表的创建、死锁的产生。数据库优化的原则在网上比较常见，多google一下就能解决问题。在数据库的选择上可以根据自己的习惯选择，Oracle，MySQL等，并非Oracle就够解决所有的问题，也并非MySQL就代表小应用，合适的就是最好的。

　　前面讲的都是基于软件的性能设计方案，实际上硬件的良好搭配使用也可以有效的降低时间成本，以及开发维护成本，只是在这里我们不再展开。

　　网站架构的设计是一个整体的工程，在设计的时候需要考虑到性能，可括展性，硬件成本，时间成本等等，如何根据业务的定位，资金，时间，人员的条件设计合适的方案是件比较困难的事情，但多想多实践，终究会建立一套适合自己的网站设计理念，用于指导网站的设计工作，为网站的发展奠定良好的基础。

　　yudunde 发表于 June 18, 2006 12:22 AM | Example

　　以往文章使用开源软件，设计高性能可扩展网站

　　评论

　　Hi 敦德：

　　你的文章商业价值很高啊： 看匹配出来的广告

　　北京博大网人－南北互联互通虚拟主机

　　249元/年=100M空间+100M邮箱+域名。南北互联互通，高速访问。5年成功...

　　www.3271.cn

　　光明在线6年用户超10万－建网站面向全国

　　网站的设计：建网站980元，送域名空间，300种功能，网站自动生成，中...

　　www.aaawww.com

　　网站的设计－网站吧68元建站

　　提供网站的设计，NOON网站吧再掀自助网站风暴：超多功能上千页面，全...

　　www.wangzhan8.com

　　信网－设计网站

　　360元建设网站，专业公司、多年经验，按需订制、非模板制作，赠送域名...

　　www.clxtech.com

　　NOON设计网站专家68元建站－诺凡

　　NOON网站吧（京ICP证041545号）设计网站，再掀自助建站风暴：超多功能...

　　www.wangzhan8.com

　　亿速互联－让您的企业在网络中更精彩

　　专业网站整体策划、资深美工设计、丰富的网站建设经验。面向全国提供...

　　www.cnes.com.cn

　　最近我在做上下文广告方面的系统：近期看看有没有合作的机会。你的育儿博客也是很有商业价值的内容。

　　Posted by: Che Dongat June 18, 2006 10:39 AM

　　哈哈，好的。我页面上没放广告啊，你从哪里查到的相关广告?

　　Posted by: Donaldat June 18, 2006 11:27 AM

　　顶一下，其实很多时候我发现，瓶颈在数据库上，

　　squid的方法不错，但是很担心被人当跳板。

　　顺便说一句，google现在的集群已经不是只有 pc了

　　Posted by: 二孬 at June 19, 2006 07:20 PM

　　squid参数里可以设置的，避免被用来做正向代理

　　Posted by: Donaldat June 20, 2006 09:18 AM

　　奇怪，为什么你和车东都没有提到过是用LVS来做网站的负载均衡呢？？和DNS相比有什么优缺点呢？

　　Posted by: 蓝槐at June 28, 2006 11:51 AM

　　LVS目前应该还是主要用于在前端针对web server进行的分布式扩展，其实用DNS轮循虽然效果差一点，但基本可以满足要求。

　　"IPVS无法检查到请求的内容再选择服务器，这就要求后端服务器组提供相同的服务，不管请求被发送到哪一台服务器，返回结果都是一样的。"这对于大部分都是动态请求的网站来说无法接受:)

　　它还有个七层交换的项目，目的就是解决这个问题，但开发的不太完善，用的也不多。

　　Posted by: Donaldat June 28, 2006 01:19 PM

　　对不起，我的网站开发经验不是很丰富，想问一下什么情况需要根据请求内容来选择服务器呢？谢谢^_^

　　Posted by: 蓝槐at June 30, 2006 11:26 AM

　　例如访问用户的短消息数据和访问文章数据有时候是放在不同的应用服务器上处理的，这就叫根据请求内容来选择不同的服务器。

本文转自

http://www.example.net.cn/2006/06/open_source_high_performance.html