bs架构设计方案 - 图文

更新时间：2024-06-12 05:41:01 阅读量：综合文库文档下载

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

BS架构设计方案推荐度：
相关推荐

公开内部公开机密绝密√

网站架构设计方案

8/12/2013

第1页,共39页Page 1 , Total39

公开内部公开机密绝密√

1 2 3

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

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

8/12/2013

第2页,共39页Page 2 , Total39

公开内部公开机密绝密√

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来实现软件的四层交换负载均

第3页,共39页Page 3 , Total39

8/12/2013

公开内部公开机密绝密√

衡。

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) 在不同运营商机房部署服务器，通过镜像技术来实现不同网络服务商的接入速度问题。

8/12/2013

第4页,共39页Page 4 , Total39

公开内部公开机密绝密√

2.2 总体架构

2.2.1 网站的系统分层架构

硬件四层交换软件四层交换负载均衡反向代理软件（数据缓存）WEB服务（Apache+tomcat负载均衡）...WEB服务器架构MVC应用架构应用级缓存(ibatis)(OSCache)(Memcached)数据存储文件共享数据库 8/12/2013

第5页,共39页Page 5 , Total39

公开内部公开机密绝密√

这样客户端的 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缓存实现动静分离的架构图如下所示：

8/12/2013

第11页,共39页Page 11 , Total39

公开内部公开机密绝密√

5. Apache +tomcat集群实现负载均衡。

使用 apache和多个tomcat 配置一个可以应用的web网站，用Apache进行分流，把请求按照权重以及当时负荷分tomcat1,tomcat2...去处理，要达到以下要求：

8/12/2013

第12页,共39页Page 12 , Total39

公开内部公开机密绝密√

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只会保存一次，无论链接变成8/12/2013

第13页,共39页Page 13 , Total39

公开内部公开机密绝密√

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的形式单个对象缓存。

8/12/2013

第14页,共39页Page 14 , Total39

公开内部公开机密绝密√

3）自主开发的内存数据缓存服务 a）独立进程方式的缓存服务

对于一些常用的动态数据通过开发程序服务缓存在内存中，提供给其他子系统调用，如下面的数据就可以通过这样方式进行缓存。

1) 用户基本信息及状态的信息缓冲 2) 列表缓存，就像论坛里帖子的列表

3) 记录条数的缓存，比如一个论坛板块里有多少个帖子，这样才方便实现分页。 4) 复杂一点的group，sum，count查询，比如积分的分类排名 b）集成在WEB应用中的内存缓存

在web应用中对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力，比如：很多配置信息，操作员信息等等。 2.3.3 页面静态化

静态的HTML页面严格地由标准的HTML标示语言构成，并不需要服务器端即时运算生成。这意味着，对一个静态HTML文档发出访问请求后，服务器端只是简单地将该文档传输到客户端。从服务器运行的那个时间片来看，这个传输过程仅仅占用了很小的CPU资源。

页面静态化就是采用效率最高、消耗最小的纯静态化的html页面来替换动态页面。我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。

8/12/2013

第15页,共39页Page 15 , Total39

公开内部公开机密绝密√

同时采用第三方开源的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是不够的，还需要进行热备份，从而得到超快的速度和超高的可靠性。

8/12/2013

第16页,共39页Page 16 , Total39

公开内部公开机密绝密√

另外，在将所有备份文件从服务器上转移出来之前要进行压缩和加密。另外还要确保拥有设计合理的、有用的关于安全、性能和稳定性问题的设定，包括防止数据败坏，其中很多设定都是非常重要的。

2.3.5 文件存储 1. 文件共享 1） HDFS（GFS）

HDFS是Apache Hadoop项目中的一个分布式文件系统实现，基于Google于2003年10月发表的Google File System(GFS)论文。

? 特性

1) 硬件要求低 2) 高容错性 3) 易可扩展 4) 配置简单 5) 超大文件

HDFS采用master/slave架构。

一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。

第17页,共39页Page 17 , Total39

8/12/2013

公开内部公开机密绝密√

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. 文件的多服务器自动同步

使用Linux 2.6内核的inotify监控Linux文件系统事件。

利用开源的lsync监听某一目录，如果目录内文件发生增、删、改，利用Rsync协议自动同步到多台服务器。 3. 图片服务器分离

特别是如果程序与图片都放在同一个 APAHCE 的服务器下，每一个图片的请求都有可能导致一个 HTTPD 进程的调用。

使用独立的图片服务器不但可以避免以上这个情况，更可以对不同的使用性质的图片设置不同的过期时间，以便同一个用户在不同页面访问相同图片时不会再次从服务器（基于是缓存服务器）取数据，不但快速，而且还省了带宽。还有就是，对于缓存的时间上，亦可以做独立的调节。

