前台门户网站架构设计方案.doc

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

目 录
1 设计思绪 3
2 系统构造 3
3 网络规划及性能运算 3
3.1 网络架构 3
3.2 网络架构讲明 4
3.2.1 采纳双防火墙双互换机做网络冗余，保证平台服务 4
3.2.2 采纳硬件设备负载均衡器，实现网络流量的负载均衡 4
3.3 系统测算 4
3.3.1 系统处理能力规定 4
3.3.2 业务处理能力规定 4
3.3.3 系统话务模型 4
3.4 配置核算 5
3.4.1 数据库服务器性能核算 5
3.4.2 WEB服务器集群性能核算 5
3.4.3 WEB服务器集群内存性能核算 5
3.4.4 网络带宽 5
4 性能模拟测试及性能推算 6
4.1 测试环境 6
4.2 测试成果 8
4.2.1 1个客户端模拟不一样线和并发规定成果 8
4.2.2 10个客户端规定 8
4.3 成果分析 9
4.4 按照测试成果推算 9
4.5 设备清单 11
4.5.1 硬件设备配置清单 11
4.5.2 设备技术规格 12
4.6 平台扩容的提议 12

网站的性能瓶颈分析
网站的性能阻碍原因专门多，下面要紧从如下4个方面进行分析讲明：
网络负载
公网负载
内网负载
WEB应用服务器性能
CPU
储备，I/O访征询
内存
并发TCP/IP连接数
数据库服务器性能
数据库参数配置
服务器性能（CPU、内存、储备）
数据构造的合理性
不一样WEB应用的处理方式而对不一样的性能瓶颈
有关静态的网站：
静态的HTML页面严格地由原则的HTML标示语言构成，并不需要服务器端即时运算生成。这意味着，对一种静态HTML文档发出访征询规定后，服务器端只是简朴地将该文档传播到客户端。从服务器运行的那个时刻片来看，那个传播过程仅仅占用了专门小的CPU资源。有关静态HTML的访征询瓶颈为：网络带宽、磁盘I/O以及cache(高速缓冲储备器)。
有关动态页面
由于服务器解析动态页面必须在其传播到客户端前就通过服务器来进行讲明，如此就会给应用服务器添加额外的性能消耗，假如深入要访征询数据库，则会增长数据库服务器的性能消耗，则动态页面尚有额外的瓶颈：应用服务器的性能，数据库服务器的性能。
系统架构设计
总体思绪
为提高网站的高并发性能,提高开发效率及运行效率,要紧按如下几种思绪进行规划设计:
负载均衡
四层互换负载均衡：
采纳负载均衡器来实现硬件级的四层互换负载均衡，或采纳LVS来实现软件的四层互换负载均衡。
通过第三方软件来实现负载均衡,同步实现页面规定的缓存。
通过Nginx实现反向代理服务器集群，同步搭建squid集群以作为静态页面和图片的缓存。
通过web服务器的配置来实现负载均衡
即通过apache或是Nginx 将客户规定均衡的分给tomcat1,tomcat2....去处理。
WEB应用开发架构思绪
应用开发实现MVC架构三层架构进行web应用开发
页面尽量静态化以减少动态数据访征询，假如是资讯类的网站可以考虑采纳第三方开源的CMS系统来生成静态的内容页面。
采纳Oscache实现页面缓存,采纳Memcached实现数据缓存
采纳独立的图片服务器集群来实现图片资源的储备及WEB规定
数据储备的设计思绪
数据库拆分,把生产数据库和查询数据库分离，对生产数据库采纳RAC实现数据库的集群。
采纳高效的网络文献共享方略，采纳图片服务器来实现页面的图片储备。
不一样网络顾客访征询考虑
通过引入CDN来处理不一样网络服务商的接入速度征询题，同样只能处理静态页面的访征询征询题。
在不一样运行商机房布署服务器，通过镜像技术来实现不一样网络服务商的接入速度征询题。

总体架构
网站的系统分层架构

网站的物理架构

网站的开发架构

网络拓扑构造

