门户网站架构设计文档

前台门户网站架构

设计方案

目录

1设计思路 (3)

2系统结构 (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.2WEB服务器集群性能核算.......................................................................... 错误！未定义书签。

3.4.3WEB服务器集群内存性能核算.................................................................. 错误！未定义书签。

3.4.4网络带宽 (35)

4性能模拟测试及性能推算 .......................................................................................... 错误！未定义书签。

4.1测试环境 .............................................................................................................. 错误！未定义书签。

4.2测试结果 .............................................................................................................. 错误！未定义书签。

4.2.11个客户端模拟不同线和并发请求结果..................................................... 错误！未定义书签。

4.2.210个客户端请求 .......................................................................................... 错误！未定义书签。

4.3结果分析 .............................................................................................................. 错误！未定义书签。

4.4根据测试结果推算 .............................................................................................. 错误！未定义书签。

4.5设备清单 (35)

4.5.1硬件设备配置清单 ...................................................................................... 错误！未定义书签。

4.5.2设备技术规格 .............................................................................................. 错误！未定义书签。

4.6平台扩容的建议 (35)

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

2.2.2 网站的物理架构

2.2.3 网站的开发架构

持久层通讯层

消息中心

业务层数据层

2.2.4 网络拓扑结构

主防火墙

备防火墙

光纤交换机

磁盘阵列柜磁盘阵列柜

负载均衡器1

负载均衡器2

备注：

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-c ache

注：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集群实现负载均衡。

重以及当时负荷分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;

}

expires 70;

}

这个配置会将https://www.wendangku.net/doc/4e15179425.html,/mem/abc指明到memcached的abc这个key去取数据。

Nginx目前没有写入memcached的任何机制，所以要往memcached里写入数据得用后台的动态语言完成，可以利用404定向到后端去写入数据。

Nginx传统缓存的缺点也是它和squid等缓存软件的不同之特色，所以也可看作其优

点。在生产应用中它常常用作和squid的搭档，squid对于带?的链接往往无法阻挡，

而nginx能将其访问拦住，例如：https://www.wendangku.net/doc/4e15179425.html,/?和https://www.wendangku.net/doc/4e15179425.html,/在squid上

会被当做两个链接，所以会造成两次穿透；而nginx只会保存一次，无论链接变成

https://www.wendangku.net/doc/4e15179425.html,/?1还是https://www.wendangku.net/doc/4e15179425.html,/?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.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组成。

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 进程的调用。

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

2.3.6 网络问题解决方案

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

电信机房多线机房网通机房

1. 智能DNS解析

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

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

2. CDN

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

CDN的全称是Content Delivery Network，即内容分发网络。它采取了分布式网络缓

存结构（即国际上流行的web cache技术），其目的是通过在现有的Internet中增加

一层新的网络架构，将网站的内容发布到最接近用户的网络"边缘"，使用户可以就

近取得所需的内容，解决Internet网络拥挤的状况，提高用户访问网站的响应速度。

从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的

