网站架构设计技术方案(火车票订票系统)

第一篇：网站架构设计技术方案(火车票订票系统)

xxx市xxxxx网管理中心

火 车 票 网 络 订 票 系 统 方 案

二零一二年二月 总体设计说明...............................................................................................................................2

1.1 项目概述...........................................................................................................................2 1.2 建设目标...........................................................................................................................2 1.3 建设原则...........................................................................................................................2 2 系统需求分析...............................................................................................................................3

2.1 服务器集群.......................................................................................................................3 2.2 负载均衡...........................................................................................................................3 2.3 数据库集群与库表散列...................................................................................................3 2.4 划分服务器....................................................................................................................4 2.5 不同网络用户的访问问题...........................................................................................4 3 系统架构设计...............................................................................................................................4

3.1 网站物理架构................................................................................................................4 3.2 Web应用开发架构.........................................................................................................5 3.3 网络拓扑结构................................................................................................................6 4 架构方案所涉及的技术...............................................................................................................7

4.1 负载均衡.........................................................................................................................7 4.2 页面静态化.......................................................................................................................8 4.3 MVC架构..........................................................................................................................9 4.4 CDN和镜像网站技术..................................................................................................10 5 网站的硬件扩容和升级.............................................................................................................11 5.1 增加服务器.....................................................................................................................11 5.2 升级服务器..................................................................................................................11 5.3 增加存储.......................................................................................................................11 5.4 网络扩容.......................................................................................................................12

实习生：杨茂饶

火车票网络订票系统设计方案 总体设计说明

1.1 项目概述

本次火车票网络订票系统项目是因为当前铁路局网上订票系统设计不合理造成用户订票难等原因而要求重新设计的。我们先前的火车票网络订票系统最主要的问题是在遭受高负载的情况下系统不能正常的运行，所以此问题也是该方案所要重点解决的。当此项目建成后，我们的火车票网络订票系统将大大减轻实地售票系统、电话订票系统的压力，使用户足不出户就能享受快速、高效的订票服务。

1.2 建设目标

该订票系统的设计要能解决当前网络订票系统订票难的问题，在高负载情况下要保证系统的正常工作。系统的建设要符合国家标准，必须要能满足当前大量用户的订票需求，能承受或杜绝同一个用户频繁对页面的点击所产生的流量。充分发挥订票系统的作用和效益。该系统采用先进成熟的技术进行建设并能根据需要为以后系统的升级做好准备。

1.3 建设原则

1.3.1 实用性

本次火车票订票系统要根据当前用户订票需求情况和系统未来的规划进行设计。结合实际使系统的性价比达到最高。1.3.2 可靠性

系统的设计要使之能长期稳定的运行，当遇到问题的时候还要能够快速有效的恢复。1.3.3 安全性

确保系统的线路设计和设备是否能安全正常工作，保证用户信息不向外泄漏。

1.3.4 兼容性与扩展性

本次网络订票系统的设计上采用先进成熟的技术设备，以保障系统的高效运行，也是为系统的扩充和升级做好准备。1.3.5 专业性

系统的设计遵照国家标准，符合国家要求。1.3.6 易管理性

系统的设计要便于管理，方便日常维护中的操作。系统需求分析

由于火车票网络订票系统建成后是为我们中国13亿人提供订票服务的，将不可避免的遭受由大量网页点击造成的网络高流量、高负载的情况。所以要求此系统要能克服这种严重的状况，保证整个系统正常、安全、可靠的运行。最终方便用户订票。

为了满足以上要求，该方案需要采取服务器集群、负载均衡、数据库划分、图片服务器分离等，不仅如此，还要考虑不同网络用户的访问问题。

2.1 服务器集群

服务器集群就是指把很多的服务器统一集中起来进行同一种服务，在客户端看起来就像是只有一个服务器在提供服务。集群可以利用多个计算机进行并行计算从而获得更高的计算速度，也可以使用多个计算机做备份，并且能使其中一台计算机坏了后整个系统依然能正常运行。此系统采用服务器集群技术，集群内的服务器能并发的处理来自网络的访问请求，当访问量过大时，各服务器共同承担访问处理的任务，这将大幅的提高系统的工作效率。除此之外，还可以根据需求添加集群中服务器的数量以增大集群的处理能力。

2.2 负载均衡

负载均衡就是把从网络中传输进系统的流量根据系统的实际工作情况进行分流和划分，然后再传输到各服务器进行处理。在此方案中将采用负载均衡器和Squid/Nginx反向代理服务器实现此功能，负载均衡器需要被放置在临近服务器集群的位置。由于采用的是服务器集群技术，但当网站系统访问量很大时，Web服务器集群里的各个服务器压力都会很大，所以我们使用负载均衡器来管理这些访问请求，把这些访问请求传输给集群中有空闲资源的服务器进行处理。这样就能充分的利用服务器集群的优势，不至于因为集群内一台服务器资源耗尽或出现故障而中断服务。

2.3 数据库集群与库表散列

数据库服务器在整个系统的地位非常的重要，因为网站的瓶颈问题大都出现在数据库身上。大型网站都有复杂的应用，这些应用必须使用数据库，在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

1.数据库集群

在数据库集群方面，不同类型的数据库都有自己不同的解决方案，使用了什么样的数据库，就参考相应的解决方案。

2.库表散列

在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的 3

模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。

2.4 划分服务器

按服务器种类来划分，我们一般把服务器划分为：图片服务器、页面服务器、数据库服务器、应用服务器、日志服务器等。对于访问量大的网站而言，分离单独的服务器是非常必要的。分离服务器后各个服务器只需要完成各自的功能和处理任务，这样把工作细化后系统的整体运行效率也会提升很多。

2.5 不同网络用户的访问问题

由于处于不同网络服务商的计算机想要相互通讯会比在同一网络服务商的计算机慢。为了解决此问题，本系统将通过引入CDN和镜像网站技术来解决不同网络服务商的接入速度问题。系统架构设计

3.1 网站物理架构

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

整个系统架构组成如图所示，该架构有负载均衡器、Nginx代理服务器集群

