前台门户网站架构设计方案 - 图文

更新时间：2024-03-21 11:18:01 阅读量：综合文库文档下载

说明：文章内容仅供预览，部分内容可能不全。下载后的文档，内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的，是否完整无缺。

经销商门户网站前台登录推荐度：
相关推荐

1 2 3

设计思路 ........................................................................................................................................................ 2 系统结构 ........................................................................................................................................................ 2 网络规划及性能计算 .................................................................................................. 错误！未定义书签。 3.1 网络架构 ................................................................................................................................................ 7 3.2 网络架构说明 ...................................................................................................... 错误！未定义书签。 3.2.1 采用双防火墙双交换机做网络冗余，保障平台服务 ................................................................. 7 3.2.2 采用硬件设备负载均衡器，实现网络流量的负载均衡 ............................................................. 7 3.3 系统测算 .............................................................................................................. 错误！未定义书签。 3.3.1 系统处理能力要求 ...................................................................................................................... 33 3.3.2 业务处理能力要求 ...................................................................................... 错误！未定义书签。 3.3.3 系统话务模型 .............................................................................................. 错误！未定义书签。 3.4 配置核算 .............................................................................................................. 错误！未定义书签。 3.4.1 数据库服务器性能核算 .............................................................................. 错误！未定义书签。 3.4.2 WEB服务器集群性能核算 .......................................................................... 错误！未定义书签。 3.4.3 WEB服务器集群内存性能核算 .................................................................. 错误！未定义书签。 3.4.4 网络带宽 ...................................................................................................................................... 34 4

性能模拟测试及性能推算 .......................................................................................... 错误！未定义书签。 4.1 测试环境 .............................................................................................................. 错误！未定义书签。 4.2 测试结果 .............................................................................................................. 错误！未定义书签。 4.2.1 1个客户端模拟不同线和并发请求结果 ..................................................... 错误！未定义书签。 4.2.2 10个客户端请求 .......................................................................................... 错误！未定义书签。 4.3 结果分析 .............................................................................................................. 错误！未定义书签。 4.4 根据测试结果推算 .............................................................................................. 错误！未定义书签。 4.5 设备清单 .............................................................................................................................................. 34 4.5.1 硬件设备配置清单 ...................................................................................... 错误！未定义书签。 4.5.2 设备技术规格 .............................................................................................. 错误！未定义书签。 4.6 平台扩容的建议 .................................................................................................................................. 34

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.2 WEB应用开发架构思路

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 网站的系统分层架构

硬件四层交换软件四层交换负载均衡器LVSNginx proxySquidNginx cache负载均衡反向代理软件（数据缓存）WEB服务（Apache+tomcat负载均衡）Squid cacheApacheTomatControl...TomatWEB服务器架构MVC应用架构应用级缓存Model数据持久层(ibatis)页面缓存(OSCache)View数据缓存(Memcached)查询数据库数据存储文件共享NFSHDFS数据库生产数据库

2.2.2 网站的物理架构

Internet用户浏览页面负载均衡器1...服务器1服务器2服务器3服务器2代理服务器集群（Nginx）服务器n服务器2...服务器1服务器2服务器1服务器2服务器1服务器2服务器1服务器n图片服务器集群Web服务器集群AWeb服务器集群BSquid服务器集群

2.2.3 网站的开发架构

通讯层消息中心业务层WEB服务器持久层数据层数据存储SMSMMSWAP PUSH基于struts 的MVC框架ControlORMI/O文件存储HDFS数据库消息中心WEB容器请求ibatis数据ViewModelDB连接池生产数据库（RAC）JDBC页面缓存（Memcached）ApacheTomat...Tomat短信群发器彩信群发器C3p0生产数据库（RAC）业务支撑模块后台支撑模块HTML静态化模块统计支撑模块查询数据库

2.2.4 网络拓扑结构

