070715最全面的门户网站架构设计方案.docx
《070715最全面的门户网站架构设计方案.docx》由会员分享，可在线阅读，更多相关《070715最全面的门户网站架构设计方案.docx（64页珍藏版）》请在冰点文库上搜索。
070715最全面的门户网站架构设计方案
前台门户网站架构
设计方案
北京宽连十方数字技术有限公司
2010-7
1网站的性能瓶颈分析
网站的性能影响因素很多，下面主要从如下4个方面进行分析说明：
1）网络负载
a）公网负载
b）内网负载
2）WEB应用服务器性能
a）CPU
b）存储，I/O访问
c）内存
d）并发TCP/IP连接数
3）数据库服务器性能
a）数据库参数配置
b）服务器性能（CPU、内存、存储）
c）数据结构的合理性
4）不同WEB应用的处理方式而对不同的性能瓶颈
a）对于静态的网站：
静态的HTML页面严格地由标准的HTML标示语言构成，并不需要服务器端即时运算生成。
这意味着，对一个静态HTML文档发出访问请求后，服务器端只是简单地将该文档传输到客户端。
从服务器运行的那个时间片来看，这个传输过程仅仅占用了很小的CPU资源。
对于静态HTML的访问瓶颈为：
网络带宽、磁盘I/O以及cache（高速缓冲存储器）。
b）对于动态页面
因为服务器解析动态页面必须在其传输到客户端前就通过服务器来进行解释，这样就会给应用服务器添加额外的性能消耗，如果进一步要访问数据库，则会增加数据库服务器的性能消耗，则动态页面还有额外的瓶颈：
应用服务器的性能，数据库服务器的性能。
2系统架构设计
2.1总体思路
为提高网站的高并发性能,提高开发效率及运营效率,主要按如下几个思路进行规划设计:
2.1.1负载均衡
1）四层交换负载均衡：
采用负载均衡器来实现硬件级的四层交换负载均衡，或采用LVS来实现软件的四层交换负载均衡。
2）通过第三方软件来实现负载均衡,同时实现页面请求的缓存。
通过Nginx实现反向代理服务器集群，同时搭建squid集群以作为静态页面和图片的缓存。
3）通过web服务器的配置来实现负载均衡
即通过apache或是Nginx将客户请求均衡的分给tomcat1,tomcat2....去处理。
2.1.2WEB应用开发架构思路
1）应用开发实现MVC架构三层架构进行web应用开发
2）页面尽可能静态化以减少动态数据访问，如果是资讯类的网站可以考虑采用第三方开源的CMS系统来生成静态的内容页面。
3）采用Oscache实现页面缓存,采用Memcached实现数据缓存
4）采用独立的图片服务器集群来实现图片资源的存储及WEB请求
2.1.3数据存储的设计思路
1）数据库拆分,把生产数据库和查询数据库分离，对生产数据库采用RAC实现数据库的集群。
2）采用高效的网络文件共享策略，采用图片服务器来实现页面的图片存储。
2.1.4不同网络用户访问考虑
1）通过引入CDN来解决不同网络服务商的接入速度问题，一般只能解决静态页面的访问问题。
2）在不同运营商机房部署服务器，通过镜像技术来实现不同网络服务商的接入速度问题。
2.2总体架构
2.2.1网站的系统分层架构
2.2.2网站的物理架构
2.2.3网站的开发架构
2.2.4网络拓扑结构
备注：
1）采用双防火墙双交换机做网络冗余，保障平台服务
采用双防火墙通知接通2线路互联网接入，设备之间采用VRRP协议，在任何一个防火墙、互联网发生故障后均可自动将流量切换到另一端，保证网站的正运行，设备或网络恢复后，自动恢复。
采用双千兆交换机分别接在2台防火墙上，当某台设备或者网络链路发生故障后，好设备自动接管已坏设备的工作，不影响网站的整体运行，根据业务及真实服务器的数量，交换机可以随时增加。
2）采用硬件设备负载均衡器，实现网络流量的负载均衡
使用硬件设备负载均衡器，将网络流量均衡的分担到WEB服务器集群各节点服务器，保障平台服务器资源均衡的使用。
3）采用代理服务器，实现软件级的网络负载均衡。
4）数据库服务器分离成生产数据库集群和查询数据库集群，实现生产读写与后台查询统计进行分离，同时生产数据库采用rac技术进行
2.3架构涉及技术的详解
2.3.1负载均衡
1.基于DNS的负载均衡--一个域名绑定多个IP
DNS负载均衡技术是最早的负载均衡解决方案，它是通过DNS服务中的随机名字解析来实现的，在DNS服务器中，可以为多个不同的地址配置同一个名字，而最终查询这个名字的客户机将在解析这个名字时得到其中的一个地址。
因此，对于同一个名字，不同的客户机会得到不同的地址，它们也就访问不同地址上的Web服务器，从而达到负载均衡的目的。
这种技术的优点是，实现简单、实施容易、成本低、适用于大多数TCP/IP应用；但是，其缺点也非常明显，首先这种方案不是真正意义上的负载均衡，DNS服务器将Http请求平均地分配到后台的Web服务器上，而不考虑每个Web服务器当前的负载情况；如果后台的Web服务器的配置和处理能力不同，最慢的Web服务器将成为系统的瓶颈，处理能力强的服务器不能充分发挥作用；其次未考虑容错，如果后台的某台Web服务器出现故障，DNS服务器仍然会把DNS请求分配到这台故障服务器上，导致不能响应客户端。
最后一点是致命的，有可能造成相当一部分客户不能享受Web服务，并且由于DNS缓存的原因，所造成的后果要持续相当长一段时间（一般DNS的刷新周期约为24小时）。
所以在国外最新的建设中心Web站点方案中，已经很少采用这种方案了。
2.通过硬件四层交换实现负载均衡
在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。
Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了
3.通过软件四层交换实现负载均衡
软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是LinuxVirtualServer，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。
一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性。
4.通过反向代理服务器实现负载均衡
反向代理服务器又称为WEB加速服务器，它位于WEB服务器的前端，充当WEB服务器的内容缓存器,反向代理服务器是针对WEB服务器设置的，后台WEB服务器对互联网用户是透明的，用户只能看到反向代理服务器的地址，不清楚后台WEB服务器是如何组织架构的。
当互联网用户请求WEB服务时，DNS将请求的域名解析为反向代理服务器的IP地址，这样URL请求将被发送到反向代理服务器，由反向代理服务器负责处理用户的请求与应答、与后台WEB服务器交互。
利用反向代理服务器减轻了后台WEB服务器的负载，提高了访问速度，同时避免了因用户直接与WEB服务器通信带来的安全隐患。
目前有许多反向代理软件，比较有名的有Nginx和Squid。
Nginx是由IgorSysoev为俄罗斯访问量第二的Rambler.ru站点开发的，是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP代理服务器。
Squid是由美国政府大力资助的一项研究计划，其目的为解决网络带宽不足的问题，支持HTTP，HTTPS，FTP等多种协议，是现在Unix系统上使用、最多功能也最完整的一套软体。
1）Squid
Squid是一个开源的软件，利用它的反向代理技术可以提高网站系统的访问速度,下面将重点介绍Squid反向代理的实现原理和在提高网站性能方面的应用。
Squid反向代理服务器位于本地WEB服务器和Internet之间,组织架构如下图：
客户端请求访问WEB服务时，DNS将访问的域名解析为Squid反向代理服务器的IP地址，这样客户端的URL请求将被发送到反向代理服务器。
如果Squid反向代理服务器中缓存了该请求的资源，则将该请求的资源直接返回给客户端，否则反向代理服务器将向后台的WEB服务器请求资源，然后将请求的应答返回给客户端，同时也将该应答缓存在本地，供下一个请求者使用。
Squid反向代理一般只缓存可缓冲的数据（比如html网页和图片等），而一些CGI脚本程序或者ASP、JSP之类的动态程序默认不缓存。
它根据从WEB服务器返回的HTTP头标记来缓冲静态页面,有四个最重要HTTP头标记：
∙Last-Modified:
告诉反向代理页面什么时间被修改
∙Expires:
告诉反向代理页面什么时间应该从缓冲区中删除
∙Cache-Control:
告诉反向代理页面是否应该被缓冲
∙Pragma:
用来包含实现特定的指令，最常用的是Pragma:
no-cache
注：
DNS的轮询机制将某一个域名解析为多个IP地址。
2）Nginx
Nginx（“enginex”）是俄罗斯人IgorSysoev（塞索耶夫）编写的一款高性能的HTTP和反向代理服务器。
Nginx已经在俄罗斯最大的门户网站──RamblerMedia（www.rambler.ru）上运行了4年时间，同时俄罗斯超过20%的虚拟主机平台采用Nginx作为反向代理服务器。
在国内，已经有新浪博客、新浪播客、搜狐通行证、网易新闻、网易博客、金山逍遥网、金山爱词霸、校内网、YUPOO相册、豆瓣、迅雷看看等多家网站、频道使用Nginx服务器。
Nginx特点如下：
1）工作在OSI模型的第7层（应用层）
2）高并发连接
官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数。
3）内存消耗少
在3万并发连接下，开启的10个Nginx进程才消耗150M内存（15M*10=150M）。
4）配置文件非常简单
风格跟程序一样通俗易懂。
5）成本低廉
Nginx为开源软件，可以免费使用。
而购买F5BIG-IP、NetScaler等硬件负载均衡交换机则需要十多万至几十万人民币。
6）支持Rewrite重写规则
能够根据域名、URL的不同，将HTTP请求分到不同的后端服务器群组。
7）内置的健康检查功能
如果NginxProxy后端的某台Web服务器宕机了，不会影响前端访问。
8）节省带宽
支持GZIP压缩，可以添加浏览器本地缓存的Header头。
9）稳定性高
用于反向代理，宕机的概率微乎其微。
3）Nginx+squid页面缓存来实现反向代理负载均衡
通过Nginx反向代理和squid缓存实现动静分离的架构图如下所示：
5.Apache+tomcat集群实现负载均衡。
使用apache和多个tomcat配置一个可以应用的web网站，用Apache进行分流，把请求按照权重以及当时负荷分tomcat1,tomcat2...去处理，要达到以下要求：
1）Apache做为HttpServer，通过mod_jk连接器连接多个tomcat应用实例，并进行负载均衡。
2）同时还要配置session复制，也就是说其中任何一个tomcat的添加的session，是要同步复制到其它tomcat，集群内的tomcat都有相同的session，并为系统（包括Apache和tomcat）设定Session超时时间。
2.3.2缓存
1.系统架构方面的缓存
1）Squid缓存
架构方面使用Squid进行缓存。
注：
SQUID使用了LM算法，LM就是页面Header里时间（Date）和Last-Modified时间的差。
Date一般是Squid从后面取页面的时间，Last-Modified一般是页面生成时间。
2）Nginx的缓存功能
Nginx从0.7.48版本开始，支持了类似Squid的缓存功能；
缓存把URL及相关组合当作Key，用md5编码哈希后保存；
Nginx的Web缓存服务只能为指定URL或状态码设置过期时间，不支持类似Squid的PURGE指令，手动清除指定缓存页面；
采用MMAP实现，设置的缓存区大小不能超过物理内存+SWEB的值
3）基于memcached的缓存
nginx对memcached有所支持，但是功能并不是特别之强，性能上还是非常之优秀。
location/mem/{
if（$uri~"^/mem/（[0-9A-Za-z_]*）$"）
{
set$memcached_key"$1";
memcached_pass 192.168.1.2:
11211;
}
expires70;
}
这个配置会将
Nginx目前没有写入memcached的任何机制，所以要往memcached里写入数据得用后台的动态语言完成，可以利用404定向到后端去写入数据。
Nginx传统缓存的缺点也是它和squid等缓存软件的不同之特色，所以也可看作其优点。
在生产应用中它常常用作和squid的搭档，squid对于带?
的链接往往无法阻挡，而nginx能将其访问拦住，例如：
nginx会非常老实地将链接形式保存到文件系统中，这样对于一个链接，可以很方便地查阅它在缓存机器上的缓存状态和内容，也可以很方便地和别的文件管理器如rsync等配合使用，它完完全全就是一个文件系统结构。
2.应用程序方面的缓存
1）OSCache
OSCache由OpenSymphony设计，它是一种开创性的JSP定制标记应用，提供了在现有JSP页面之内实现快速内存缓冲的功能，OSCache是个一个广泛采用的高性能的J2EE缓存框架，OSCache能用于任何Java应用程序的普通的缓存解决方案。
OSCache有以下特点：
缓存任何对象，你可以不受限制的缓存部分jsp页面或HTTP请求，任何java对象都可以缓存。
拥有全面的API--OSCacheAPI给你全面的程序来控制所有的OSCache特性。
永久缓存--缓存能随意的写入硬盘，因此允许昂贵的创建（expensive-to-create）数据来保持缓存，甚至能让应用重启。
支持集群--集群缓存数据能被单个的进行参数配置，不需要修改代码。
缓存记录的过期--你可以有最大限度的控制缓存对象的过期，包括可插入式的刷新策略（如果默认性能不需要时）。
OSCache是当前运用最广的缓存方案，JBoss,Hibernate,Spring等都对其有支持。
OSCache的特点:
1）缓存任何对象：
你可以不受限制的缓存部分jsp页面或HTTP请求，任何java对象都可以缓存。
2）拥有全面的API：
OSCacheAPI允许你通过编程的方式来控制所有的OSCache特性。
3）永久缓存：
缓存能被配置写入硬盘，因此允许在应用服务器的多次生命周期间缓存创建开销昂贵的数据。
4）支持集群：
集群缓存数据能被单个的进行参数配置，不需要修改代码。
5）缓存过期：
你可以有最大限度的控制缓存对象的过期，包括可插入式的刷新策略（如果默认性能不能满足需要时）。
2）Memcached
memcached是高性能的分布式内存缓存服务器。
一般的使用目的是，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度、提高可扩展性。
Memcached是以Key/Value的形式单个对象缓存。
3）自主开发的内存数据缓存服务
a）独立进程方式的缓存服务
对于一些常用的动态数据通过开发程序服务缓存在内存中，提供给其他子系统调用，如下面的数据就可以通过这样方式进行缓存。
1）用户基本信息及状态的信息缓冲
2）列表缓存，就像论坛里帖子的列表
3）记录条数的缓存，比如一个论坛板块里有多少个帖子，这样才方便实现分页。
4）复杂一点的group，sum，count查询，比如积分的分类排名
b）集成在WEB应用中的内存缓存
在web应用中对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存（多个可以采用负载均衡），减轻数据库的压力，比如：
很多配置信息，操作员信息等等。
2.3.3页面静态化
静态的HTML页面严格地由标准的HTML标示语言构成，并不需要服务器端即时运算生成。
这意味着，对一个静态HTML文档发出访问请求后，服务器端只是简单地将该文档传输到客户端。
从服务器运行的那个时间片来看，这个传输过程仅仅占用了很小的CPU资源。
页面静态化就是采用效率最高、消耗最小的纯静态化的html页面来替换动态页面。
我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。
同时采用第三方开源的CMS系统来实现网站内容的管理。
对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现页面静态化，所以我们需要引入常见的信息发布系统（CMS），信息发布系统（CMS）可以实现最简单的信息录入自动生成静态页面，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。
同时，HTML静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用HTML静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。
在进行html静态化的时候还可以使用一种折中的方法，就是前端继续使用动态实现，在一定的策略下通过后台模块进行定时把动态网页生成静态页面，并定时判断调用，这个能实现很多灵活性的操作。
为了提高静态HTML的访问效率，主要可以对以下几个方面进行优化：
网络带宽、磁盘I/O以及cache（高速缓冲存储器）。
2.3.4数据库配置及优化
1.数据库集群
对生产数据库采用RAC实现数据库的集群。
2.数据库及表的散列
把生产数据库和查询数据库进行分离，针对系统业务数据的特点，把大的表进行拆分，对于访问较多的表采用分区表。
使用读/写数据库分离，随着系统变得越来越庞大，特别是当它们拥有很差的SQL时，一台数据库服务器通常不足以处理负载。
但是多个数据库意味着重复，除非你对数据进行了分离。
更一般地，这意味着建立主/从副本系统，其中程序会对主库编写所有的Update、Insert和Delete变更语句，而所有Select的数据都读取自从数据库（或者多个从数据库）。
尽管概念上很简单，但是想要合理、精确地实现并不容易，这可能需要大量的代码工作。
因此，即便在开始时使用同一台数据库服务器，也要尽早计划在PHP中使用分离的DB连接来进行读写操作。
如果正确地完成该项工作，那么系统就可以扩展到2台、3台甚至12台服务器，并具备高可用性和稳定性。
3.拥有良好的DB配置和备份
很多公司都没有良好的备份机制，也不知道如何恰当地完成这项工作。
只有imp是不够的，还需要进行热备份，从而得到超快的速度和超高的可靠性。
另外，在将所有备份文件从服务器上转移出来之前要进行压缩和加密。
另外还要确保拥有设计合理的、有用的关于安全、性能和稳定性问题的设定，包括防止数据败坏，其中很多设定都是非常重要的。
2.3.5文件存储
1.文件共享
1）HDFS（GFS）
HDFS是ApacheHadoop项目中的一个分布式文件系统实现，基于Google于2003年10月发表的GoogleFileSystem（GFS）论文。
⏹特性
1）硬件要求低
2）高容错性
3）易可扩展
4）配置简单
5）超大文件
HDFS采用master/slave架构。
一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。
2）NFS与GFS比较
首先从它们的功能上进行分析。
NFS即网络文件系统，是由SUN公司开发的。
它是FreeBSD支持的文件系统中的一种，允许一个系统在网络上与它人共享目录和文件。
通过使用NFS，用户和程序访问远端系统上的文件就像访问本地文件一样。
而GFS是Google为了满足本公司迅速增长的数据处理要求而开发的文件系统。
GFS是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。
它是针对Google的计算机集群进行设计的，专门是为Google页面搜索的存储进行了优化。
所以从功能上看，它们两者是完全不同的概念。
其次从结构上比较，NFS至少包括两个主要部分：
一台服务器，以及至少一台客户机。
被共享的目录和文件存放在服务器上，客户机远程地访问保存在服务器上的数据。
GFS则由一台Master（通常有几台备份）和若干台TrunkServer构成。
GFS中文件备份成固定大小的Trunk分别存储在不同的TrunkServer上，每个Trunk有多份（比如3）拷贝，也存储在不同的TrunkServer上。
Master负责维护GFS中的Metadata，即文件名及其Trunk信息。
客户端先从Master上得到文件的Metadata，根据要读取的数据在文件中的位置与相应的TrunkServer通信，获取文件数据。
再从跨平台性上，NFS的基本原则是“容许不同的客户端及服务端通过一组RPCs分享相同的文件系统”，它是独立于操作系统的，容许不同的操作系统共同地进行文件的共享。
而GFS则没有这一特点，文件只能被集群系统中的PC所访问，而且这些PC的操作系统一般是Linux。
最后从规模上比较，HDFS只应用在大批量的数据共享上。
目前Google拥有超过200个的GFS集群，其中有些集群的PC数量超过5000台。
集群的数据存储规模可以达到5个PB，并且集群中的数据读写吞吐量可达到每秒40G。
而NFS一般没有这么巨大的规模。
2.文件的多服务器自动同步
使用Linux2.6内核的inotify监控Linux文件系统事件。
利用开源的lsync监听某一目录，如果目录内文件发生增、删、改，利用Rsync协议自动同步到多台服务器。
3.图片服务器分离
特别是如果程序与图片都放在同一个APAHCE的服务器下，每一个图片的请求都有可能导致一个HTTPD进程的调用。
使用独立的图片服务器不但可以避免以上这个情况，更可以对不同的使用性质的图片设置不同的过期时间，以便同一个用户在不同页面访问相同图片时不会再次从服务器（基于是缓存服务器）取数据，不但快速，而且还省了带宽。
还有就是，对于缓存的时间上，亦可以做独立的调节。
2.3.6网络问题解决方案
你不可能要求所有的使用人员，都和你的服务器在一个运营商的网络内，而不同网络之间访问速度会很慢，我们可以采用镜像网站和引入CDN来解决这一问题。
1.智能DNS解析
我们可以在不同的网络运营商部署web服务器，通过linux上的rsync工具自动同步到不同网络接入商的web服务器上，以作为主站的镜像。
然后通过配置智能DNS解析来引导不同网络的访问用户到对应的网络运营商的web服务器。
2.CDN
如果有
升级会员 