或Squid代理服务器集群以及其他种类的服务器集群。这样的架构设计能够使该系统在高负载的情况下依然能正常工作，同时系统的安全性因为有代理服务器集群的存在也会得到相当大的提高。3.1.1架构中的代理服务器

代理服务器是介于客户端和Web服务器之间的另一种服务器的存在，有了它之后，浏览器不能直接到Web服务器去取回网页，而是向代理服务器发出请求，信号会先传送到代理服务器，由代理服务器来取回浏览器所需要的信息并传回浏览器。

很多代理服务器都有很大的存储空间，它能不断的将新取得的数据存储到它本机的存储器上，如果浏览器所请求的数据在它本机存储器上有而且是最新的，那么它就不再从Web服务器上读取数据，而是直接将存储器上的数据直接传送给用户的浏览器，起到系统缓存的作用。这样就能显著的提高浏览器的速度和效率。

除了缓存功能之外，代理服务器还能连接内网与Internet充当防火墙。这是因为所有内部的主机通过代理服务器访问外界时，只映射为一个IP地址，所以外界不能直接访问到内部网络；同时还可以设置IP地址过滤，限制内外网络之间的相互访问。所以本系统中采用代理服务器集群技术是对整个系统的安全是大有裨益的。

3.1.2 架构中的Web服务器

Web服务器是指驻留于因特网上某类计算机的的程序。当客户端的Web浏览器连接到服务器上并请求文件时，服务器将处理该请求并将文件发送到浏览器上，文件附带的信息（文件类型）会告诉浏览器如何查看该文件。服务器使用Http超文本传输协议进行信息交流。Web服务器不仅能够存储信息，还能在用户通过Web浏览器提供的信息基础上运行程序。3.1.3 图片服务器分离

对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃。

3.2 Web应用开发架构

Web应用开发采用MVC架构。把各种应用程序划分为视图、模型和控制三部分。大部分Web应用程序都是用像ASP，PHP，或者CFML这样的语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。要想使用多种方式来访问我们的应用程序，就必须要把数据从表示层中分离开来，如此就要运用到MVC架构。

如图：

现在科技的发展和用户需求不断的提升要求我们提供越来越多的方式来访问应用程序。MVC模式允许用户使用各种不同样式的视图来访问同一个服务器端的代码。它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。例如，很多数据可能用HTML来表示，但是也有可能用WAP来表示，而这些表示所需要的命令是改变视图层的实现方式，而控制层和模型层无需做任何改变。

3.3 网络拓扑结构

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

3.3.1 采用双防火墙双交换机，保障平台服务

本系统采用双防火墙接通互联网，在任何一个防火墙或者互联网发生故障后都可以自动的将流量切换到另一端，保证网站的正运行，设备或网络的故障恢复后，自动恢复先前的运行状况。不但如此，系统所采用的双千兆交换机分别接在2台防火墙上，当其中某台设备或者网络链路发生故障后，好的设备自动接管已坏设备的工作，不影响网站的整体运行，根据真实服务器的数量，交换机还可以随时增加。

3.3.2 采用硬件设备负载均衡器，实现网络流量的负载均衡

使用硬件设备负载均衡器，将网络流量均衡的分担到WEB服务器集群的各节点服务器，保障平台服务器资源均衡的使用。3.3.3 采用数据库集群和库表散列

本系统采用了数据库集群和库表散列技术，将大幅提高数据库的存取和查询的处理能力，不仅如此，在本方案中还为集群配置了磁盘阵列，可以在极大程度上增加数据库的存储空间。架构方案所涉及的技术

4.1 负载均衡

4.1.1 基于DNS的负载均衡

DNS负载均衡技术是最早的解决负载均衡的技术。主要是这样实现的，由于在DNS服务器中可以为不同的网络地址配置同一个域名，在DNS服务器进行解析时，它随即的得到其中一个地址。所以对于同一个域名它所解析出的地址是会不同的，用户也就访问不了同地址的Web服务器，从而在一定程度上能起到均衡负载的作用。但基于DNS的负载均衡不是真正意义上的负载均衡，由于DNS服务器在进行地址解析时不会考虑到当前Web服务器的负载情况，如果其中一台Web服务器出现了故障，DNS服务器仍然回把地址解析到此台出现故障的服务器上，导致不能响应客户端。所以在这种情况下必然会导致很大一部分用户不能享受服务器所提供的服务。

4.1.2 基于硬件四层交换的负载均衡

本网站架构就使用了基于硬件四层交换的硬件设备，在硬件四层交换产品中有很多的产品可以选择，大多数的这些产品都是比较昂贵的，但都能提供与之相符合的功能，都是物有所值的。4.1.3 基于软件四层交换的负载均衡

软件四层交换的均衡负载可以使用Linux操作系统中的LVS来解决。4.1.4 通过反向代理服务器来实现负载均衡

反向代理服务器又称为Web加速服务器，它位于Web服务器的前端，充当WEB 7

服务器的内容缓存器,反向代理服务器是专门针对Web服务器设置的，在后台运行的Web服务器对互联网用户是透明的、不可见的，用户只能看到反向代理服务器的网络地址，但却不清楚后台的Web服务器是如何组织架构的。当互联网用户请求Web服务时，DNS服务器将所请求的域名解析为反向代理服务器的IP地址，这样 URL请求将会被发送到反向代理服务器，由反向代理服务器负责处理用户的请求与应答并与后台Web服务器进行交互。如此就利用反向代理服务器减轻了后台Web服务器的负载，提高了访问速度，同时也避免了因用户直接与Web服务器通信带来的安全隐患。如图所示：

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

4.2 页面静态化

4.2.1 什么是静态页面

静态页面是网页的代码都在页面中，不需要执行asp,php,jsp,.net等程序生成客户端网页代码的网页。静态页面不能自主管理发布更新页面。常见的静态页面有以.html扩展名结尾的、.htm扩展名结尾的页面。还有一点是必须注意的，静态页面并非是网页上没有动画就是静态页面。4.2.2 什么是动态页面