Internet主防火墙备防火墙主交换机VRRP备交换机负载均衡器1负载均衡器2...服务器2服务器1服务器n服务器1服务器n服务器2服务器2服务器2...服务器2服务器1服务器n服务器1服务器n服务器1服务器n服务器1服务器2代理服务器集群（Nginx）网站服务器集群图片服务器集群应用服务器集群光纤交换机生产DB服务器集群查询DB服务器组管理终端光纤交换机磁盘阵列柜磁盘阵列柜备注：

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就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性。 4. 通过反向代理服务器实现负载均衡

反向代理服务器又称为 WEB 加速服务器，它位于 WEB 服务器的前端，充当WEB服务器的内容缓存器,反向代理服务器是针对 WEB 服务器设置的，后台 WEB 服务器对互联网用户是透明的，用户只能看到反向代理服务器的地址，不清楚后台 WEB 服务器是如何组织架构的。当互联网用户请求 WEB 服务时，DNS 将请求的域名解析为反向代理服务器的 IP 地址，这样 URL 请求将被发送到反向代理服务器，由反向代理服务器负责处理用户的请求与应答、与后台 WEB 服务器交互。利用

反向代理服务器减轻了后台 WEB 服务器的负载，提高了访问速度，同时避免了因用户直接与 WEB 服务器通信带来的安全隐患。

目前有许多反向代理软件，比较有名的有 Nginx 和 Squid 。

Nginx 是由 Igor Sysoev 为俄罗斯访问量第二的 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 (“engine x”) 是俄罗斯人Igor Sysoev(塞索耶夫)编写的一款高性能的 HTTP 和反向代理服务器。

Nginx 已经在俄罗斯最大的门户网站── Rambler Media（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为开源软件，可以免费使用。而购买F5 BIG-IP、NetScaler等硬件负载均衡交换机则需要十多万至几十万人民币。 6) 支持Rewrite重写规则

能够根据域名、URL的不同，将 HTTP 请求分到不同的后端服务器群组。 7) 内置的健康检查功能

如果 Nginx Proxy 后端的某台 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 ~ \ {

set $memcached_key \

memcached_pass 192.168.1.2:11211; }

expires 70; }

这个配置会将http://sudone.com/mem/abc指明到memcached的abc这个key去取数据。 Nginx目前没有写入memcached的任何机制，所以要往memcached里写入数据得用后台的动态语言完成，可以利用404定向到后端去写入数据。

Nginx传统缓存的缺点也是它和squid等缓存软件的不同之特色，所以也可看作其优点。在生产应用中它常常用作和squid的搭档，squid对于带?的链接往往无法阻挡，而nginx能将其访问拦住，例如：http://sudone.com/?和http://sudone.com/在squid上会被当做两个链接，所以会造成两次穿透；而nginx只会保存一次，无论链接变成

http://sudone.com/?1还是http://sudone.com/?123，均不能透过nginx缓存，从而有效地保护了后端主机。

nginx会非常老实地将链接形式保存到文件系统中，这样对于一个链接，可以很方便地查阅它在缓存机器上的缓存状态和内容，也可以很方便地和别的文件管理器如rsync等配合使用，它完完全全就是一个文件系统结构。

2. 应用程序方面的缓存 1） OSCache

OSCache由OpenSymphony设计，它是一种开创性的JSP定制标记应用，提供了在现有JSP页面之内实现快速内存缓冲的功能，OSCache是个一个广泛采用的高性能的J2EE缓存框架，OSCache能用于任何Java应用程序的普通的缓存解决方案。OSCache有以下特点：缓存任何对象，你可以不受限制的缓存部分jsp页面或HTTP请求，任何java对象都可以缓存。拥有全面的API--OSCache API给你全面的程序来控制所有的OSCache特性。永久缓存--缓存能随意的写入硬盘，因此允许昂贵的创建（expensive-to-create）数据来保持缓存，甚至能让应用重启。支持集群--集群缓存数据能被单个的进行参数配置，不需要修改代码。缓存记录的过期--你可以有最大限度的控制缓存对象的过期，包括可插入式的刷新策略（如果默认性能不需要时）。

OSCache是当前运用最广的缓存方案，JBoss,Hibernate,Spring等都对其有支持。 OSCache的特点:

