1、公开 内部公开机密 绝密9/2/2019 版权所有，侵权必究All rights reserved 第1页 ,共 39页Page 1 , Total39前台门户网站架构设计方案北京宽连十方数字技术有限公司2012-7公开 内部公开机密 绝密9/2/2019 版权所有，侵权必究All rights reserved 第2页 ,共 39页Page 2 , Total39目 录1 设计思路 .32 系统结构 .33 网络规划及性能计算 .33.1 网络架构 .33.2 网络架构说明 .43.2.1 采用双防火墙双交换机做网络冗余，保障平台服务 .43.2.2 采用硬件设备负载均衡器，实现网络流量的负
2、载均衡 .43.3 系统测算 .43.3.1 系统处理能力要求 .43.3.2 业务处理能力要求 .43.3.3 系统话务模型 .43.4 配置核算 .53.4.1 数据库服务器性能核算 .53.4.2 WEB服务器集群性能核算 .53.4.3 WEB服务器集群内存性能核算 .53.4.4 网络带宽 .54 性能模拟测试及性能推算 .64.1 测试环境 .64.2 测试结果 .84.2.1 1个客户端模拟不同线和并发请求结果 .84.2.2 10个客户端请求 .84.3 结果分析 .94.4 根据测试结果推算 .94.5 设备清单 .114.5.1 硬件设备配置清单 .114.5.2 设备技术
3、规格 .124.6 平台扩容的建议 .12公开 内部公开机密 绝密9/2/2019 版权所有，侵权必究All rights reserved 第3页 ,共 39页Page 3 , Total391 网站的性能瓶颈分析网站的性能影响因素很多，下面主要从如下4个方面进行分析说明：1) 网络负载a) 公网负载b) 内网负载2) WEB应用服务器性能a) CPUb) 存储，I/O访问c) 内存d) 并发TCP/IP 连接数3) 数据库服务器性能a) 数据库参数配置b) 服务器性能（CPU、内存、存储）c) 数据结构的合理性4) 不同WEB应用的处理方式而对不同的性能瓶颈a) 对于静态的网站：静态的HT
4、ML页面严格地由标准的 HTML标示语言构成，并不需要服务器端即时运算生成。这意味着，对一个静态HTML 文档发出访问请求后，服务器端只是简单地将该文档传输到客户端。从服务器运行的那个时间片来看，这个传输过程仅仅占用了很小的CPU资源。对于静态HTML的访问瓶颈为：网络带宽、磁盘 I/O以及cache( 高速缓冲存储器) 。b) 对于动态页面因为服务器解析动态页面必须在其传输到客户端前就通过服务器来进行解释，这样就会给应用服务器添加额外的性能消耗，如果进一步要访问数据库，则会增加数据库服务器的性能消耗，则动态页面还有额外的瓶颈：应用服务器的性能，数据库服务器的性能。2 系统架构设计2.1 总体
5、思路为提高网站的高并发性能,提高开发效率及运营效率,主要按如下几个思路进行规划设计:2.1.1 负载均衡1) 四层交换负载均衡：采用负载均衡器来实现硬件级的四层交换负载均衡，或采用LVS来实现软件的四层交换负载公开 内部公开机密 绝密9/2/2019 版权所有，侵权必究All rights reserved 第4页 ,共 39页Page 4 , Total39均衡。2) 通过第三方软件来实现负载均衡,同时实现页面请求的缓存。通过Nginx实现反向代理服务器集群，同时搭建squid集群以作为静态页面和图片的缓存。3) 通过web服务器的配置来实现负载均衡即通过apache或是Nginx 将客户请
6、求均衡的分给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 不同网络用
7、户访问考虑1) 通过引入CDN 来解决不同网络服务商的接入速度问题，一般只能解决静态页面的访问问题。2) 在不同运营商机房部署服务器，通过镜像技术来实现不同网络服务商的接入速度问题。公开 内部公开机密 绝密9/2/2019 版权所有，侵权必究All rights reserved 第5页 ,共 39页Page 5 , Total392.2 总体架构2.2.1 网站的系统分层架构T o m a tA p a c h eW E B 服 务 器架 构数 据 存 储文 件共 享T o m a tN g i n x p r o x yS q u i d反 向 代 理 软 件（ 数 据 缓 存 ）数 据
8、库生 产 数 据 库 查 询 数 据 库H D F S负 载 均 衡 器负 载 均 衡. . .W E B 服 务（ A p a c h e + t o m c a t负 载 均 衡 ）硬 件 四 层 交 换C o n t r o lM V C应 用 架 构 M o d e l V i e w数 据 持 久 层( i b a t i s )应 用 级 缓 存页 面 缓 存( O S C a c h e )S q u i d c a c h e N g i n x c a c h eN F SL V S软 件 四 层 交 换数 据 缓 存( M e m c a c h e d )公开 内部公开机
9、密 绝密9/2/2019 版权所有，侵权必究All rights reserved 第6页 ,共 39页Page 6 , Total392.2.2 网站的物理架构I n t e r n e t服 务 器 2代 理 服 务 器 集 群（ N g i n x ）W e b 服 务 器 集 群 B负 载 均 衡 器 1. . .服 务 器 n服 务 器 2服 务 器 n服 务 器 1S q u i d 服 务 器 集 群服 务 器 1 服 务 器 2. . .用 户 浏 览 页 面服 务 器 2服 务 器 1服 务 器 1 服 务 器 2W e b 服 务 器 集 群 A服 务 器 1 服 务 器
10、2图 片 服 务 器 集 群服 务 器 3公开 内部公开机密 绝密9/2/2019 版权所有，侵权必究All rights reserved 第7页 ,共 39页Page 7 , Total392.2.3 网站的开发架构T o m a tA p a c h eW E B 服 务 器数 据 存 储文 件 存 储T o m a tH D F S. . .W E B容 器基 于 s t r u t s 的 M V C 框 架M o d e lV i e w持 久 层页 面 缓 存 （ M e m c a c h e d ）通 讯 层S M SM M SW A P P U S H短 信 群发 器彩 信
11、 群发 器数 据 库消息中心消 息中 心O R Mi b a t i sD B 连 接 池C 3 p 0H T M L 静态 化 模 块后 台 支撑 模 块业 务 支 撑模 块请 求数 据生 产 数 据 库（ R A C ）生 产 数 据 库（ R A C ）统 计 支 撑模 块I / OC o n t r o l业 务 层 数 据 层J D B C查 询 数 据 库公开 内部公开机密 绝密9/2/2019 版权所有，侵权必究All rights reserved 第8页 ,共 39页Page 8 , Total392.2.4 网络拓扑结构I n t e r n e t主 防 火 墙主 交 换
12、 机V R R P备 防 火 墙服 务 器 2服 务 器 1服 务 器 2服 务 器 n服 务 器 2服 务 器 2服 务 器 1 服 务 器 1代 理 服 务 器 集 群（ N g i n x ）网 站 服 务 器 集 群生 产 D B 服 务 器 集 群 查 询 D B 服 务 器 组光 纤 交 换 机光 纤 交 换 机磁 盘 阵 列 柜 磁 盘 阵 列 柜备 交 换 机负 载 均 衡 器 1负 载 均 衡 器 2. . .服 务 器 n服 务 器 2服 务 器 n服 务 器 1应 用 服 务 器 集 群管 理 终 端服 务 器 1 服 务 器 n. . .服 务 器 2服 务 器 1 服
13、 务 器 n图 片 服 务 器 集 群备注：1) 采用双防火墙双交换机做网络冗余，保障平台服务采用双防火墙通知接通2线路互联网接入，设备之间采用VRRP协议，在任何一个防火墙、互联网发生故障后均可自动将流量切换到另一端，保证网站的正运行，设备或网络恢复后，自动恢复。采用双千兆交换机分别接在2台防火墙上，当某台设备或者网络链路发生故障后，好设备自动接管已坏设备的工作，不影响网站的整体运行，根据业务及真实服务器的数量，交换机可以随时增加。2) 采用硬件设备负载均衡器，实现网络流量的负载均衡使用硬件设备负载均衡器，将网络流量均衡的分担到WEB服务器集群各节点服务器，保障平台服务器资源均衡的使用。3)
14、 采用代理服务器，实现软件级的网络负载均衡。4) 数据库服务器分离成生产数据库集群和查询数据库集群，实现生产读写与后台查询统计进行分离，同时生产数据库采用rac技术进行公开 内部公开机密 绝密9/2/2019 版权所有，侵权必究All rights reserved 第9页 ,共 39页Page 9 , Total392.3 架构涉及技术的详解2.3.1 负载均衡1. 基于DNS的负载均衡- 一个域名绑定多个IPDNS负载均衡技术是最早的负载均衡解决方案，它是通过DNS服务中的随机名字解析来实现的，在DNS服务器中，可以为多个不同的地址配置同一个名字，而最终查询这个名字的客户机将在解析这个名字
15、时得到其中的一个地址。因此，对于同一个名字，不同的客户机会得到不同的地址，它们也就访问不同地址上的Web 服务器，从而达到负载均衡的目的。这种技术的优点是，实现简单、实施容易、成本低、适用于大多数TCP/IP应用；但是，其缺点也非常明显，首先这种方案不是真正意义上的负载均衡，DNS 服务器将Http请求平均地分配到后台的Web服务器上，而不考虑每个Web服务器当前的负载情况；如果后台的Web服务器的配置和处理能力不同，最慢的 Web服务器将成为系统的瓶颈，处理能力强的服务器不能充分发挥作用；其次未考虑容错，如果后台的某台Web服务器出现故障，DNS服务器仍然会把DNS 请求分配到这台故障服务器
16、上，导致不能响应客户端。最后一点是致命的，有可能造成相当一部分客户不能享受Web服务，并且由于DNS 缓存的原因，所造成的后果要持续相当长一段时间(一般DNS 的刷新周期约为24小时)。所以在国外最新的建设中心Web 站点方案中，已经很少采用这种方案了。2. 通过硬件四层交换实现负载均衡在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了3. 通过软件四层交换实现负载均衡软件四层交换我们可以使用Linux上常用的LVS来解决，LV
17、S就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性。4. 通过反向代理服务器实现负载均衡反向代理服务器又称为 WEB 加速服务器，它位于 WEB 服务器的前端，充当WEB服务器的内容缓存器,反向代理服务器是针对 WEB 服务器设置的，后台 WEB 服务器对
18、互联网用户是透明的，用户只能看到反向代理服务器的地址，不清楚后台 WEB 服务器是如何组织架构的。当互联网用户请求 WEB 服务时， DNS 将请求的域名解析为反向代理服务器的 IP 地址，这样 URL 请求将被发送到反向代理服务器，由反向代理服务器负责处理用户的请求与应答、与后台 WEB 服务器交互。利公开 内部公开机密 绝密9/2/2019 版权所有，侵权必究All rights reserved 第10页,共39 页Page 10 , Total39用反向代理服务器减轻了后台 WEB 服务器的负载，提高了访问速度，同时避免了因用户直接与 WEB 服务器通信带来的安全隐患。目前有许多反向代
19、理软件，比较有名的有 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 反向代理服务器中缓存了该请