动态页面是通过执行asp,php,jsp,.net等程序生成客户端网页代码的网页。动态页面通常可以通过网站后台管理系统对网站内容进行更新管理。发布新闻，发布公司产品，交流互动，博客，网上调查等，这都是动态网站的一些功能，也是我们经常使用的。动态页面常见的扩展命有asp,php,jsp,cgi,.aspx等。当中需要我们注意的是动态页面的动态是指网站与客户端用户互动的意思，而并非网页上有动画就是动态页面。4.2.3 页面静态化

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

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

4.3 MVC架构

MVC是一个设计模式，它强制性的把应用程序的输入、处理和输出分开。使用MVC将应用程序分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。4.3.1 视图

视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，要求要以不同的界面呈现。如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。4.3.2 模型

模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。例如对数据库的处理。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。4.3.3 控制器

控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。4.3.4 MVC应用优势

1.适用性

MVC模式允许使用各种不同样式的视图来访问同一个服务器端的代码。满足了用户不同方式的访问需求。

2.快速部署

使用MVC模式使开发时间得到相当大的缩减，它使程序员集中精力于业务逻辑，界面程序员集中精力于表现形式上。

3.可维护性

分离视图和业务逻辑也使得WEB应用更易于维护和修改。在维护过程中可以细化和减少工作量。

4.4 CDN和镜像网站技术

由于网站的用户可能在不同的网络运营商的网络中，不同网络中信息的交互会比在同一网络中慢。为了解决这个问题，本方案就采用了CDN技术和镜像网站技术。

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

4.4.1 镜像网站

镜像网站是指将一个完全相同的站点放到几个服务器上，分别都可以有自己的网址，这些服务器上的网站就称为镜像网站。镜像网站和主站并没有什么太大的差别，或者可以说是主站的拷贝。镜像网站的主要优点是，用户如果不能对主站进行正常的访问（如服务器故障，网络故障或者是网速太慢），仍然能通过访

问镜像服务器获得服务。

所以在本次方案中，我们可以在不同的网络运营商部署web服务器，通过软件工具自动同步到不同网络接入商的web服务器上，以作为主站的镜像。然后通过配置智能DNS解析来引导不同网络的访问用户到对应的网络运营商的web服务器。

4.4.2 CDN技术

CDN的全称是Content Delivery Network，即内容分发网络。其基本思想是尽可能的避开互联网上有可能影响数据传输速度和稳定性的环节，使内容的传输速度更快、更稳定。通过在网络各处放置节点服务器所构成的在现有互联网基础之上的一层智能虚拟网络，CDN系统能够实时的根据网络流量和各节点的连接、负载状况以及到各用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务器节点上。其根本目的是使用户可以就近的获取所需内容，避开Internet网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。网站的硬件扩容和升级

根据当今时代的发展，中国将会有越来越多的人群加入网民的行列，当然也就会有更多的人愿意通过互联网来购票。所以随着用户的不断增多，为了满足用户的需求，网站对今后的发展和升级也是要必须考虑的。

5.1 增加服务器

当集群不能满足用户的访问要求时，可以考虑在集群中增加服务器，增大整个集群的访问处理能力。

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

当数据库有处理压力时，可以增加数据库服务器，增加数据库服务器加入数据库的集群中。

5.2 升级服务器

当集群中服务器的各项处理能力不能达到要求时，这时就可以考虑对服务器进行升级。对服务器的升级其实和增加服务器的作用相差无几。但是升级服务器会比增加服务器更加繁琐而且更加昂贵。所以我们一般都采用增加服务器的方法来解决问题。

5.3 增加存储

随着网站的用户访问量的扩大和网站的升级，当然所要存储的信息和数据也就会越来越多,以前的服务器磁盘不再能满足要求。所以此时应当考虑增加磁盘 11

容器或者设立一个新的存储服务器。

5.4 网络扩容

由不断增多的大量的用户访问造成了巨大的网络流量，很可能造成网络的阻塞。原来的网络带宽设计就会无法承受。所以在系统扩容中还要考虑重新申请更大的网络带宽。不仅如此，当带宽增大后，为了适应更大的网络流量，内网交换机的升级也是必须的。

第二篇：火车票订票管理系统++设计报告

摘要

随着时代的发展，计算系软件和系统的成熟，火车票的正当管理成为一个影响铁路部门正常运营的因素之一，而建立火车票订票管理系统是一个很好的解决办法。作为计算机应用的一部分，使用计算机对火车票信息进行管理，具有手工管理所无法比拟的优点，例如检索迅速、查找方便、可靠性高、存储量大、保密性好等，这些优点能够极大的提高火车票信息管理的效率，也正体现了火车票的科学化正规化管理 现在随着社会的发展，数据量急剧增长，现在人们就借助计算机和数据库技术科学的保存大量的数据，以便能更好的利用这些数据资源。本论文就是通过MFC的整体设计把数据库与应用程序相连接，做成一个火车票的订票管理系统，使得火车票管理员能够有效的管理车次信息、旅客信息、退票信息等。同时用户可以通过查询到相关的火车票信息，选择是否适合自己，也可以在网上直接订票、退票，省时省力。

关键字： SQL2000，MFC，数据库设计，火车票订票系统 目录

第一章概述

1.1项目开发背景 1.2系统开发目的 1.3技术可行性研究 第二章开发平台介绍 2.1 系统的架构

2.2系统运行环境操作系统 2.3系统开发环境 2.4开发工具

第三章数据库设计 3.1系统详细调查 3.2数据流图 3.3数据库设计

第四章系统的界面设计

4.1主窗口界面

4.2旅客信息窗口

4.3车次信息窗口

4.4取票及退票窗口 第五章系统的实现

总结与展望 致谢 参考文献 需求分析

需求分析的任务

调查机票预定系统应用领域涉及的内容，对涉及到领域的各个应用的信息要求和操作要求进行详细分析，形成需求分析说明书。最重要的是调查、收集信息、分析购票人信息和火车预定流程。处理要求、数据的安全性与完整性要求。

要求系统能有效、快速、安全、可靠和无误的完成上述操作。并要求客户机的界面要简单明了，易于操作，服务器程序利于维护。需求分析的过程