1) 缓存任何对象：你可以不受限制的缓存部分jsp页面或HTTP请求，任何java对象都可以缓存。 2) 拥有全面的API：OSCache API允许你通过编程的方式来控制所有的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） Struts架构

客户端发送一个HTTP请求，通过Struts框架最后获得一个HTTP响应，这一过程非常重要，它是理解Struts框架的重点。上图描述了Struts框架的结构，而下图通过一个活动图更具体描述接受请求直至返回响应的整个过程：

2. 面向服务的应用架构

面向服务的应用架构是指构建可分布式的、去中心化的服务器平台，以提供许多不同的应用，数据库被分成很多个小部分，围绕每个部分都会创建一个服务接口(API),并且该接口是访问数据库的唯一途径。最终数据库演变成一个非常庞大的共享资源。

这种架构是松散耦合的，并且围绕着服务进行构建。面向服务的架构提供给他们隔离特性，一个服务可能有很多台数据库服务器，他们之间的数据是相通的，而对外他们的接口只有一个，外面是无法知道这个服务后面的数据组织是如何搭建的。

这样就有了越来越多的应用服务器。这些应用服务器从数据众多的服务（每个服务背后都有数据库或集群数据库）中聚合信息，然后生成我们所看到的Amazon.com的各个网站页面。

这样各种服务如插件一样组成了一个开放的平台，这样团队的规模就会比较小，比较灵活。注Amazon就是采用了这种架构来构建的，它拥有上千台服务器。

2.4 系统软件参数优化

在一定的架构基础上，要提高并发处理能力则需要调整服务器的操作系统内核参数、web服务器（tomcat的参数、apache的参数、Nginx的参数），以使其性能达到最优化。

2.4.1 操作系统优化

调整系统的内核参数，增大连接数及TCP/IP的超时设置。 Linux系统中：

在/etc/sysctl.conf配置文件中增加如下内核参数： net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 5 2.4.2 tomcat服务器优化

增大并发连接数，调整内存参数的设置。

1、JDK内存优化：当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。因此一般建议堆的最大值设置为可用内存的最大值的80%。 Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大. Tomcat默认可以使用的内存为128MB,Windows下,在文件/bin/catalina.bat，Unix下，在文件/bin/catalina.sh的前面，增加如下设置： JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】' 需要把这个两个参数值调大。例如： JAVA_OPTS='-Xms256m -Xmx512m' 表示初始化内存为256MB，可以使用的最大内存为512MB。 2、连接器优化：在tomcat配置文件server.xml中的配置中，和连接数相关的参数有： maxThreads： Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。默认值150。 acceptCount：指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。默认值10。 minSpareThreads： Tomcat初始化时创建的线程数。默认值25。 maxSpareThreads：一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。默认值75。

enableLookups：是否反查域名，默认值为true。为了提高处理能力，应设置为false connnectionTimeout：网络连接超时，默认值60000，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。 maxKeepAliveRequests：保持请求数量，默认值100。 bufferSize：输入流缓冲大小，默认值2048 bytes。 compression：压缩传输，取值on/off/force，默认值off。其中和最大连接数相关的参数为maxThreads和acceptCount。如果要加大并发连接数，应同时加大这两个参数。 web server允许的最大连接数还受制于*作系统的内核参数设置，通常Windows是2000个左右，Linux是1000个左右。 2.4.3 apache服务器优化

加大并发数量和关闭不需要的模块。因为apache非常消耗内存，尽量轻量化。

Apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率

同时配置apache和tomcat的组合使之能作到动静分离，apache处理静态页面，tomcat处理动态页面。在处理静态页面或者图片、js等访问方面，可以考虑使用lighttpd代替Apache，它提供了更轻量级和更高效的处理能力

2.4.4 Nginx服务器的优化

worker_processes：该参数的值最好跟cpu核数相等，能够发挥最大性能，如果nginx所在服务器为2颗双核cpu，则建议设定为4。

3 Web服务架构评测

主要对基于tomcat和nginx+tomcat的web服务器的处理性能进行测试，以作为不同性能要求下架构选型的依据