备注：
采纳双防火墙双互换机做网络冗余，保证平台服务
采纳双防火墙告知接通2线路互联网接入，设备之间采纳VRRP协议，在任何一种防火墙、互联网发生故障后均可自动将流量切换到另一端，保证网站的正运行，设备或网络复原后，自动复原。
采纳双千兆互换机分别接在2台防火墙上当某台设备或者网络链路发生故障后，好设备自动接管已坏设备的工作，不阻碍网站的整体运行，按照业务及真实服务器的数量，互换机可以随时增长。
采纳硬件设备负载均衡器，实现网络流量的负载均衡
使用硬件设备负载均衡器，将网络流量均衡的分担到WEB服务器集群各节点服务器，保证平台服务器资源均衡的使用。
采纳代理服务器，实现软件级的网络负载均衡。
数据库服务器分离成生产数据库集群和查询数据库集群，实现生产读写与后台查询记录进行分离，同步生产数据库采纳rac技术进行

架构波及技术的详解
负载均衡
基于DNS的负载均衡--一种域名绑定多种IP
DNS负载均衡技术是最早的负载均衡处理方案它是通过DNS服务中的随机名字解析来实现的，在DNS服务器中，可认为多种不一样的地址配置同一种名字，而最终查询那个名字的客户机将在解析那个名字时得到其中的一种地址。因此，有关同一种名字，不一样的客户机会得到不一样的地址，它们也就访征询不一样地址上的Web 服务器，从而到达负载均衡的目的。
这种技术的长处是，实现简朴、实行轻易、成本低、合用于大多数TCP/IP应用；然而，其缺陷也专门明显，第一这种方案不是真正意义上的负载均衡，DNS 服务器将Http规定平均地分派到后台的Web服务器上，而不考虑每个Web服务器目前的负载情形；假如后台的Web服务器的配置和处理能力不一样，最慢的 Web服务器将成为系统的瓶颈，处理能力强的服务器不能充足发挥作用；另一方面未考虑容错，假如后台的某台Web服务器显现故障，DNS服务器仍旧会把DNS 规定分派到这台故障服务器上，导致不能响应客户端。最终一点是致命的，有也许导致相称一部分客户不能享有Web服务，同步由于DNS缓存的缘故，所导致的后果要持续相称长一段时刻(同样DNS的刷新周期约为24小时)。因此在国外最新的建设中心Web站点方案中，差不多专门少采纳这种方案了。
通过硬件四层互换实现负载均衡
在硬件四层互换产品领域，有某些著名的产品可以选择，例如Alteon、F5等，这些产品专门昂贵，然而物有所值，可以提供专门优秀的性能和专门灵活的治理能力Yahoo中国起初靠近台服务器使用了三四台Alteon就搞定了
通过软件四层互换实现负载均衡
软件四层互换我们可以使用Linux上常用的LVS来处理，LVS确实是Linux Virtual Server，他提供了基于心跳线heartbeat的实时劫难应对处理方案，提高系统的鲁棒性，同步可供了灵活的虚拟VIP配置和治理功能，可以同步满足多种应用需求，这有关分布式的系统来讲必不可少。
一种经典的使用负载均衡的方略确实是，在软件或者硬件四层互换的基础上搭建squid集群，这种思绪在专门多大型网站包括搜索引擎上被采纳，如此的架构低成本、高性能尚有专门强的扩张性。
通过反向代理服务器实现负载均衡
反向代理服务器又称为 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 系统上使用、最多功能也最完整的一套软体。
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地址。
Nginx
Nginx (“engine x”) 是俄罗斯人Igor Sysoev(塞索耶夫)编写的一款高性能的 HTTP 和反向代理服务器。
在国内，差不多有新浪博客、新浪播客、搜狐通行证、网易新闻、网易博客、金山逍遥网、金山爱词霸、校内网、YUPOO相册、豆瓣、迅雷看看等多家网站、频道使用 Nginx 服务器。
Nginx 特点如下：
工作在OSI模型的第7层（应用层）
高并发连接
官方测试可以支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数。
内存消耗少
在3万并发连接下，启动的10个Nginx 进程才消耗150M内存（15M*10=150M）。
配置文献专门简朴
风格跟程序同样通俗易懂。
成本低廉
Nginx为开源软件，可以免费使用。而购置F5 BIG-IP、NetScaler等硬件负载均衡互换机则需要十多万至几十万人民币。
支持Rewrite重写规则
可以按照域名、URL的不一样，将 HTTP 规定分到不一样的后端服务器群组。
内置的健康检查功能
假如 Nginx Proxy 后端的某台 Web 服务器宕机了，可不能阻碍前端访征询。
节省带宽
支持 GZIP 压缩，可以添加扫瞄器当地缓存的 Header 头。
稳固性高
用于反向代理，宕机的概率微乎其微。