火车站为方便旅客，需开发一个火车票预定系统。为便于旅客由网上定票，把预定火车票的旅客信息，包括姓名、性别、工作单位、身份证号码、出发时间、目的地，输入火车票订票系统的客户端程序，系统经过查询火车站内的列车车次数据服务器后，为旅客安排列车，印出取票通知。旅客在火车出发前一天凭取票通知和帐单交款后取票，系统校对无误后即印出火车票给旅客。如果某方面出现问题，旅客可以持有效证件去火车站退票。

要求系统能有效、快速、安全、可靠和无误的完成上述操作。并要求客户机的界面要简单明了，易于操作，服务器程序便于维护。数据字典与流程图

经过可行性分析和初步需求调查，抽象出该系统业务流程图，结合该实例具体情况，给出旅客信息、订票信息和取票通知的具体需求。

图2.1 旅客购票流程图 ⑴调查用户需求 ①售票处需求 功能：旅客持个人证件去火车站购买火车票。希望能通过旅客姓名查到该旅客的列车车次并记录旅客基本信息。统计功能：

按火车票统计买票人数 按姓名统计火车票数 ②旅客购票需求 交费功能： 交费 退费

③取票需求 通知功能： 通知旅客取票 统计功能：

统计通过验证的人数 统计可以取票的人 统计未通过验证的人数 查询功能： 购票旅客查询 购票旅客姓名 购票旅客身份证号 购票旅客订单号 ④列车车次信息需求 查询功能： 车次 始发站 终点站 始发时间 系统框架 在调查完了用户需求之后，就要开始分析用户需求。在此，我们们采用自顶向下的结构化分析方法（SA方法）。首先，定义全局概念结构的框架，如图2.2所示。

图2.2火车票预定系统总框架图

各子系统需要进一步细化。旅客信息系统为例进一步细化，如图2.3所示。

图2.3旅客信息系统细化

以其中的查询旅客信息功能为例进一步细化，如图2.4所示。

图2.4查询旅客信息功能

图2.5列车车次信息系统细化

图2.6取票通知系统细化

图2.7旅客信息系统能查询到的内容

图2.8火车票信息系统能查询到的内容

图2.9退票信息系统细化

将所有子系统全部细化。将所有用户需求分析完毕之后，就要开始构造数据字典了。经分析之后，本系统要用到五个基本表：退票信息表，旅客信息表，列车车次信息表，取票通知信息系统，列车座位信息表。数据结构定义如表2.1所示。表2.1 数据结构定义 数据结构名

含义说明

组成退票信息

定义了退票旅客的有关信息

旅客姓名，身份证号，订单号，电话号

旅客

定义了旅客有关信息

旅客姓名，身份证号，性别，工作单位，电话号

列车车次信息表

定义了车次 的有关信息

车次号，始发地，目的地，始发时间

取票通知单

定义了取票通知相关有关信息

旅客姓名，取票时间，列车车次，座位号，火车票类型

列车座位信息表

定义了列车座位有关信息

列车号，座位号,座位信息，火车票类型

概念结构设计

概念结构设计的方法与步骤 概念结构设计的方法

概念设计阶段我们采用自底向上的方法，即自顶向下的进行需求分析，然后再自底向上的进行概念结构设计。对已经细化到无法再分的阶段逐步集成在一起，最终合成一个全局概念模式。

概念结构设计的步骤

第一步是进行局部视图的设计：由于高层的数据流图只能反映系统的概貌，而中层流图能较好的反映系统中各局部应用的子系统组成。因此我们们先逐一的设计分E-R图。

第二步是进行视图的集成：各子系统的E-R图设计好之后，下一步就是要将所有的分E-R图合成一个系统的总E-R图，一般有两个方式，多个分E-R图一次集成，另一种是一次集成两个分E-R图。我们想采用一次集成两个分E-R图的方式。数据抽象与局部视图设计

按照图2.2机票预定系统总框架图，设计实体属性图以及局部E-R图。

图3.1退票信息系统

图3.2旅客信息系统 ……图3.3列车车次信息

图3.4取票通知信息

图3.5列车座位信息表

图3.6旅客购票局部E-R 视图的集成

经过逐步细化再进行每两个一集成初步形成一个E-R图，最后得到图3.4总体概念结构E-R图

图3.4系统总体结构E-R图

逻辑结构设计

E-R图向关系模型的转换

将图3.4总体概念结构E-R图转化成关系模型。退票信息（订单号，旅客姓名，电话号,身份证号）

旅客（旅客姓名，身份证号，电话号，性别，工作单位)车次信息表（车次号，始发站，终点站，始发时间）

取票通知单（旅客姓名，取票时间，车次号，座位号，车票类型）列车座位信息表（座位号，车次号,座位信息，车票类型）数据模型的优化

将转化的关系模式进行优化，最终达到第三范式。

1、确定数据依赖

退票信息（订单号，旅客姓名，电话号,身份证号）根据这个关系写出数据依赖 订单号→旅客姓名，订单号→电话号，订单号→身份证号 旅客（旅客姓名，身份证号，电话号，性别，工作单位)旅客姓名→身份证号，旅客姓名→电话号，旅客姓名→性别，旅客姓名→工作单位 车次信息表（车次号，始发地，目的地，始发时间）列车车次→始发站，列车车次→终点站，车次→始发时间

取票通知单（旅客姓名，取票时间，车次号，座位号，机票类型）旅客姓名→取票时间，旅客姓名→车次号，旅客姓名→座位号，旅客姓名→车票类型

火车座位信息表（座位号，车次号,座位信息，车票类型）（座位号，车次号）→座位信息，（座位号，车次号，座位信息）→车票类型 对各关系模式间数据依赖进行极小化处理，消除冗余

订单号→旅客姓名，订单号→电话号，订单号→身份证号，旅客姓名→性别 旅客姓名→工作单位，旅客姓名→取票时间，旅客姓名→车次号

旅客姓名→座位号，旅客姓名→车票类型，车次号→始发站，列车号→终点站 车次号→始发时间，（座位号，车次号）→座位信息

看这些模式是否符合要求，确定是否要对某些模式进行合并或者分解 最终分解成第三范式：