3.1 测试环境

3.1.1 网络环境 1. 内网带宽 ? 千M内网。

? 内网ping包延迟：< 0.1ms

2. 网络拓扑示意

WEB服务高可用测试网络示意图千兆交换机测试服务器WEB服务192.168.131.19test1192.168.131.61test2192.168.131.60:81192.168.131.57Tomcat1Nginx服务端192.168.131.56Tomcat2 3.1.2 服务器配置

设备 Nginx 硬件配置 IBM X3650 CPU: Intel(R) Xeon(R) E5150 2.66GHz 2核*2 内存：4G 千兆网卡操作系统 Redhat linux as4 Tomcat1 Hp DL580 G4 CPU: Intel(R) Xeon(TM) 3.40GHz 4核*2 内存：8G 千兆网卡 Redhat linux as5 Tomcat2 Hp DL580 G4 CPU: Intel(R) Xeon(TM) 3.40GHz 4核*2 内存：8G 千兆网卡 Redhat linux as5 Test1 Hp DL580 G5 CPU:Intel(R) Xeon(R) E7310 1.60GHz 4核*2 内存：4G 千兆网卡 IBM X3650 CPU: Intel(R) Xeon(R) E5150 2.66GHz 2核*2 内存：4G 千兆网卡 Redhat linux as5 Test2 Redhat linux as4

3.1.3 软件环境 1. 操作系统网络参数优化

用做测试的各台服务器，均在/etc/sysctl.conf配置文件中增加如下内核参数： net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 5 2. Nginx设置主要配置如下： user www www; worker_processes 4;

