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

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

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

随着中国大型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等电子商务模式很可能以立体交叉方式整合到各种大型商务网站中来。因此，作为公司的技术人员，作为临危救驾的“白衣骑士”，如何应对海量存储、海量访问问题，海量信息检索的问题，日益严峻的安全问题，等等，已经刻不容缓。

第二篇：PHP技术：大型网站架构不得不考虑的10个问题

PHP技术：大型网站架构不得不考虑的10个问题

这里的大型网站架构只包括高互动性高交互性的数据型大型网站，基于大家众所周知的原因，我们就不谈新闻类 和一些依靠HTML静态化就可以实现的架构了，我们以高负载高数据交换高数据流动性的网站为例，比如海内，开心网等类似的web2.0系列架构。我们这里 不讨论是PHP还是JSP或者.NET环境，我们从架构的方面去看问题，实现语言方面并不是问题，语言的优势在于实现而不是好坏，不论你选择任何语言，架 构都是必须要面对的。

这里讨论一下大型网站需要注意和考虑的问题

1、海量数据的处理

众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加 几个索引就可以搞定。对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是 几何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。

2、数据并发的处理

在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然 而在我们进行修改的时候就，如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及 缓存策略。

另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。

3、文件存贮的问题

对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是 对文件按照日期和类型进行存贮。但是当文件量是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是 一个巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。如果这个时候还涉及上传，磁盘很容易就over了。

也许用raid和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度 如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。

所以我们不得不承认，文件存贮是个很不容易的问题

4、数据关系的处理

我们可以很容易的规划出一个符合第三范式的数据库，里面布满了多对多关系，还能用GUID来替换INDENTIFY COLUMN 但是，多对多关系充斥的2.0时代，第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。

5、数据索引的问题

众所周知，索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是，在高UPDATE的情况下，update和delete付出的成本 会高的无法想想，笔者遇到过一个情况，在更新一个聚焦索引的时候需要10分钟来完成，那么对于站点来说，这些基本上是不可忍受的。

索引和更新是一对天生的冤家，问题A，D，E这些是我们在做架构的时候不得不考虑的问题，并且也可能是花费时间最多的问题。

6、分布式处理

对于2.0网站由于其高互动性，CDN实现的效果基本上为0，内容是实时更新的，我们常规的处理。为了保证各地的访问速度，我们就需要面对一个 绝大的问题，就是如何有效的实现数据同步和更新，实现各地服务器的实时通讯有是一个不得不需要考虑的问题。

7、Ajax的利弊分析

成也AJAX，败也AJAX，AJAX成为了主流趋势，突然发现基于XMLHTTP的post和get是如此的容易。客户端get或者post 到服务器数据，服务器接到数据请求之后返回来，这是一个很正常的AJAX请求。但是在AJAX处理的时候，如果我们使用一个抓包工具的话，对数据返回和处 理是一目了然。对于一些计算量大的AJAX请求的话，我们可以构造一个发包机，很容易就可以把一个webserver干掉。

8、数据安全性的分析

对于HTTP协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G问题来说的话，加密的过程就可能是明文了(比如我们 知道的QQ，可以很容易的判断他的加密，并有效的写一个跟他一样的加密和解密方法出来的)。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来 之后，那么所谓的外挂，所谓的群发就会接踵而来(从qq一开始的群发可见端倪)。也许我们可以很的意的说，我们可以采用更高级别的判断甚至HTTPS来实 现，注意，当你做这些处理的时候付出的将是海量的database，io以及CPU的成本。对于一些群发，基本上是不可能的。笔者已经可以实现对于百度空 间和qq空间的群发了。大家愿意试试，实际上并不是很难。

9、数据同步和集群的处理的问题

当我们的一台databaseserver不堪重负的时候，这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问 题了，数据基于网络传输根据数据库的设计的不同，数据延迟是很可怕的问题，也是不可避免的问题，这样的话，我们就需要通过另外的手段来保证在这延迟的几秒 或者更长的几分钟时间内，实现有效的交互。比如数据散列，分割，内容处理等等问题。

10、数据共享的渠道以及OPENAPI趋势

Openapi已经成为一个不可避免的趋势，从google，facebook，myspace到海内校内，都在考虑这个问题，它可以更有效的 留住用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的途径了，而在开放的 接口的情况保证数据的安全性和性能，又是一个我们必须要认真思考的问题了。

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

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 网络扩容

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

第四篇：java技术架构

Java技术体系图

Java程序员

高级特性

反射、泛型、注释符、自动装箱和拆箱、枚举类、可变

参数、可变返回类型、增强循环、静态导入

核心编程

IO、多线程、实体类、集合类、正则表达式、XML和属性文件

图形编程

AWT（Java2D/JavaSound/JMF）、Swing、SWT、JFace

网路编程

Applet、Socket/TCP/UDP、NIO、RMI、CORBA

Java语法基础