（订单号，电话号，身份证号）（订单号，旅客姓名）（旅客姓名，取票时间，性别，工作单位，车票类型）（旅客姓名，车次号）（旅客姓名，座位号）（车次号，座位号，车票类型）（车次号，始发站，终点站，始发时间）

第三篇：软件工程课设-网上火车票订票系统

目录

1.选题意义.................................................................1 2.网上火车票订票系统要达到的目标及限制......................................1 2.1 要达到的目标...........................................................1 2.1.1功能目标...........................................................1 2.1.2 质量及性能目标.....................................................2 2.2 限制...................................................................2 3.用例、事件流及对应活动....................................................3 3.1 系统用例图.............................................................3 3.2 用户注册...............................................................3 3.2.1用例简述...........................................................3 3.2.2 基本事件流.........................................................3 3.2.3 活动图.............................................................4 3.3 用户登录系统...........................................................4 3.3.1 用例简述.........................................................4 3.3.2 基本事件流.......................................................4 3.3.3 活动图...........................................................5 3.4 用户退出系统...........................................................5 3.4.1 用例简述...........................................................5 3.4.2 基本事件流.........................................................5 3.5 按起点终点和出发日期浏览车票...........................................6 3.5.1 用例简述...........................................................6 3.5.2 基本事件流.........................................................6 3.5.3 活动图.............................................................6 3.6 订单生成及支付.........................................................7 3.6.1 用例简述...........................................................7 3.6.2 基本事件流.........................................................7 3.6.3 活动图.............................................................7 3.7 查看订单...............................................................8 3.7.1 用例简述...........................................................8 3.7.2 基本事件流.........................................................8 3.7.3 活动图.............................................................8 3.8 退票...................................................................8 3.8.1 用例简述...........................................................8 3.8.2 基本事件流.........................................................8 3.8.3 活动图.............................................................8 3.9 业务数据管理...........................................................9 3.9.1 用例简述...........................................................9 3.9.2 基本事件流.........................................................9 3.9.3 活动图.............................................................9 3.10 管理员账号管理.......................................................10 3.10.1 用例简述.........................................................10 3.10.2 基本事件流.......................................................10

3.10.3 活动图...........................................................10 4.类图....................................................................11 5.主要时序图..............................................................11 5.1 注册..................................................................11 5.2检索车票..............................................................12 5.3 选座购票..............................................................12

1.选题意义

铁路作为中国最重要的交通工具之一，在市场经济浪潮中，面临着严峻的考验。公路运输的便捷，航空运输的快速，这一切都对铁路运输构成很大的冲击。火车站市场的管理和规范问题，是困扰我们多年的一个老问题，也是政府管理中的一个难点，订票是客运业务中的一个最基本的业务，表面上看，它只是火车站业务的一个简单的部分，但是它涉及到管理与客户服务等多方面，因此，随着我国铁路交通的不断发展，过去传统的售票方式已经不能满足现代客运业务流量剧增的客观要求，简单的窗口售票模式已经不能满足方便人们出行的目的。采用先进的网络技术开发出方便快捷的网上订票系统是现代客运业务发展的必然要求。电子商务的出现，正好带给了铁路客运服务一个发展契机，推出新型的订票方式——网上订票，来缓解订票高峰时期的客运压力，并为用户提供方便快捷的订票服务。它既是技术上的创新，又将完善铁路服务，在一定程度上解决买票难这一大难题，增强铁路竞争力，为铁路争取到更多的客流。本次设计的火车票网上订票系统通过访问主页，可以实现个人信息注册、车次车票价格查询、在线订票退票等基本功能，为用户提供快捷方便的订票服务。

2.网上火车票订票系统要达到的目标及限制 2.1 要达到的目标 2.1.1功能目标

网上火车票订票系统登录管理个人信息管理选座订单管理注册登录查询修改选择起点终点及出发日期选择出发时刻选择座位等级下订单付款 显示取票信息退票显示历史订单图2-1-1用户功能模块图

从用户角度看：

（1）注册：普通用户可以进行注册，输入的注册信息要进行验证，验证正确后将信息存入数据库。

（2）登录：已经注册的普通用户可以正确登录，在登录页面输入信息时，如果信息输入正确可以正确登录进入系统；如果信息输入错误，能够看到信息输入错误提示，并且停留在该系统登录页面。

（3）查询：用户可以实现对个人信息的查询、车次信息的查询和已订车票信息的查询。要求： 对个人信息的查询和修改，用户可以查看并修改自己的基本信息。

2）对车次的查询，可以按照始发站和终点站进行查询。3）对订单的查询，用户可以查看自己订单的所有车票信息。

（4）添加：用户可以进行订票来添加订单。

（5）退票：用户可以对自己已付款订单车次的车票进行退票操作。

网上火车票订票系统1）

登录查询数据管理个人信息车次站点已注册用户添加删除修改 图2-1-2管理员功能模块图

从管理员的角度看：

（1）登录：管理员可以通过登录权限进入管理员模式。

（2）查询：管理员可以对个人信息进行查询、对现有车次进行查询、对站点进行查询和对已注册用户信息进行查询。

1）对个人信息的查询，管理员可以查看自己的基本信息。

2）对车次的查询，可以按照发车车次进行查询，也可以按照始发站和终点站进行查询。

3）对站点的查询，管理员查看所有已存在站点的信息。

4）对已注册用户的查询，管理员可以查看本系统中所有已注册用户的基本信息和其订单信息。

（3）添加：管理员可以实现对车次的添加、对站点的添加和对车票信息的添加。

（4）删除：管理员可以实现对车次的删除、对站点的删除和对车票信息的删除。

（5）管理员可以修改站点信息、车次信息和车票信息。

（6）管理员也可以创建、管理更低权限级别的管理员的权限级别等信息。2.1.2 质量及性能目标

系统使用时，登录、注册、检索浏览车票、生成订单等流程正常。系统可迅速且正确地响应用户的请求。2.2 限制

用户仅能修改自己的信息，不能修改管理员信息、车票信息等数据。