error_log /usr/local/nginx/logs/nginx_error.log debug; pid /usr/local/nginx/logs/nginx.pid; worker_rlimit_nofile 51200; events {

use epoll;

worker_connections 51200; } http {

include mime.types;

default_type application/octet-stream; #charset gb2312;

server_names_hash_bucket_size 128; client_header_buffer_size 32k; large_client_header_buffers 4 32k;

sendfile on; tcp_nopush on; keepalive_timeout 1; tcp_nodelay on; #gzip on;

#gzip_min_length 1k; #gzip_buffers 4 16k; #gzip_http_version 1.0;

#gzip_comp_level 2;

#gzip_types text/plain application/x-javascript text/css application/xml; #gzip_vary on; upstream tomcats {

server 192.168.131.57:8081; server 192.168.131.56:8081; # server 192.168.131.61:8080; } server {

listen 81;

server_name localhost; proxy_redirect off;

location / {

proxy_pass http://tomcats; }

#后端的Web服务器可以通过X-Forwarded-For获取用户真实IP # proxy_set_header X-Forwarded-For $remote_addr; # location / {

# if ($request_uri ~* \ # {

# proxy_pass http://squid.abc.com; # }

# if ($request_uri ~* \ # {

# proxy_pass http://squid.abc.com; # }

# proxy_pass http://web.abc.com; #}

#定义日志格式

log_format access '$remote_addr - $remote_user [$time_local] $request ' '\ '\ #打日志

access_log /usr/local/nginx/logs/access.log access;

#允许客户端请求的最大的单个文件字节数 client_max_body_size 10m;

#缓冲区代理缓冲用户端请求的最大字节数可以理解为先保存到本地再传给用户 client_body_buffer_size 128k;

#跟后端服务器连接的超时时间_发起握手等候响应超时时间 proxy_connect_timeout 600;

#连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理 proxy_read_timeout 600;

#后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据 proxy_send_timeout 600;

#代理请求缓存区_这个缓存区间会保存用户的头信息以供Nginx进行规则处理_一般只要能保存下头信息即可

proxy_buffer_size 8k;

#同上告诉Nginx保存单个用的几个Buffer 最大用多大空间 proxy_buffers 4 32k;

#如果系统很忙的时候可以申请更大的proxy_buffers 官方推荐*2 proxy_busy_buffers_size 64k;

#proxy缓存临时文件的大小 proxy_temp_file_write_size 64k; } }

3. Tomcat设置主要配置如下： ? Tomcat5.5 ? MaxThread 500 ? MinSpareThread 25 ? MaxSpareThread75

? Xmx 1740M 4. Java环境

? 使用jdk1.6_03启动两个Tomcat。

使用jdk1.6启动两个客户端的httpTes测试t进程。

3.2 测试结果

3.2.1 单个TOMCAT的WEB服务器 N客户O 数线程数 500 请求间隔测试服次数时间务器 200万 200万 0毫秒 25毫秒占用服务器内存负载 >150 持续平均速时间度 1298682秒条/秒 288秒 293秒 422秒 413秒 742秒 744秒 1595秒 1575秒 6362秒 6351秒 4765条/秒 4123条/秒 2863条/秒 2922条/秒 1727条/秒 1608条/秒 742条/秒 737条/秒 471条/秒 472条/秒完成请求 106万 137万 120万 120万 120万 128万 119万 118万 116万 300万 300万结果说明 1 1 Test1 1.1G Test1 从第82秒开始，tomcat占用内存1.1g，但CPU资源被tomcat耗尽，服务器负载急剧升高，top显示已达150，服务器停止响应客户端请求，客户端请求速度急剧下降，错包率100%，测试被迫中断。从第280秒左右开始，tomcat占用内存到达Xmx指定上限1.7g，Test1、Test2请求速度急剧下降，出现错包，错包率超过>6%，且仍在增加，测试终止。tomcat抛出“java.lang.OutOfMemoryError: GC overhead limit exceeded “异常。服务端从第400秒左右开始，tomcat占用内存到达Xmx指定上限1.7g，Test1、Test2请求速度急剧下降，开始出现大量错包，422秒以后的错包率超过4.3%，且仍在在增加中，之前的错包率约为0.8%，测试终止。服务端从第740秒左右开始，tomcat占用内存到达Xmx指定上限1.7g，Test1、Test2请求速度急剧下降，开始出现大量错包，测试终止，达到1.7G前，错包率只有0.008%，达到1.7g后，截止停止测试时，错包率增长到1.2%，且仍在在增加中。 web服务器负载小于2。服务端从第1595秒左右开始，tomcat占用内存到达Xmx指定上限1.7g，Test1、Test2请求速度急剧下降，开始出现大量错包，达到1.7G前，错包率只有0.08%，达到1.7g后，截止停止测试时，错包率增长到2.3%，测试终止。在测试进度到80%左右时，tomcat1占用内存达到了Xmx指定上限1.7g，但Test1、Test2请求速度并未下降，直到600万次请求全部完成，两个客户端分别有9个丢包，丢包率只有0.003%，最长的响应时长为12.728秒。 2 2 500 Test2 Test1 1.7G < 6 3 2 500 200万 50毫秒 Test2 Test1 1.7G < 3 4 2 500 200万 2001.7G 毫秒 Test2 Test1 < 2 5 2 500 200万 5001.7G 毫秒 Test2 Test1 1.7G Test2 < 1 6 2 500 300万 1000毫秒 < 1

3.2.2 Nginx+2个TOMCAT的WEB服务器 NO 客户线程端数数 2 250 请求间隔测试服次数时间务器 150万 0毫秒 Test1 Test1 Tomcat占用内存 1G < 2 1G 322秒 542秒 < 2 Test2 1.4G Test1 1.7G < 2 Test2 1.7G Test1 1.7G < 1 Test2 1.7G Test1 1.7G < 1 Test2 1.7G Test1 968M 5565秒 898条/秒 10149秒 492条/秒 < 1 Test2 1G 10149秒 492条/秒 500万 500万 500万 1863秒 1141秒 1860秒 544秒 1140秒服务器负载持续时间 347秒平均速度 4322条/秒 4658条/秒 3690条/秒 3676条/秒 2445条/秒 2424条/秒 1490条/秒 1482条/秒完成请求数 150万 150万 200万 200万最大响应时长 93005毫秒 21244毫秒 45016毫秒 45014毫秒平均响应时长 0.21毫秒测试结果 1 300万次请求全部完成，无一错包。 0.23毫秒 0.27毫秒 2 2 500 200万 25毫秒 Test1 1.4G 400万次请求全部完成，无一错包。 0.27毫秒 3 2 500 300万 50毫秒 278万 276万 277万 276万 500万 93000毫秒 92987毫秒 9077毫秒 9044毫秒 1.09毫秒 1.11毫秒 2.02毫秒服务端从第1100秒左右开始，Tomcat1、Tomcat2占用内存到达Xmx指定上限1.7g，Test1、Test2请求速度缓慢下降，但并无错包，人为终止测试。服务端从第1800秒左右开始，Tomcat1、Tomcat2占用内存到达Xmx指定上限1.7g，Test1、Test2请求速度缓慢下降，但并无错包，人为终止测试。完成测试，但Tomcat1、Tomcat2占用内存到达Xmx指定上限1.7g，无错包。 4 2 500 300万 200毫秒 5 2 500 500万 500毫秒 5475秒 913条/秒 6 2 500 500万 1000毫秒完成测试，无一错包。 2.02毫秒

3.2.3 Nginx+2个TOMCAT的WEB服务器+缓冲 NO 客户线程端数数 2 250 请求间隔次数时间 150万 200万 0毫秒 25毫秒测试服务器 Test1 Test2 Test1 Test2 Test1 Test2 Test1 Test2 Test1 Test2 Test1 Test2 Tomcat占用内存 0.2G 0.2G 0.4G < 1 0.4G 0.4G < 1 0.2G 0.4G < 1 0.2G 0.4G < 1 0.2G 0.4G < 1 0.2G 服务器负载 < 1 持续平均速度时间 (条/秒) 64秒 23437 59秒 25423 19610202 秒 19410361 秒 3797915 秒 3847812 秒 12202459 秒 12412417 秒 5031993 秒 5055989 秒 1004498 0秒 1003498 8秒完成请最大响应平均响应时求数时长长 150万 9993毫秒 0.04毫秒 150万 3472毫秒 0.04毫秒测试结果 1 2 2 500 200万 9616毫秒 0.10毫秒开启Nginx缓存后，400万次请求全部完成，分别200万 9608毫秒 0.10毫秒有241和216个错包。 300万 9015毫秒 0.13毫秒开启Nginx缓存后，600万次请求全部完成，无一10234毫300万 0.13毫秒错包。秒 300万 3018毫秒 0.40毫秒开启Nginx缓存后，600万次请求全部完成，无一300万 3384毫秒 0.41毫秒错包。 500万 3020毫秒 1.00毫秒开启Nginx缓存后，1000万次请求全部完成，无一500万 3394毫秒 1.01毫秒错包。 3 2 500 300万 50毫秒 4 2 500 300万 200毫秒 5 2 500 500万 500毫秒 6 2 500 500万 1000毫秒 1000500万 3020毫秒 2.00毫秒开启Nginx缓存后，万次请求全部完成，无一500万 78毫秒 2.00毫秒错包。注：本次测试所用jsp页面仅100个字节大小，测试过程中带宽压力可以忽略不计。测试过程中曾尝试过使用100k大小静态页面，结果显示在千兆内网下，无论是单Tomcat亦或是Nginx+2Tomcat，请求速度最大均不超过1000条/秒，网络带宽使用已经达到800M，接近千M内网上限。因此，实际应用中，网络带宽对整个web服务的影响会非常大

公开内部公开√ 机密

3.3 测试结果分析

1. 系统参数的影响分析

1） worker_processes 参数对Nginx性能的影响

测试过程中分别设定worker_processes为8、4、2、1时发现，该参数对nginx性能影响不大，对服务器资源消耗也没有太大影响，相关资料显示，该参数的值最好跟cpu核数相等，能够发挥最大性能，本次测试nginx所在服务器为2颗双核cpu，因此最终测试设定为4。 2） MaxThread参数对tomcat并发性的影响

本次测试tomcat的 MaxThread参数设定为500，进行13000条/秒并发测试时，tomcat启动并发线程过多，将服务器cpu耗尽。分析MaxThread虽能够提高tomcat并发能力，但前提是在一个合理的范围内，要确保服务器负载不会因为并发线程过多而急剧升高，从而停止响应。 3） -Xmx最大内存值对Tomcat能够持续响应高并发的影响

持续高并发请求状态下，有6次测试是因为tomcat内存达到指定最大值导致响应变慢，直至内存溢出停止响应，因此，Tomcat最大内存对tomcat能够持续响应高并发请求有很大的影响，调整该值，应该可以增加Tomcat响应高并发请求的总数，进而延长WEB服务能够支撑峰值的时间。 2. 各架构下的性能分析

1) Nginx+2Tomcat的最大并发性低于单Tomcat，Nginx+2Tomcat最快为8980条/秒，单Tomcat

为12986条/秒，分析可能是受nginx所在服务器性能影响所致。

2) 单tomcat在配置1.7g最大内存时，在持续超过1479条/秒的并发请求下，在稳定支撑约240