Nginx+squid页面缓存来实现反向代理负载均衡
通过Nginx反向代理和squid缓存实现动静分离的架构图如下所示：

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

使用 apache和多种tomcat 配置一种可以应用的web网站，用Apache进行分流，把规定按照权重以及当时负荷分tomcat1,tomcat2...去处理，要到达如下规定：
Apache 做为HttpServer ，通过mod_jk连接器连接多种 tomcat 应用实例，并进行负载均衡。
同步还要配置session复制，也确实是讲其中任何一种tomcat的添加的session，是要同步复制到其他tomcat， 集群内的tomcat均有相似的session，并为系统（包括 Apache 和 tomcat）设定 Session 超时时刻。
缓存
系统架构方面的缓存
Squid缓存
架构方面使用Squid进行缓存。
注：SQUID使用了LM算法，LM确实是页面Header里时刻(Date)和Last-Modified时刻的差。Date同样是Squid从背面取页面的时刻，Last-Modified 同样是页面生成时刻。
Nginx的缓存功能
Nginx从0.7.48版本开始，支持了类似Squid的缓存功能；
缓存把URL及有关组合当作Key，用md5编码哈希后储存；
Nginx的Web缓存服务只能为指定URL或状态码设置过期时刻，不支持类似Squid的PURGE指令，手动清除指定缓存页面；
采纳MMAP实现，设置的缓存区大小不能超过物理内存+SWEB的值
location /mem/ {
    if ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" )
    {
     set $memcached_key "$1";
     memcached_pass     192.168.1.2:11211;
    }
    expires 70;
}
Nginx目前没有写入memcached的任何机制，因此要往memcached里写入数据得用后台的动态语言完毕，可以运用404定向到后端去写入数据。
nginx会专门诚实地将链接形式储存到文献系统中，如此有关一种链接，可以专门以便地查阅它在缓存机器上的缓存状态和内容，也可以专门以便地和别的文献治理器如rsync等配合使用，它完完全全确实是一种文献系统构造。
应用程序方面的缓存
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) 缓存过期：你可以有最大程度的操纵缓存对象的过期，包括可插入式的刷新方略（假如默认性能不能满足需要时）。
Memcached
memcached是高性能的分布式内存缓存服务器。同样的使用目的是，通过缓存数据库查询成果，减少数据库访征询次数，以提高动态Web应用的速度、 提高可扩展性。
Memcached是以Key/Value的形式单个对象缓存。

自主开发的内存数据缓存服务
独立进程方式的缓存服务
有关某些常用的动态数据通过开发程序服务缓存在内存中，提供应其他子系统调用，如下面的数据就可以通过如此方式进行缓存。
顾客差不多信息及状态的信息缓冲
列表缓存，就像论坛里帖子的列表
记录条数的缓存，例如一种论坛板块里有多少个帖子，如此才以便实现分页。
复杂一点的group，sum，count查询，例如积分的分类排名
集成在WEB应用中的内存缓存
在web应用中有关热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，有关需要频繁访征询的热点数据，采纳集中缓存(多种可以采纳负载均衡)，减轻数据库的压力，例如：专门多配置信息，操作员信息等等。
页面静态化
静态的HTML页面严格地由原则的HTML标示语言构成，并不需要服务器端即时运算生成。这意味着，对一种静态HTML文档发出访征询规定后，服务器端只是简朴地将该文档传播到客户端。从服务器运行的那个时刻片来看，那个传播过程仅仅占用了专门小的CPU资源。
页面静态化确实是采纳效率最高、消耗最小的纯静态化的html页面来替代动态页面。我们尽量使我们的网站上的页面采纳静态页面来实现，那个最简朴的措施实际上也是最有效的措施。
同步采纳第三方开源的CMS系统来实现网站内容的治理。有关大量内容同步频繁更新的网站，我们无法所有手动去挨个实现页面静态化，因此我们需要引入常见的信息公布系统(CMS)，信息公布系统(CMS)可以实现最简朴的信息录入自动生成静态页面，有关一种大型网站来讲，拥有一套高效、可治理的CMS是必不可少的。
在进行html静态化的时候还可以使用一种折中的措施，确实是前端持续使用动态实现，在一定的方略下通过后台模块进行定期把动态网页生成静态页面，并定期鉴定调用，那个能实现专门多灵活性的操作。
为了提高静态HTML的访征询效率，要紧可以对如下几种方面进行优化：网络带宽、磁盘I/O以及cache(高速缓冲储备器)。