管理员不可以修改更高权限及相同权限级别的管理员的信息。管理员账号只 能由更高级别的管理员创建产生，不能由注册产生，也不能由同权限级别或者更低权限级别的管理员创建产生。系统默认内置一个超级管理员账号，该管理员拥有最高管理权限。

3.用例、事件流及对应活动

网上火车票订票系统描述的主要用例有：普通用户注册，用户（普通用户/管理员）登录系统，用户（普通用户）退出系统，车票浏览，查看订单，检索车票，显示车票信息，订单生成及支付，业务数据管理，管理员账号管理。

3.1 系统用例图

业务数据管理查看历史订单退出系统登录会员管理员查询车次信息管理员账号管理生成订单及支付

图3-1 系统用例图

3.2 用户注册 3.2.1用例简述

用户在购票网站上输入注册信息，成为注册用户。3.2.2 基本事件流

1、用户：在会员注册画面，输入用户编号、密码、用户姓名、证件编号、电子邮件地址和联系电话等信息，提交注册请求；

2、系统：对用户的信息进行检查；

3、系统：用户的信息被系统保存；

4、系统：保存注册信息，提示用户注册成功；

5、用例结束。3.2.3 活动图

用户系统输入注册信息显示注册界面提交注册信息检查注册信息是否合法保存注册信息显示注册成功

图3-2 用户注册活动图

3.3 用户登录系统 3.3.1 用例简述

用户输入合法的用户名和密码后，登录系统。3.3.2 基本事件流

1、用户：在用户登录页面上，输入用户名和密码；

2、系统：根据用户名和密码检索系统，获得用户信息；

3、系统：显示用户登录成功，用户身份由游客变为注册用户；

4、结束用例。3.3.3 活动图

用户系统显示登录界面输入注册信息检查登录信息是否正确显示登录成功

图 3-3 用户登录系统活动图

3.4 用户退出系统 3.4.1 用例简述

用户退出系统。3.4.2 基本事件流

1、用户：提交退出系统的请求；

2、系统：注销用户，显示退出成功；

3、用例结束。3.4.3 活动图

用户系统用户提交退出请求显示退出成功

图 3-4 用户退出系统活动图 3.5按起点终点和出发时间检索车票 3.5.1 用例简述

根据用户选择的起点终点以及出发日期显示列车信息。3.5.2 基本事件流

1、用户：选择起点和终点以及出发日期；

2、系统：检查起点和终点是否正确；

2、系统：显示符合用户选择的列车信息；

3、用户：选择某辆列车；

4、系统：显示用户选择的列车的车票信息；

5、用例结束。3.5.3 活动图

用户系统显示查票界面输入起点、终点、出发日期起始点是否正确显示各时间的列车信息选择某辆列车显示车票信息

图 3-5按照起点终点和出发日期检索车票活动图 3.6 订单生成及支付 3.6.1 用例简述

用户下单并完成支付，系统检查是否完成支付。3.6.2 基本事件流

1、用户：选择车次、座位；

2、用户：提交订单请求；

3、系统：检查用户是否已经登录；

4、系统：检查座位选择是否有效；

5、系统：生成订单，显示付款页面；

6、用户：选择支付方式，输入付款信息，进行付款；

7、系统：检查支付信息是否正确，是否完成支付；

8、系统：存储并显示车票信息等订单详情；

9、用例结束。3.6.3 活动图

用户系统选择车次、座位提交订单请求检查登录信息是否正确检查座位选择是否正确选择付款方式生成订单，显示付款界面付款检查是否完成支付保存订单信息

图 3-6订单生成及支付 3.7 查看订单 3.7.1 用例简述

顾客查看自己的历史订单。3.7.2 基本事件流

1、用户：提交查看历史订单请求；

2、系统：显示该用户所有的历史订单信息；

3、用户：选择某一条订单；

4、系统：在订单详细页面显示用户选择的某一条订单的详细信息；

5、用例结束。3.7.3 活动图

用户系统提交查看历史订单请求显示历史订单列表选择某一条订单显示选中的订单详情

图 3-7 查看订单活动图

3.8 退票

3.8.1 用例简述

顾客选择退掉已经购买的车票。3.8.2 基本事件流

1、用户：选择已购买的车票并提交退票请求；

2、系统：检查退票请求是否合法；

3、系统：显示退票成功，返回原来页面；

4、用例结束。3.8.3 活动图

用户系统显示退票界面选择车票并提交退票请求退票请求是否合法显示退票成功

图 3-8 退票活动图

3.9 业务数据管理 3.9.1 用例简述

管理员管理商品，订单，会员等相关的业务数据，包括对数据的新增，更新，删除，查询。3.9.2 基本事件流

1、管理员：实施业务数据的新增，更新，删除，查询操作；

2、系统：检查管理员登录信息；

3、系统：保存管理员对业务数据的相关操作；

4、用例结束。3.9.3 活动图

管理员系统管理业务数据检查管理员登录信息检查管理员权限保存管理员操作

图 3-10业务数据管理 3.10 管理员账号管理 3.10.1 用例简述

管理员实现对较低级别的管理员账号的管理。3.10.2 基本事件流

1、管理员：对系统中的较低级别的管理员账号进行新增，更新，删除，权限更改等操作；

2、系统：检查管理员登录信息；

3、系统：保存管理员的操作；

4、用例结束。

3.10.3 活动图

管理员系统管理管理员账号检查管理员登录信息检查管理员权限保存管理员操作

图 3-11 管理员账号管理 4.类图

订单-下单时间 : string-价格 : float-起点 : string-终点 : string-出发时间 : string-站台号 : string1-列车编号 : string-座位号 : string火车票-列车编号 : string-价格 : float-起点 : string-终点 : string-出发时间 : string-到达时间 : string-座位等级 : string-座位号 : stringm..n管理员-ID : string-用户名 : stringm..n-密码 : string-权限 : string-特性1-手机号 : string-地址 : string-真实姓名 : stringm..n+登录()+退出()+业务数据管理()+管理员账号管理()*1*注册用户-ID : string-用户名 : string-密码 : string-身份证号 : string-手机号 : string-E-mail : string-地址 : string-真实姓名 : string-注册时间 : string+登录()+退出()+检索车票()+选座下单()+查看订单()+支付()+个人信息管理()未注册用户-ID : string+注册()0..11m..n