类、抽象类、接口、最终类、静态类、匿名类、内部类、异常类、编码规范

Java开发环境

JDK、JVM、Eclipse、Linux

Java核心编程技术

Java，设计而又非常精巧的语言。学习Java，须从Java开发环境开始，到Java语法，再到Java的核心API。

1.Java开发入门：Java开发环境的安装与使用，包括JDK命令、EclipseIDE、Linux下Java程序的开发和部署等。

2.Java语法基础：基于JDK和Eclipse环境，进行Java核心功能开发，掌握Java面向对象的语法构成，包括类、抽象类、接口、最终类、静态类、匿名类、内部类、异常的编写。

3.Java核心API：基于JDK提供的类库，掌握三大核心功能：

A。Java核心编程:包括Java编程的两大核心功能——Java输入/输出流和多线程，以及常用的辅助类库——实体类、集合类、正则表达式、XML和属性文件。

B。Java图形编程：包括Sun的GUI库AWT（Java2D、JavaSound、JMF）和Swing，IBM和GUI库SWT和Jface;

C.Java网路编程：Applet组件编程，Socket编程，NIO非阻塞Socket编程、RMI和CORBA分布式开发。

4.Java高级特性：掌握JDK1.4、JDK5.0、JDK6.0中的Java高级特性，包括反射、泛型、注释，以及java高级特性——自动装箱和拆箱、枚举类、可变参数、可变返回类型、增强循环、静态导入等。

JavaEE初级软件工程师

JSF框架开发技术

配置文件（页面导航、后台Bean）、JSF组件库（JSF EL语言、HTML标签、事件处理、）、JSF核心库（格式转换、输入验证、国际化）

Javaweb核心开发技术

开发环境（Eclipse、Linux）

三大组件（JSP、JavaBean、Servlet）

扩展技术（EL、JSTL、Taglib）

网页开发技术

HTML、XML、CSS、JavaScript、AJAX

数据库设计技术

SQL、MySql、Oracle、SQLServer、JDBC

Web服务器（Tomcat/Jetty/Resin/JBossWeb）

JavaWeb核心技术：

JavaWeb项目开发的全过程可以分解为：

网页开发+数据库设计——>JavaWeb项目开发，其中，javaWeb由6项基本技术组成：JSP+JavaBean+Servlet+EL+JSTL+Taglib，而JSF正是将这6种技术进行有机结合的技术框架：

JavaEE中级软件工程师

四种经典架构SSH1、SSI1、SSH2、SSI2

Struts1表现层框架

入门配置、核心组件、标签库、国际化、数据检验、数据库开发、Sitemesh集成、集成Hibernate/iBATIS

Struts2表现层框架

入门配置、核心组件、标签库、国际化、数据校验、Sitemesh集成转换器、拦截器、集成Hibernate/iBATIS

Spring业务层框架

入门配置、IoC容器、MVC、标签库、国际化、数据校验、数据库开发

Hibernate持久层框架

MySQL、Oracle、SQLServer iBATIS持久层框架

MySQL、Oracle、SQLServer

Web服务器（Tomcat/Jetty/Resin/JBossWeb）

Java高级软件工程师

javaWeb开源技术与框架

工作流、规则引擎

搜索引擎、缓存引擎、任务调度、身份认证

报表服务、系统测试、集群、负载平衡、故障转移

JavaWeb分布式开发技术

JTA（Java事物管理）

JAAS（Java验证和授权服务）

JNDI（Java命名和目录服务）

JavaMail（Java邮件服务）

JMS（java信息服务）

WebService(web服务)

JCA（java连接体系）

JMS（java管理体系）

应用服务器（JBossAS/WebLogic/WebSphere）

JavaEE系统架构师

面向云架构（COA）

COA、SaaS、网格计算、集群计算、分布式计算、云计算

面向资源架构（ROA）

ROA、RESI

面向web服务架构（SOA）

WebService、SOA、SCA、ESB、OSGI、EAI

Java设计模式

创建式模式：抽象工厂/建造者/工厂方法/原型/单例

构造型模式：适配器/桥接/组合/装饰/外观/享元/代理

行为型模式：责任链/命令/解释器/迭代子/中介者/备忘录/观察者/状态/策略/模板方法/访问者

Java与UML建模

对象图、用例图、组件图、部署图、序列图、交互图、活动图、正向工程与逆向工程

CTO首席技术官

发展战略

技术总监

团队提升

团队建设

项目管理

产品管理

第五篇：基于java技术的软件开发架构总结

基于java技术的软件开发架构总结

在具体的实现中，表现层可为Struts/JSF等，业务层、访问层可为JavaBean或EJB等，资源层一般为数据库。

宏观上的层次就是这样，在具体现实中，有如下几种实现形式：

1，轻量级实现

表现层使用基于MVC的框架，比如Struts或JSF 业务层使用JavaBean（就是常说的Service）访问层使用JavaBean（就是常说的DAO）优点：