数据库配置及优化
数据库集群
对生产数据库采纳RAC实现数据库的集群。
数据库及表的散列
把生产数据库和查询数据库进行分离，针对系统业务数据的特点，把大的表进行拆分，有关访征询较多的表采纳分区表。
使用读/写数据库分离，伴随系统变得越来越庞大，专门是当它们拥有 专门差的SQL时，一台数据库服务器一般局限性以处理负载。然而多种数据库意味着反复，除非你对数据进行了分离。更同样地，这意味着建立主/从副本系统，其中 程序会对主库编写所有的Update、Insert和Delete变更语句，而所有Select的数据都读取自从数据库（或者多种从数据库）。
尽管概念上专门简朴，然而想要合理、精确地实 现并不轻易，这也许需要大量的代码工作。因此，即便在开始时使用同一台数据库服务器，也要尽早打算在PHP中使用分离的DB连接来进行读写操作。假如对的 地完毕该项工作，那么系统就可以扩展到2台、3台甚至12台服务器，并具有高可用性和稳固性。
拥有良好的DB配置和备份
专门多企业都没有良好的备份机制，也不明白如 何恰当地完毕这项工作。只有imp是不够的，还需要进行热备份，从而得到超快的速度和超高的可靠性。
此外，在将所有备份文献从服务器上转移出来之前要进行压缩和加密。此外还要保证拥有设计合理的、有用的有关安全、性能和稳固性征询题的设定，包括防止数据败坏，其中专门多设定差不多上专门重要的。
文献储备
文献共享
HDFS（GFS）
HDFS是Apache Hadoop项目中的一种分布式文献系统实现，基于Google于10月刊登的Google File System(GFS)论文。
特性
硬件规定低
高容错性
易可扩展
配置简朴
超大文献
HDFS采纳master/slave架构。
一种HDFS集群是由一种Namenode和一定数目的Datanodes构成。

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同样没有这样庞大的规模。
文献的多服务器自动同步
使用Linux 2.6内核的inotify监控Linux文献系统事件。
运用开源的lsync监听某一名目，假如名目内文献发生增、删、改，运用Rsync协议自动同步到多台服务器。
图片服务器分离
专门是假如程序与图片都放在同一种 APAHCE 的服务器下，每一种图片的规定均有也许导致一种 HTTPD 进程的调用。
使用独立的图片服务器不仅可以幸免以上那个情形，更可以对不一样的使用性质的图片设置不一样的过期时刻，以便同一种顾客在不一样页面访征询相似图片时可不能再次从服务器（基因此缓存服务器）取数据，不仅迅速，并且还省了带宽。尚有确实是，有关缓存的时刻上，亦可以做独立的调剂。
网络征询题处理方案
你不也许规定所有的使用人员，都和你的服务器在一种运行商的网络内，而不一样网络之间访征询速度会专门慢，我们可以采纳镜像网站和引入CDN来处理这一征询题。