用户访问网站响应速度慢的问题。(也就是一个服务器的内容，平均分部到多个服

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

目前，国内访问量较高的大型网站如新浪、网易等，均使用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，为什么还要学习其他东西

系统架构设计(模板)

XX项目 项目编号： 系统架构设计

目录 1、概述 (4) 1.1.系统的目的 (4) 1.2.系统总体描述 (4) 1.3.系统边界图 (4) 1.4.条件与限制 (4) 2、总体架构 (4) 2.1.系统逻辑功能架构 (4) 2.2.主要协作场景描述 (5) 2.3.系统技术框架 (5) 2.4.系统物理网络架构 (5) 3、数据架构设计 (5) 3.1.数据结构设计 (5) 3.2.数据存储设计 (6) 4、核心模块组件概要描述 (6) 4.1.<组件1>编号GSD_XXX_XXX_XXX (6) 4.1.1.功能描述 (6) 4.1.2.对外接口 (6) 4.2.<组件2>编号GSD_XXX_XXX_XXX (6) 4.2.1.功能描述 (6) 4.2.2.对外接口 (6) 5、出错处理设计 (6) 5.1.出错处理对策 (7) 5.2.出错处理输出 (7) 6、安全保密设计 (7) 6.1.网络安全 (7) 6.2.系统用户安全 (7) 6.3.防攻击机制 (7) 6.4.数据安全 (7) 6.5.应用服务器配置安全 (7) 6.6.文档安全 (8) 6.7.安全日志 (8) 7、附录 (8) 7.1.附录A外部系统接口 (8) 7.2.附录B架构决策 (8) 7.3.附录C组件实现决策 (8) 修订记录

1、概述 1.1.系统的目的 [必须输出] [请明确客户建立本系统的目的，建议引用需求说明书的内容。]

[必须输出] [描述系统的 ●总体功能说明 ●设计原则 ●设计特点] 1.3.系统边界图 [必须输出] [请明确本系统的范围及与其它系统的关系，划分本系统和其他系统的边界。同时描述本系统在客户整体信息化建设中的规划及定位情况，系统的设计必须遵守客户的信息化建设思路及规范，条件允许的情况下需画出本系统在客户信息化建设中的定位关系图。] 1.4.条件与限制 [可选项] [列出在问题领域，项目方案及其它影响系统设计的可能方面内，应当成立的假设条件，包括系统的约束条件。以及系统在使用上或者功能上的前提条件与限制。] 2、总体架构 2.1.系统逻辑功能架构 [必须输出] [系统总体架构图解释建议的系统方案，并描述其根本特征，主要描述系统逻辑功能组件之间的关系，就系统级架构画出模型。并针对每一组件给出介绍性描述。] 2.2.主要协作场景描述 [可选项] [描述系统组件之间的主要协作场景。]

软件结构设计规范模板

软件结构设计规范

精选编制： 审核： 批准：

目录 1.简介 (6) 1.1.系统简介 (6) 1.2.文档目的 (6) 1.3.范围 (6) 1.4.与其它开发任务/文档的关系 (6) 1.5.术语和缩写词 (6) 2.参考文档 (8) 3.系统概述 (9) 3.1.功能概述 (9) 3.2.运行环境 (9) 4.总体设计 (10) 4.1.设计原则/策略 (10) 4.2.结构设计 (10) 4.3.处理流程 (10) 4.4.功能分配与软件模块识别 (11) 5.COTS及既有软件的使用 (12) 5.1.COTS软件的识别 (12) 5.2.COTS软件的功能 (12)

5.3.COTS软件的安全性 (12) 5.4.既有软件的识别 (12) 5.5.既有软件的功能 (13) 5.6.既有软件的安全性 (13) 6.可追溯性分析 (14) 7.接口设计 (15) 7.1.外部接口 (15) 7.2.内部接口 (15) 8.软件设计技术 (16) 8.1.软件模块 (16) 8.2.数据结构 (16) 8.3.数据结构与模块的关系 (16) 9.软件故障自检 (17)

1.简介 1.1.系统简介 提示：对系统进行简要介绍，包括系统的安全目标等。 1.2.文档目的 提示： 软件结构设计的目的是在软件需求基础上，设计出软件的总体结构框架，实现软件模块划分、各模块之间的接口设计、用户界面设计、数据库设计等等，为软件的详细设计提供基础。 软件结构设计文件应能回答下列问题： 软件框架如何实现软件需求； 软件框架如何实现软件安全完整度需求； 软件框架如何实现系统结构设计； 软件框架如何处理与系统安全相关的对软/硬件交互。 1.3.范围 1.4.与其它开发任务/文档的关系 提示：如软件需求和界面设计文档的关系 1.5.术语和缩写词 提示：列出项目文档的专用术语和缩写词。以便阅读时，使读者明确，从

架构设计文档模板

架构设计?档模板 在软件设计的不同阶段应该设计不同的UML模型，将不同阶段输出的UML模型图放在?个? 档中，对每张模型图配以适当的?字说明，就构成?篇设计?档。 对于规模不太?的软件系统，我们可以将概要设计?档和详细设计?档合并成?个设计?档。 这?，我会展现?个设计?档示例模板，你可以参考这个模板编写你的设计?档。 ?档开头是设计概述，简单描述业务场景要解决的核?问题领域是什么。?于业务场景，应该 在专?的需求?档中描述，但是在设计?档中，必须要再简单描述?下，以保证设计?档的完 整性，这样，即使脱离需求?档，阅读者也能理解主要的设计。 此外，在设计概述中，还需要描述设计的?功能约束，?如关于性能、可?性、维护性、安全 性，甚?开发和部署成本??的设计?标。 然后就是具体的设计了，第?张设计图应该是部署图，通过部署图描述系统整个物理模型蓝 图，包括未来系统?什么样。 如果系统中包含?个?系统，那么还需要描述?系统间的关系，可以通过?系统序列图，?系 统活动图进?描述。 ?系统内部的最顶层设计就是组件图，描述?系统由哪些组件组成，不同场景中，组件之间的 调?序列图是什么样的。 每个组件内部，需要?类图进?建模描述，对于不同场景，?时序图描述类之间的动态调?关 系，对于有复杂状态的类，?状态图描述其状态转换。 具体示例模板如下： 1 设计概述 ……系统是?个……的系统，是公司……战略的核?系统，承担着公司……的?标任务。 1.1 功能概述 系统主要功能包括……，使?者包括……。 1.2 ?功能约束 ……系统未来预计?年?户量达到……，?订单量达到……，?PV达到……，图?数量达到 ……。 1.查询性能?标：平均响应时间<300ms，95%响应时间<500ms，单机T PS>100；

系统设计文档模板

系统设计说明书（架构、概要、详细）目录结构 虽然这些文档一般来说公司都是有模板的，但我写这些文档以来基本上是每写一次就把目录结构 给改一次，应该说这是因为自己对这些文档的理解开始加深，慢慢的越来越明白这些文档的作用 和其中需要阐述的东西，觉得这三份文档主要阐述了一个系统的设计和实现过程，从系统分解为层次、层次内的模块以及相互的接口、模块分解为对象以及对象的接口、实现这些对象接口的方法。这次又整了一份，A/ ，欢迎大家指正。 XXX架构设计说明书 （架构设计重点在于将系统分层并产生层次内的模块、阐明模块之间的关系）一?概述 描述本文的参考依据、资料以及大概内容。 二.目的 描述本文编写的目的。 三.架构设计 阐明进行架构设计的总体原则，如对问题域的分析方法。 3.1. 架构分析 对场景以及问题域进行分析，构成系统的架构级设计，阐明对于系统的分层思想。 3.2. 设计思想 阐明进行架构设计的思想，可参考一些架构设计的模式，需结合当前系统的 实际情况而定。 3.3. 架构体系 根据架构分析和设计思想产生系统的架构图，并对架构图进行描述，说明分层的原因、层次的职责，并根据架构图绘制系统的物理部署图，描述系统的部署体系。3.4. 模块划分 根据架构图进行模块的划分并阐明模块划分的理由，绘制模块物理图以及模

块依赖图。 341. 模块描述 根据模块物理图描述各模块的职责，并声明其对其他模块的接口要求。。 3.4.2. 模块接口设计 对模块接口进行设计，并提供一定的伪代码。 XXX概要设计说明书 （概要设计重点在于将模块分解为对象并阐明对象之间的关系） 一.概述 描述本文的参考依据、资料以及大概内容。 二.目的 描述本文的编写目的。 三.模块概要设计 引用架构设计说明书中的模块图，并阐述对于模块进行设计的大致思路。 3.1. 设计思想 阐明概要设计的思想，概要设计的思想通常是涉及设计模式的。 3.2. 模块A 3.2.1. 概要设计 根据该模块的职责对模块进行概要设计（分解模块为对象、描述对象的职责以及声明对象之间的接口），绘制模块的对象图、对象间的依赖图以及模块主要功能的序列图，分别加以描述并相应的描述模块异常的处理方法。 3.2.2. 模块接口实现 阐明对于架构设计中定义的模块接口的实现的设计。 XXX详细设计说明书 （详细设计重点在于对模块进行实现，将模块的对象分解为属性和方法，并阐述 如何实现）

《软件架构设计文档》模板资料

《软件架构设计文 档》模板

Software Architecture Document Version <1.0> Revision History Date Version Description Author < yyyy-mm-dd >