轻量级实现，简单明了 缺点：

难以无法实现分布式应用

以下功能必须通过编程实现

事务控制 资源管理（包括组件的创建）

线程安全问题

安全性

2，重量级J2EE实现

表现层依然是基于MVC的框架

访问层采用实体Bean实现，如果可能最好采用CMP，实现起来更简洁。此处的实体Bean可以考虑采用本地接口

业务层一分为二，服务控制器可以由会话Bean充当，用来封装业务流程（相当于轻量级实现中的Service），也可以考虑采用本地接口；门面也可以由会话Bean充当（一般来说无状态会话Bean足矣），作为业务层的入口，应该采用远程接口。优点：

以下功能可由EJB容器自动实现，或通过配置实现

事务控制

远程访问

线程安全

资源管理

安全性

可以进行分布式应用

因为采用了EJB，故部分特征可以由装配人员来配置（比如事务，安全性等），不需要在软件中硬编码 EJB组件有更好的重用性

可利用容器提供的其他企业级的功能（比如集群，容错，灾难恢复等）

可以加入MDB（实现异步通讯）等技术 缺点：

开发难度较高

如果不恰当的使用实体Bean，会造成效率低下。如果采用CMP，则很多数据访问的操作不能直接实现。

缺少良好的开发环境

软件可能依赖于具体的EJB容器 EJB容器可能很贵，开发软件也可能很贵

3，轻量级和重量级J2EE的切换

如果项目有需求，并有充分的时间，还可以通过在表现层和业务层的交界处加入“业务代表”（JavaBean + 服务定位器实现）来对表现层隐藏对业务层访问的细节(JavaBean和EJB的访问方式显然不同)，只需替换“业务代表”就可以切换轻量级和重量级两种实现。举例说明，一般电话上都有一个P/T开关（脉冲/音频开关），随着开关状态的不同，拨号时电话机会判断是使用脉冲拨号还是音频拨号。

这种架构唯一的缺点就是必须写两套实现代码„„

4，轻量级J2EE实现

访问层通过JavaBean调用ORM框架实现（Hibernate，iBatis等），代码简洁，功能完备（相对于EJB 2.x而言），如果用的是Hibernate，可以忽略底层数据库的差异，如果用的是iBatis，则方便对SQL进行优化。

业务层和访问层依靠AOP框架（如Spring）可以在切面中实现事务，安全性等功能，同时不影响业务代码。如果采用Spring，其中已经内置了事物切面，并可以轻易的与主流ORM框架进行整合，实现声明式的事物管理。当然，更可以使用IoC模式降低组件间的耦合性。优点：

可以通过AOP框架实现事物、安全性等功能，同时不影响业务代码

ORM框架比CMP更灵活，比BMP更简洁（相对于EJB 2.x而言），运行效率也比较高

如果使用Spring，可以用更简单的方式实现J2EE中比较复杂的功能

无需额外的容器

ORM和AOP框架可以找到免费的开源实现，降低项目成本（不过也有人认为采用开源项目可能综合成本更高） 缺点：

非官方框架，缺少文档、技术支持和业界经验

采用技术太多，学习曲线较高，难以招到合适的程序员（咱们学员可以考虑在这方面下点功夫，呵呵）

某些企业级的功能轻量级框架还不能实现（或独立实现）

测试、调试均比较复杂

另类之处：

使用BMP + Hibernate（具体做法为BMP中的持久化方法，比如ejbLoad, ejbStore等都委托给Hibernate实现）优点：

借助于Hibernate强大的ORM功能弥补CMP的不足（特别是EJB-QL）缺点：

事物不好控制

不伦不类，容易发生未知的错误（比如Hibernate自身的缓存可能会于容易提供的缓存冲突）另类之处：

将业务层（也可能包含访问层）包装成Web Services，支持远程调用 优点：

借助于Web Services可以实现松散耦合分布式应用，说的大一点，就是传说中的SOA，呵呵 缺点：

Web Services自身效率不高，无状态，安全性差

当然，即使不分层，也能做出软件来，但我们应该思考怎么做才能最好？如果说分层不好，那么不分层的优势又在哪里呢？？如果说分层有性能的损耗，那么性能损耗在哪里呢？？如果不分层，软件工程思想中的“分而治之”的原则启不受到了质疑？

有人说，分层是为了减少代码量，如果分层是为了减少代码量，那怎么能减少，代码的重用也许会减少一些，但是程序更多的是业务，我们关心的也只是业务，试问分层的意义就是为了减少代码量？

总之我的观点就是：软件分层是必须做的。至于框架，不应该问用不用，而应该问用什么？要选用实践检验过的框架，毕竟实践是检验真理的唯一标准。

二年的J2EE开发之后，我们应该掌握了一些主流的架构模式，总结一下：

宏观上讲，我们采用了分层的架构，将软件分为如下的层次：