图 4-1 类图

5.主要时序图 5.1 注册

注册界面注册系统注册用户表用户输入注册信息提交注册请求[未填写注册信息]填写注册信息提交注册信息进行合法性检查[注册信息合法]保存注册信息返回保存结果返回注册结果显示注册结果

图 5-1 用户注册时序图 5.2检索车票

检索界面检索系统车票用户选择起点终点及出发日期[未填写查询信息]填写查询信息提交查询信息检索信息返回检索结果返回检索结果显示检索结果

图 5-2 检索车票时序图

5.3 选座购票

选座界面选座系统座位表订单界面订单系统订单表用户点击选座提交选座请求查询剩余座位返回座位数据返回座位数据请求锁定座位锁定座位返回选座信息返回选座信息显示选座成功点击下单请求生成订单保存订单信息返回订单信息显示订单信息返回订单信息

图 5-3 选座购票时序图

第四篇：大型网站架构设计及技术总结

大型网站架构设计及技术总结

随着中国大型IT企业信息化速度的加快，大部分应用的数据量和访问量都急剧增加，大型企业网站正面临性能和高数据访问量的压力，而且对存储、安全以及信息检索等等方面都提出了更高的要求„„

本文中，我想通过几个国外大型IT企业及网站的成功案例，从Web技术人员角度探讨如何积极地应对国内大型网站即将面临的扩展（主要是技术方面，而较少涉及管理及营销等方面）矛盾。

一、国外大型IT网站的成功之道

(一)MySpace

今天，MySpace已经成为全球众口皆碑的社区网站之王。尽管一流和营销和管理经验自然是每个IT企业取得成功的首要因素，但是本节中我们却抛弃这一点，而主要着眼于探讨在数次面临系统扩张的紧急关头MySpace是如何从技术方面采取应对策略的。

第一代架构—添置更多的Web服务器

MySpace最初的系统很小，只有两台Web服务器（分担处理用户请求的工作量）和一个数据库服务器（所有数据都存储在这一个地方）。那时使用的是Dell双CPU、4G内存的系统。在早期阶段，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。但到在2004年早期，在MySpace用户数增长到五十万后，其数据库服务器已经开始疲于奔命了。

第二代架构—增加数据库服务器

与增加Web服务器不同，增加数据库并没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下让多个数据库分担压力。

MySpace运行在三个SQL Server数据库服务器上—一个为主，所有的新数据都向它提交，然后由它复制到其它两个；另两个数据库服务器全力向用户供给数据，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。

这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace只需要投入新的数据库加以支持。在账户到达二百万后，MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（存储区域网络）—用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性。然而，当用户继续增加到三百万后，垂直分割策略也变得难以维持下去。

第三代架构—转到分布式计算架构

几经折腾，最终，MySpace将目光移到分布式计算架构——它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能的数

据都存储在相同数据库。

既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例。目前，MySpace的每台数据库服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约二百万用户。据MySpace的技术人员说，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。

第四代架构—求助于微软方案

2005年早期，账户达到九百万，MySpace开始用微软的C#编写ASP.NET程序。在收到一定成效后，MySpace开始大规模迁移到ASP.NET。

账户达到一千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。

第五代架构—增加数据缓存层并转到支持64位处理器的SQL Server 20052005年春天，MySpace账户达到一千七百万，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层——位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。

2005年中期，服务账户数达到两千六百万时，MySpace因为我们对内存的渴求而切换到了还处于beta测试的支持64位处理器的SQL Server 2005。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。

事实上，MySpace的Web服务器和数据库仍然经常发生超负荷，其用户频繁遭遇“意外错误”和“站点离线维护”等告示，他们不得不在论坛抱怨不停„„

MySpace正是在这样不断重构站点软件、数据库和存储系统中，才一步步走到今天。事实上，MySpace已经成功解决了很多系统扩展性问题，其中存在相当的经验值得我们借鉴。MySpace系统架构到目前为止保持了相对稳定，但其技术人员仍然在为SQL Server支持的同时连接数等方面继续攻坚，尽可能把事情做到最好。

(二)Amazon

亚马逊书店无疑是电子商务发展的里程碑。2000年到现在，世界网络业腥风血雨。Amazon曾经成为网络泡沫的头号代表。如今，当这个“最大的泡沫”用几经易改的数字把自己变成了坚实的IT巨人。

历览Amazon发展过程，其成功经验在于，它创造性地进行了电子商务中每一环节的探索，包括系统平台的建设，程序编写、网站设立、配送系统等等方面。用Amazon当家人贝索斯的话说就是，“在现实世界的商店最有力的武器就是地

段，地段，地段，而对于我们来说最重要的三件事就是技术，技术，技术。”

(三)eBay

eBay是世界闻名的拍卖网站，eBay公司通信部主管凯文?帕斯格拉夫认为，“eBay成功的最重要原因在于公司管理和服务。”

其成功的奥秘可以列举为以下几点：

①敢为天下先—在网络尚不普及的时代，eBay率先进入网络拍卖领域；②依托虚拟商场所产生的特有的“零库存”是eBay公司取得成功的另一个重要原因。该公司的核心业务没有任何库存风险，所有的商品都是由客户提供，它只需要负责提供虚拟的拍卖平台—网络和软件。所以，eBay公司的财务报表上不会出现“库存费用”和“保管费用”等。

③自eBay公司成立开始，它就一直遵循两条“黄金原则”：建设虚拟社区，给网民以家的感觉；保证网站稳定安全地运行。

二、国内大型网站开发时的几点建议

从本节开始，我们将结合国内外大型IT网站在技术扩展方面的沉痛教训和成功经验，探讨在如今刚刚开始的Web 2.0时代如何应对国内网站即将面临的数据访问量增加（甚至是急剧膨胀）的问题，并提出一些供参考的策略和建议。

(四)搭建科学的系统架构