万次响应后，Tomcat内存达到1.7上限，之后Tomcat响应会急剧变慢，错包急剧上升。 3) Nginx+2tomcat架构下，2个tomcat分别配置1.7g最大内存时，在持续超过2900条/秒的并发

请求下，能够稳定支撑约540万次左右响应，之后两个Tomcat内存都会达到1.7上限，响应会急剧变慢，但错包情况并未出现。

4) 在Nginx+2tomcat，同时配置了缓存的情况下，可以达到1.5万以上的并发处理能力

3.4 评测结果

1) 单个tomcat的处理能力在500条/秒左右

单个tomcat能稳定支持每秒500左右的并发请求。

2) Nginx+Tomcat比单个Tomcat更稳定，不易出现错包，可以通过扩充tomcat集群（新增

tomcat服务器）来提升系统的并发能力

单个tomcat在超出并发能力的提求下，处理能力大大下降，并出现大量错包，而采用Nginx+2Tomcat架构在各种测试下，均未出现错包，但处理能力也会下降。

单个tomcat能稳定支持每秒500左右的并发请求，而Nginx+2Tomcat能支持每秒1000左右

4/15/2014

第33页,共38页Page 33 ,

Total38

公开内部公开√ 机密

的并发请求。所以可以通过新加tomcat服务器来提升系统的并发能力，但在tomcat的总体处理能力超过nginx的处理能力时无效。