8/12/2013

第18页,共39页Page 18 , Total39

公开内部公开机密绝密√

2.3.6 网络问题解决方案

你不可能要求所有的使用人员，都和你的服务器在一个运营商的网络内，而不同网络之间访问速度会很慢，我们可以采用镜像网站和引入CDN来解决这一问题。

用户动态内容（社区、投票、调查、搜索、点评、视频）静态内容（静态网页、图片）DNS解析电信用户网通用户CDN其他用户服务器1服务器n服务器1服务器n服务器1服务器n电信机房多线机房网通机房

1. 智能DNS解析

我们可以在不同的网络运营商部署web服务器，通过linux上的rsync工具自动同步到不同网络接入商的web服务器上，以作为主站的镜像。

然后通过配置智能DNS解析来引导不同网络的访问用户到对应的网络运营商的web服务器。 2. CDN

如果有足够的投资，也可以采用CDN(内容分发网)，把静态内容（静态页面和图片）进行CDN缓存，以减轻服务器压力。

CDN的全称是Content Delivery Network，即内容分发网络。它采取了分布式网络缓存结构（即国际上流行的web cache技术），其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络\边缘\，使用户可以就近取得所需的内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。 (也就是一个服务器的内容，平均分部到多个服8/12/2013

第19页,共39页Page 19 , Total39

公开内部公开机密绝密√

务器上，服务器智能识别，让用户获取离用户最近的服务器，提高速度。

目前，国内访问量较高的大型网站如新浪、网易等，均使用CDN网络加速技术，虽然网站的访问巨大，但无论在什么地方访问都会感觉速度很快。而一般的网站如果服务器在网通，电信用户访问很慢，如果服务器在电信，网通用户访问又很慢。

2.3.7 WEB应用开发架构设计思路 1. 基于MVC的三层应用开发架构

应用开发实现MVC三层架构进行web应用开发，采用ibatis作为持久层框架，c3p0作为数据库连接池。

iBATIS 是一个可以设计和实现更好的 Java 应用程序持久化层的框架。iBATIS 把对象和存储过程或者使用 XML 描述符的 SQL 语句进行了关联。简单是 iBATIS 最大的优势

? ibatis-使用ibatis的十个理由 1. 至少能操作10种以上的数据库 2. 可配置的caching(包括从属)

3. 支持DataSource、local transaction managemen和global transaction 4. 简单的XML配置文档

5. 支持Map, Collection, List和简单类型包装(如Integer, String) 6. 支持JavaBeans类(get/set 方法)

7. 支持复杂的对象映射(如populating lists, complex object models) 8. 对象模型从不完美(不需要修改) 9. 数据模型从不完美(不需要修改)

10. 你已经知道SQL，为什么还要学习其他东西

8/12/2013

第20页,共39页Page 20 , Total39

公开内部公开机密绝密√

1） MVC架构示意

8/12/2013

第21页,共39页Page 21 , Total39

公开内部公开机密绝密√

2） Struts架构

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

8/12/2013

第22页,共39页Page 22 , Total39

公开内部公开机密绝密√

2. 面向服务的应用架构

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

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

8/12/2013

第23页,共39页Page 23 , Total39

公开内部公开机密绝密√

这样就有了越来越多的应用服务器。这些应用服务器从数据众多的服务（每个服务背后都有数据库或集群数据库）中聚合信息，然后生成我们所看到的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。 8/12/2013

第24页,共39页Page 24 , Total39

公开内部公开机密绝密√

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

第25页,共39页Page 25 , Total39

8/12/2013

公开内部公开机密绝密√

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 8/12/2013

第31页,共39页Page 31 , Total39

公开内部公开机密绝密√

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毫秒 8/12/2013

第32页,共39页Page 32 , Total39

公开内部公开机密绝密√

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服务的影响会非常大8/12/2013

第33页,共39页Page 33 , Total39

公开内部公开√ 机密

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

8/12/2013

第34页,共39页Page 34 ,

Total39

公开内部公开√ 机密

的并发请求。所以可以通过新加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 集成双千兆以太网接口，两块千兆的光纤网卡。 8/12/2013

第35页,共39页Page 35 ,

Total39

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

第36页,共39页Page 36 ,

Total39

8/12/2013

公开内部公开√ 机密

多个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 增加服务器

对于web的并发处理有瓶颈时，新增的web服务器，把新增的web服务器填加到Web服务器集群中，以增加WEB的并发处理能力。