构建大型的商业网站绝对不可能像构建普通的小型网站一样一蹴而就，需要从严格的软件工程管理的角度进行认真规划，有步骤有逻辑地进行开发。对于大型网站来说，所采用的技术涉及面极其广泛，从硬件到软件、编程语言、数据库、Web服务器、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。以著名的Yahoo!为例，他们的每一个大型网站工程都需要大量相应专业人员的参与。

(五)页面静态化

可不要小看纯静态化的HTML页面！其实在很多情况下，HTML往往意味着“效率最高、消耗最小”，所以我们尽可能使我们的网站上的页面采用静态页面来实现。但是，对于大量内容并且频繁更新的网站，我们无法全部手动实现，因此可以开发相应的自动化更新工具，例如我们常见的信息发布系统CMS。像我们经常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的。信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

(六)存储问题

存储也是一个大问题，一种是小文件的存储，比如图片这类；另一种是大文件的存储，比如搜索引擎的索引。

大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化以保证更

高的系统消耗和执行效率。

(七)数据库技术—集群和库表散列

对于大型网站而言，使用大型的数据库服务器是必须的事情。但是，在面对大量访问的时候，数据库的瓶颈仍然会显现出来，这时一台数据库将很快无法满足应用，于是我们需要借助于数据库集群或者库表散列技术。

在数据库集群方面，很多数据库厂商都有自己的解决方案，Oracle、Sybase、SQL Server等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案。因此，你使用了什么样的数据库，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用数据库类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，其中，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。在这一方面一个现成的例子就是搜狐。它的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

(八)缓存策略

这绝对不单指低级的缓存技术相关的编程，应从整个架构角度着眼，深入研究Web服务器、数据库服务器的各层级的缓冲策略，最后才是低级的缓冲技术的编程。不同的Web服务器、数据库服务器及Web编程语言都有自己不同的缓冲策略。例如数据库存储方面，SQL Serve 2005中的主动式缓存机制，Oracle数据的cache group技术，Hibernate的缓存包括Session的缓存和SessionFactory的缓存；Web服务器方面，Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力，IIS缓冲器技术；至于web开发语言，所用缓存技术更存在很大不同，例如ASP.NET 2.0中提出了两种缓存应用程序数据和缓存服务页输出的策略，这两种缓存技术相互独立但不相互排斥，PHP有Pear的Cache模块，等等。

(九)镜像

镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

(十)负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。

负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，基于LAMP

解决方案的Lighttped+Squid是相当不错的解决负载均衡和加速系统的有效方式。

(十一)硬件四层交换

第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。(十二)软件四层交换

大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

(十三)软件投资问题

据报导，目前国内除了一些上市企业和特别大知名大公司以外，很少有企业在成本中考虑正版软件的购置费用。这种思维极有可能给中国互联网带来噩梦。如果一些公司真正面临软件资金方面的困难，完全可以考虑使用开源世界的LAMP解决方案（Linux＋Apache＋MySQL＋Perl、PHP或者Python Web编程语言）；否则，随着我国加入WTO范围的不断扩大，盗版打击必然越来越严。因此，“苟且偷生”必将自食其果。

另外，随着网络带宽日渐提升，WEB 2.0技术必将影响到网络世界的几乎每一个角落。因此，如何积聚技术人员进行技术攻关并进一步加强安全防范也成为一个日益严峻的问题，宜尽早纳入到公司的议事日程。

四、总结

中国电子商务真正理性发展的一个标志，是大量的传统企业实实在在地开始用互联网来处理商务、做生意，而现在这样的浪潮已经开始。北京发行集团，联合SINA、6688.com等单位共同推出的网上虚拟书店—新新书店就是这样的一个标志。

随着网络带宽日渐提升，随着网络理念和WEB 2.0技术的断深入人心，各种B2B、B2C、C2C等电子商务模式很可能以立体交叉方式整合到各种大型商务网站中来。因此，作为公司的技术人员，作为临危救驾的“白衣骑士”，如何应对海量存储、海量访问问题，海量信息检索的问题，日益严峻的安全问题，等等，已经刻不容缓。

第五篇：OA办公系统的主要技术架构

和您一样，内行青睐万户OA

OA办公系统的主要技术架构

OA办公系统是一种重要的应用软件，目前各类应用软件已经倾向于组件化的设计思想，以降低各逻辑组件间的耦合性。设计思想中最为流行的、为绝大部分现有应用系统所采用的是：“MVC”（Model View Controller）设计思想。OA办公系统实现此思想时根据所采用的具体开发技术又分为三种架构：Domino架构、J2EE架构、Net架构。MVC设计思想

MVC英文即Model View Controller。即把一个应用的输入输出、处理、存储流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层——模型层、视图层、控制层。

MVC是构筑软件优秀的设计思想，将业务处理与显示分离。各层之间松耦合，日后当进行扩展或者整合的时候，可以用搭积木一样的方式来进行。Domina架构

Domino属于IBM阵营的技术，最初由Lotus公司开发。后被IBM收购而更加发扬光大，是OA领域最成熟的技术。目前基于Domino技术开发的OA办公系统，通常是将Domino作为Model。不需另行开发，再在Domino之上通过其提供的工具开发Controller和View，其中的View目前大部分是Web页面形式。这种架构其实就是在Domino精华之上加了一层壳，实质还是原来的Domino系统。J2EE架构

J2EE全称为Java 2 Enterprise Edition，后改名为：Java EE，即Java Platform Enterprise Edition。J2EE原属于SUN阵营，去年SUN为Oracle公司所收购。Java语言的流行、开源应用的蓬勃发展，使得J2EE是目前最流行的应用开发架构，也是将MVC思想实现地最彻底的新技术。J2EE提供了一系列的规范，可以与多种产品和技术无缝集成。Net架构

Net属于Microsoft阵营，在应用开发领域，是J2EE架构近年来的竞争对手。两者的设计思想很多地方相互学习，十分类似。最大的不同在于：。Net架构用Microsoft的技术实现，只能运行于Windows平台之上，而J2EE架构用Java语言实现。可以运行于任何平台之上，能和任何符合其规范的产品或技术“搭积木”。