3) Nginx+2Tomcat配置了缓存后，静态页面的并发能力不再受tomcat的限制，单个nginx的

并发处理能力能达到1.5万以上。

配置了缓存后，nginx+2tomcat的处理能力实测数据超过了1.5万次/秒，而单个tomcat可以支撑500次/秒，则从理论上计算一组Nginx+30个Tomcat集群可以支撑1.5万次/秒的并发处理。

注：为tomcat均分配1.7G内存。

4 配置选型

4.1 网络带宽

只考虑门户访问的带宽占用，后台管理页面等其他业务访问与门户访问相差2-3个数量级，这一部分网

络流量占用忽略。同时考虑网络带宽利用率（70%）根据业务设计能力，每秒网络流量=WEB网站每秒钟访问流量

=（每次访问占用的带宽×每秒访问次数）/带宽利用率 =(200K*8*n)/0.7

注：一般门户的首页大小>1M、平均200K/页面，我们以平均值来计算。

并发能力 100次/秒 200次/秒 500次/秒 1000次/秒

占用的网络带宽 228 M 457 M 1442 M 2286 M 4.2 架构和硬件配置选型

4.2.1 硬件配置参考

序号 1 1.1 产品功能主机设备参考型号、配置 TPMC IBM System x3850 M2, 4个处理器，每处理器为6核，共计数据库服务器 24核。内存大小16G。SAS硬盘，硬盘大小587 GB。4U 机架，684508 集成双千兆以太网接口，两块千兆的光纤网卡。 4/15/2014

第34页,共38页Page 34 ,

Total38

1.2 WEB服务器

公开内部公开√ 机密