智能DNS解析
我们可以在不一样的网络运行商布署web服务器，通过linux上的rsync工具自动同步到不一样网络接入商的web服务器上，以作为主站的镜像。
然后通过配置智能DNS解析来引导不一样网络的访征询顾客到对应的网络运行商的web服务器。
CDN
假如有足够的投资，也可以采纳CDN(内容分发网)，把静态内容（静态页面和图片）进行CDN缓存，以减轻服务器压力。
CDN的全称是Content Delivery Network，即内容分发网络。它采用了分布式网络缓存构造（即国际上流行的web cache技术），其目的是通过在既有的Internet中增长一层新的网络架构，将网站的内容公布到最靠近顾客的网络"边缘"，使顾客可以就近获得所需的内容，处理 Internet网络拥挤的状况，提高顾客访征询网站的响应速度。从技术上全面处理由于网络带宽小、顾客访征询量大、网点分布不均等缘故所导致的顾客访征询网站响应速度慢的征询题。 (也确实是一种服务器的内容，平均分部到多种服务器上，服务器智能识别，让顾客猎取离顾客近来的服务器，提高速度。
目前，国内访征询量较高的大型网站如新浪、网易等，均使用CDN网络加速技术，尽管网站的访征询庞大，但不管在什么地点访征询都会感受速度专门快。而同样的网站假如服务器在网通，电信顾客访征询专门慢，假如服务器在电信，网通顾客访征询又专门慢。
WEB应用开发架构设计思绪
基于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，什么原因还要学习其他东西

MVC架构示意

Struts架构

客户端发送一种HTTP规定，通过Struts框架最终获得一种HTTP响应，这一过程专门重要，它是懂得Struts框架的重点。上图描述了Struts框架的构造，而下图通过一种活动图更详细描述同意规定直至返回响应的整个过程：

面向服务的应用架构

面向服务的应用架构是指构建可分布式的、去中心化的服务器平台，以提供许多不一样的应用，数据库被提成专门多种小部分，围绕每个部分都会创立一种服务接口(API),同步该接口是访征询数据库的唯独途径。最终数据库演变成一种专门庞大的共享资源。
这种架构是松散耦合的，同步围绕着服务进行构建。面向服务的架构提供应他们隔离特性，一种服务也许有专门多台数据库服务器，他们之间的数据是相通的，而对外他们的接口只有一种，别处是无法明白那个服务背面的数据组织是怎样搭建的。
如此多种服务如插件同样构成了一种开放的平台，如此团体的规模就会比较小，比较灵活。
注Amazon确实是采纳了这种架构来构 建的，它拥有上千台服务器。
系统软件参数优化
在一定的架构基础上，要提高并发处理能力则需要调整服务器的操作系统内核参数、web服务器（tomcat的参数、apache的参数、Nginx的参数），以使其性能到达最优化。
操作系统优化
调整系统的内核参数，增大连接数及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
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是个左右，Linux是1000个左右。

apache服务器优化
加大并发数量和关闭不需要的模块。由于apache专门消耗内存，尽量轻量化。
Apache在配置ContentType的时候可以尽量少支持，尽量少的LoadModule，保证更高的系统消耗和执行效率
同步配置apache和tomcat的组合使之能作到动静分离，apache处理静态页面，tomcat处理动态页面。
Nginx服务器的优化
worker_processes：该参数的值最佳跟cpu核数相等，可以发挥最大性能，假如nginx所在服务器为2颗双核cpu，则提议设定为4。
Web服务架构评测
要紧对基于tomcat和nginx+tomcat的web服务器的处理性能进行测试，以作为不一样性能规定下架构选型的根据
测试环境
网络环境
内网带宽
千M内网。
内网ping包延迟：< 0.1ms
网络拓扑示意

服务器配置
设备
硬件配置
操作系统
Nginx
IBM X3650
内存：4G
千兆网卡
Redhat linux as4
Tomcat1
Hp DL580 G4
内存：8G
千兆网卡
Redhat linux as5
Tomcat2
Hp DL580 G4
内存：8G
千兆网卡
Redhat linux as5
Test1
Hp DL580 G5
内存：4G
千兆网卡
Redhat linux as5
Test2
IBM X3650
内存：4G
千兆网卡
Redhat linux as4
软件环境
操作系统网络参数优化
用做测试的各台服务器，均在/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
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 ~* ".*\.(js|css|gif|jpg|jpeg|png|bmp|swf)$")
# {
# }
# if ($request_uri ~* "^/view/(.)$")
# {
# }
#}
#定义日志格式
log_format access '$remote_addr - $remote_user [$time_local] $request '
'"$status" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

#打日志