IBM System x3850 M2, 4个处理器，每处理器为6核，共计24核。内存大于8G。SAS硬盘，硬盘大小587 GB。4U 机架，684508 集成双千兆以太网接口，两块千兆的光纤网卡。 IBM System x3560，1个Intel Xeon E5450处理器，内存大小2G，2U机架。 RADWARE应用负载均衡设备,型号:为ODS-504,有，4个可选的千兆位电端口,1G主内存,500M处理能力(最大可通过License升级为4G) CISCO ASA5520防火墙并发连接：280000 网络吞吐：450 安全过滤：225MB 网络端口：4个千兆以太网接口+1个快速用户数限：无用户数限制用户 VPN支持：支持 Quidway S3952P-EI 传输速率：10Mbps/100Mbps/1000Mbps 网络标准：IEEE 802.1Q、IEEE 802.1D 端口数量：48 接口介质：10/100Base-T、1000Base-X 传输模式：全双工/半双工自适应背板带宽：32Gbps 光纤存储柜（EVA4100）光纤交换机（ 4/32B SAN Switch） 32600 1.3 2 2.1 管理终端网络设备负载均衡器 2.2 防火墙 2.2 交换机 3 3.1 3.2 存储设备光纤存储柜光纤交换机注：上表为硬件的参考配置，根据网站规模的不同，在初期可以不用硬件负载均衡器。服务器性能也可以作适当缩减，达到一定规模后硬件的扩容请参考“4.3 硬件扩容策略”

4.2.2 Web架构和硬件选型

并发能力 Web服务器架构 1) Apache+n个Tomcat（n>=2）； 2) Nginx+n个Tomcat（n=2）； 1) Apache+n个Tomcat（n>=2）； 200~500次/秒 2) Nginx+n个Tomcat（n=2）；注：同时配置缓冲服务器配置备注 <200次/秒 2台web服务 2台数据库服务器 1台web服务器同时部署apache（nginx）和tomcat；另1台部署tomcat。一起实现web负载均衡。 1台生产数据库，1台查询数据库 1台web服务器装apache（nginx）；另2台web服务器tomcat； 1台生产数据库，1台查询数据库 3台web服务 2台数据库服务器 2台缓存服务器 >500次/秒 Nginx+n个Tomcat（n>=2）；注：同时配置缓冲 1台web服务器装nginx； n台web服务（n>5）其他web服务器tomcat；在web服务器>4m台数据库服务器台的时侯可以考虑划成多个2台缓存服务器 nginx+tomcat集群。 2台负载均衡器生产数据库用ORACLE的RAC集群，也可考虑多种数据库并存如用mysql. 版权所有，侵权必究All rights reserved

第35页,共38页Page 35 ,

Total38

4/15/2014

公开内部公开√ 机密

多个Nginx+n个Tomcat>1.5万次（n>=2）组合；注：同时配置缓冲 n台web服务（n>30）组成多个nginx+tomcat集群（1台ngix+5m台数据库服务器台tomcat）,通过负载均衡器分流。 2台缓存服务器数据库用ORACLE的RAC集群。 2台负载均衡器说明：

1）理论上单个tomcat可以支持500的并发，考虑到门户的高可用性，可以考虑用Nginx+n个Tomcat（n>=2）的负载均衡架构。

2）当并发>500时可以考虑增加tomcat服务器，当tomcat增加达到30个时理论可以支撑1.5万次的并发请求。

3）当并发>1.5万次时则需要考虑增加一套Nginx+tomcat的组合，多个Nginx+tomcat通过硬件或是软件负载均衡器来实现平载均衡。

4）以上的硬件配置没考虑其他复杂的应用需求，如有其他应用（大容量的文件存储、接口服务、复杂的计算等）需求则需要配置相应的硬件。

4.3 硬件扩容策略

当网站发展到一定阶段，随着用户量不断扩大，现有的网络资源和服务器资源不能满足用户需要的时候，就需要对平台进行服务器和网络的扩容。以下是两种平台扩容的方式：

4.3.1 增加服务器