（计算机科学与技术专业论文）三层架构主机存储系统设计.pdf

摘要 摘要 中国税收征管信息系统( v 2 o ) ，亦称综合征管软件2 0 ，是遵循“一体化 原则及国家税务总局颁布的税收征管业务规程、税收业务分类代码等 规范，采用三层体系架构形成的一个广域网环境下的、满足省级数据集中的税 收征管软件。本着这样的思路，国税系统的后续应用全部采用三层架构的省级 集中模式运行，因此，如何构建二个统一、规范、高效的业务应用平台，就成 了一个当务之急的研究课题。 本论文首先介绍了研究三层架构体系的背景和现状。着重考虑的国税系统 省级集中运行的应用系统主要包括：综合征管信息系统( 两层结构和三层结构) 、 增值税管理信息系统( 两级稽核) 、协查管理系统( 升级后的大协查) 、网络版 防伪税控系统、出口退税系统、税控收款机系统、税收执法管理系统、综合办 公系统( 0 a ) 、财务管理系统、人事管理系统等，针对省级集中应用的需求及特 点，提出了省级主机平台的规划部署原则和使用分配方案。 合理的将网络、主机、存储、数据库、w e b l o g i c 、j a v a 等多种技术融合为 一体，是本次应用实施的创新点和最大特色。本文剖析了存储系统和主机系统 的设计，规划了数据库主机环境，对整个系统的参数初步优化并进行了严格的 测试与分析，顺利完成实施了江西省国税系统的省级应用平台。本论文的重点 是：存储系统设计、主机系统设计、设备的选型搭配、设计系统的测试分析优 化等。 本文最后对目前已完成的江西国税系统主机存储系统的优点和需进一步改 进之处进行了简单的分析，并对全文做了总结和展望。 关键字：架构；主机；存储：数据库 a b s t r a c t jml1 ll _ - 一 a b s t r a c t c h i n at a xa d m i n i s t r a t i o ni n f o r m a t i o ns y s t e mv 2 o ，c t a i s2 0 ，i ns h o r t , w h i c hi sat h r e e 1 e v e lc o n s t r u c t i o ni n t e m e tt a x a t i o nc o l l e c t i o ns o f t w a r ew h i c hc a n ! m e e tt h en e e do fd a t ac e n t r a l i z a t i o no np r o v i n c i a ll e v e l i tf o l l o w st h ep r i n c i p l eo f i n c o r p o r a t i o n ，t a x a t i o n c o l l e c t i o n o p e r a t i o nr e g u l a t i o n s a n d t a x a t i o n o p e r a t i o n s o r tc o d e w h i c ha r e p u b l i s h e db y s t a t ea d m i n i s t r a t i o no f t a x a t i o n ( s a t ) ，c h i n a a c c o r d i n gt ot h a t ，a l lo fa p p l i c a t i o n so fs a ta r et h r e e l e v e l c o n s t r u c t i o na n dr u n n i n go np r o v i n c i a ll e v e l i th a sb e e na nu r g e n tr e s e a r c ht o p i c t h a th o wt ob u i l dau n i f i e d ，n o r m a t i v ea n de f f i c i e n to p e r a t i o na p p l i c a t i o np l a t f o r m i ti sd i s c u s s e df i r s t l yi nt h i sa r t i c l et h a tt h eb a c k g r o u n da n ds t a t u si nq u oo f t h r e e - l e v e lc o n s t r u c t i o ns y s t e m e s p e c i a l l yt h ei n f o r m a t i o nt e c h n o l o g ya p p l i c a t i o n s o fs 钔r ，l i k ei n t e g r a t i v et a x a t i o nc o l l e c t i o ns y s t e m ( t w o - l e v e la n dt h r e e - l e v e l ) ， v a l u ea d d e dt a x a t i o na d m i n i s t r a t i o ns y s t e m ( t w o l e v e l ) ，a u d i t i n ga d m i n i s t r a t i o n s y s t e m ( a f t e r u p g r a d e ) ，n e t w o r kv e r s i o nf w s ks y s t e m ，e x p o r t d r a w b a c k t a x a t i o n s y s t e m ，t a x a t i o n c a s h r e g i s t e rs y s t e m , e x e c u t e t a x a t i o nl a w a d m i n i s t r a t i o ns y s t e m ，i n t e g r a t i v eo as y s t e m ，f i n a n c i a la d m i n i s t r a t i o ns y s t e m a n dh u m a nr e s o u r c ea d m i n i s t r a t i o ns y s t e m s e c o n d l y ，i ti sp u tf o r w a r dt h a tt h e p r i n c i p l eo fl a y o u ta n dd e p l o y m e n ta n dt h ep r o j e c to fd i s t r i b u t i o no np r o v i n c i a l l e v e l a n dt h e n , i ti st a l k e da b o u tt h ed e s i g no fs t o r a g es y s t e ma n dc o m p u t e rs y s t e m ， m a r k i n go u td a t a b a s ec o m p u t e re n v i r o n m e n t i ti so p t i m i z e d ，t e s t e da n da n a l y z e d t h a tt h ep a r a m e t e r so fw h o l es y s t e m 1 1 1 ek e yp o 硫o ft h i sa r t i c l et h a td e s i g no f s t o r a g es y s t e m ，d e s i g no fc o m p u t e rs y s t e m ，c h o o s i n ge q u i p m e n t , t e s t i n ga n d a n a l y z i n go fd e s i g ns y s t e ma n ds oo n a tl a s t , i ti s a n a l y z e dt h a tt h ea d v a n t a g ea n dd i s a d v a n t a g eo ff i n i s h e d c o m p u t e rs t o r a g es y s t e mo fs a t ，j i a n g x ip r o v i n c i a lo f f i c e a tt h es a m et i m e ，i ti s c o n c l u d e da n de x p e c t e d k e y w o r d s ： c o n s t r u c t i o n ；c o m p u t e r ；s t o r a g e ；d a t a b a s e 学位论文版权使用授权书 本人完全了解同济大学关于收集、保存、使用学位论文的规定， 同意如下各项内容：按照学校要求提交学位论文的印刷本和电子版 本：学校有权保存学位论文的印刷本和电子版，并采用影印、缩印、 扫描、数字化或其它手段保存论文；学校有权提供目录检索以及提 供本学位论文全文或者部分的阅览服务；学校有权按有关规定向国 家有关部门或者机构送交论文的复印件和电子版；在不以赢利为目 的的前提下，学校可以适当复制论文的部分或全部内容用于学术活 动。 学位论文作者躲f 骘，睇 z 一8 年；月，；日 经指导教师同意，本学位论文属于保密，在年解密后适用 本授权书。 指导教师签名： 年月日 学位论文作者签名：砀睇 2 8 年3 月，多日 同济大学学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师指导下，进 行研究工作所取得的成果。除文中已经注明引用的内容外，本学位 论文的研究成果不包含任何他人创作的、已公开发表或者没有公开 发表的作品的内容。对本论文所涉及的研究工作做出贡献的其他个 人和集体，均已在文中以明确方式标明。本学位论文原创性声明的 法律责任由本人承担。 签名：f 2 一睥；月l ，弓日 第1 章引言 第1 章引言 1 1 课题研究背景和现状分析 随着税务系统信息化建设的不断推进深入，按照金税工程( - - 期) 建设目 标的要求，加强省级单位应用和平台的统一管理，建设一个统一的省级集中的 应用运行平台已经是当务之急。国税系统各主要应用系统将逐步演进为省级集 中模式运行，数据集中在省级统一管理。其中增值税专用发票交叉稽核系统、 协查管理系统、网络版防伪税控系统、出口退税管理系统等都将逐步升级为三 层结构，并统一提升到省级单位集中运行，综合征管信息系统( 包括两层结构 和三层结构) 也正以省级集中模式推广运行。数据库产品统一为o r a c l e 公司的 o r a c l e9 i ， w e b 及应用服务器产品统一为b e a 公司的w e b l o g i c8 1 版本。 本文重点研究综合征管信息系统的配置与部署。该系统采用集中分布式的 三层结构，包括三个层面：用户数据接口平台( 客户端) 、运行平台( 应用层面) 、 信息平台( 数据层面) 。 ( 1 ) 用户数据接口平台。用户数据接口平台是面对用户的会话层、表示层： 接收用户数据、请求，形成交易请求通过中间件事务管理器传到应用层，并接 收应用层处理后的响应，将结果进行输出或显示。 ( 2 ) 运行平台。 应用逻辑管理器：应用软件的聚合，关键应用逻辑、策略或者过程；从计 算机的角度出发，一个应用服务体现为一个守护进程；多个应用服务组成的应 用服务族构成一个完整应用系统的后台处理部分。应用逻辑管理器通过中间件 事务管理器获得客户的请求，从信息平台取出数据，进行数据的各种处理和加 工，然后在中间件事务管理器的监控下再将数据存入信息平台中，再通过中间 件事务管理器把处理结果回送客户。 ( 3 ) 信息平台。信息平台通过资源管理器完成各种资源的管理，主要是数 据库资源的管理，使用r d b m s 关系型数据库系统，r d b m s 是数据的存取和 管理工具，将采用o r a c l e 数据库。 第1 章引言 通过三层体系结构，将运用程序从整体上分为三个独立而又彼此相关联的 层次，这三层分别是：用户层、业务逻辑层、数据层。 用户层就是程序与用户的操作接口，比如说：网页。在用户层，常用到的 技术如：h t 儿、c s s 、j a v a s c r i p t 、j r v a 等。 业务逻辑层就是将一些业务处理的逻辑与规则经过封装，它提供一些接口 与用户层与数据层进行交互。在逻辑层，当今比较流行的技术和规范，如； m ic r o s o f t 的c o m d c o m c o m + n e t 组件，s u n 的e j b 等。 数据层主要是提供业务逻辑层的数据接口和后台的数据管理，比较典型的 数据库管理系统有：s q ls e r c e r2 0 0 0 2 0 0 5 、o r c a l e8 i 9 i ，d b 2 等。 三层体系结构的好处是将运用程序分成互相独立的几个层次，当某层需要 改变的时候，不会对其他层次有大的影响，便于进行运用程序的维护。同时， 层与层之间结构清晰，易于我们进行开发与部署。 三层式架构的基本考量： 1 、整体负荷的重新安排 在有限经费及资源情况下，整个应用系统的工作负荷，由三层架构下使用 者的个人电脑和应用程序服务器、数据库服务器、w e b 服务器各自负担，合力 完成整个工作，使得各自均有充裕应付之能力。 2 、分散式处理分散风险 将应用系统及数据库系统分别安装于不同之设备上，利用强大的网络功能 将各个部份加以整合成一个完整系统，由于应用系统及数据库系统不在单一设 备上，将可以使得意外伤害之风险降至最少。 3 、维持高效率的网络速率： 由于网络担负了大量的信息传递，并透过分散搭配方式及负责其各自专长 部份，使得网络仅传递必须的信息，可以维持整个网络在高可用率。 4 、周边设备连接更具弹性 通过统一管理各项资源，应用软件系统可以不需修改。 5 、亲和性高的操作方式 借助浏览器图形界面，可以很方便且简易地来操作整个应用软件，来加速 整个工作运行。浏览器的图形界面已为使用者所熟悉。 6 、应用系统扩充弹性大 第1 章引言 鉴于应用系统常随时间及情势状况而有所变动，因此应用软件应以物件导 向技术设计，将可提供相当大扩充弹性及功能修改。 7 、应用系统的可维护性 使用者个人电脑只需安装浏览器便可操作应用系统，环境单纯易于维护。 应用程序集中放置在服务器上方便管理，当应用系统出现问题时，容易界定问 题发生所在。 税务系统省级集中的各应用系统中的业务处理都属于关键业务，这就要求 从硬件和软件平台的角度，针对可靠性、可用性、容错能力、最大无故障时间 等方面提供完整科学韵系统备份方案设计，其中包括采用双机备份、数据恢复 等技术，并能够提供高可靠的解决方案用以满足业务系统高可靠的运行。在关 键系统可以通过采用集群技术构建各系统集群，不仅可以提高主机运行的可靠 性、加强数据的安全，而且可以进行双机互备、实现多工作机方式以减少单点 故障，达到负载均衡，有效提高系统的可用性。 本课题的选择和研究实现正是基于以上的背景情况，有其重要的现实应用 意义。 1 2 课题研究的内容 根据省级集中应用系统的运行特点和要求，研究如下内容： 1 、合理规划：小型机划分分区，由于小型机分区需要消耗掉一部分资源， 在能够满足应用系统相对独立运行要求的前提下尽量减少分区，或多个应用使 用一个分区； 2 、均衡负载：实时性要求强、业务负载大的应用单独使用一个或者同时使 用多个硬件分区；多个实时性要求相对不高，业务处理量小的应用部署在一台 物理小型机上，合理均衡机器负载； 3 、安全保证：业务应用和数据实现省局集中，其风险也将大大提高，在条 件许可前提下对省局集中的每个应用都建立双机热备，尽量做到每个应用系统 都有生产机和备份机，保证系统安全； 4 、物理分区技术：数据库系统必须使用按物理分区技术分割的分区，互为 热备的数据库系统必须分配在两台物理的主机上，不能安装在一台物理主机上 第1 章引言 的2 个物理分区上，如综合征管信息系统生产机与查询机必须安装在两台物理 主机的物理分区上。 5 、安全保障的技术实现。 安全包含以下三方面内容： 机密性：保证系统内的机密信息不被非法访问、窃取，防止泄密。 完整性：保证系统内信息不被非法篡改或无意修改，即维护信息的真实性、 一致性和有效性。 可用性：保证系统能够正常地提供服务，不会拒绝合法操作员的正常使用。 1 3 本文的章节安排 本文详细描述了三层架构主机存储系统的总体概述、系统设计、系统实施 以及系统测试，这个系统的优点是分层设计，资源配置合理，系统性能高效， 集群负载均衡，日常维护方便。本文共分为7 章： 第一章阐述了本课题的研究背景和现状分析、研究的主要内容。 第二章叙述了本课题研究的理论基础，包括：架构理论、框架理论以及设 计模式。 第三章对w e b 层、应用层、数据层作了简要描述，并对逻辑架构和执行架 构作了较为细致的分析。 第四章对三层架构主机存储系统进行了存储系统设计和主机系统设计，给 出了两个子系统的结构示意图和配置的计算策略。 第五章对三层架构主机存储系统进行了设备选型和规划实施，并详细给出 了主机系统和数据库系统的核心参数。 第六章对实施的系统进行了详细的系统测试。构造了测试环境和测试数据， 实施了系统调优，并对测试的结果进行了合理的分析。 第七章对全文进行了总结，并对存在的问题进行了说明，同时提出一些根 据目前实际情况的改进方法。 第2 章相关理论 2 1 架构 第2 章相关理论 软件体系结构通常被称为架构，a n s i f i e e e 6 1 0 2 1 9 9 0 软件工程标准词汇对 于体系结构定义是：“体系结构是以构件、构件之间的关系、构建与环境之间的 关系为内容的某一系统的基本组织结构以及指导上述内容设计与演化的原理 ( p r i n c i p l e ) 。 可以简单理解为：体系结构= 构件( c o m p o n e n t ) ，连接件 ( c o n n e c t o r ) ，约束( e o m m d n ) _ ，其中构建可以是一组代码，如程序的模块； 也可以是一个独立的程序，如数据库服务器。连接件可以是过程调用、管道、 远程过程调用( i 心c ) 等，用于表示构件之间的相互作用。约束一般为对象连 接时的规则，或指明构件连接的形式和条件，例如，上层构件可要求下层构件 的服务，反之不行；两对象不得递归地发送消息；什么条件下此种连接无效等。 一般而言，架构有两个要素：首先，它是一个软件系统从整体到部分的最 高层次的划分，一个软件系统中的元件首先是逻辑元件，这些逻辑元件如何放 到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活 性、性能等做出贡献，是非常重要的信息；其次，建造一个系统所作出的最高 层次的、以后难以更改的，商业的和技术的决定，也就是说进行软件设计需要 做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的 所有非功能性特征，这些决定中会有很多是一旦做出，就很难更改。 在开发一个系统之前会有很多的重要决定需要事先做出，而一旦系统开始 进行详细设计甚至开发，这些决定就很难更改甚至无法更改。显然，这样的决 定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。 引入架构就是要从更高的层面去考虑问题，把注意力集中在“不变”的因素上， 使得最终的软件系统可以实现如下目标： 可靠性( r e l i a b l e ) 软件系统对于用户的商业经营和管理来说极为重 要，因此软件系统必须非常可靠。 安全性( s e c u r e ) 软件系统所承担的交易的商业价值极高，系统的 第2 章相关理论 安全性非常重要。 可定制化( c u s t o m i z a b l e ) 同样的一套软件，可以根据客户群的不同 和市场需求的变化进行调整。 可扩展性( e x t e n s i b l e ) 软件必须能够在用户的使用率、用户的数目 增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市 场扩展的可能性；在新技术出现的时候，一个软件系统应当允许导入 新技术，从而对现有系统进行功能和性能的扩展。 可维护性( m a i n t a i n a b l e ) 软件系统地维护包括两个方面。一是排除 现有的错误；二是将新的软件需求反映到现有系统中去。一个易于维 护的系统可以有效地降低技术支持的花费。 客户体验( c u s t o m e re x p e r i e n c e ) 软件系统必须易于使用。 市场时机( t i m et om a k e r ) 软件用户要面临同业竞争，软件提供商 也要面临同业竞争。以最快的速度争夺市场先机非常重要。 2 2 框架 框架，即f r a m e w o r k 。框架是在给定问题领域范围内建立起可重用解决设 计问题互相间协作的一组类的集合( 它包括了具备缺省行为的大量对象) ，然而 框架不仅仅是行为的集合，还包括了支配着这些行为组合在一起的方法的一组 规则，或称为协议。框架包含了一组相互关联类一起工作的方法，框架在一个 给定领域范围中，解决了大量具体问题的通用的设计。框架其实就是某种应用 的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人 搭好的舞台，你来做表演。 框架一般处于底层应用平台( 如j 2 e e ) 和高层业务逻辑之间的中间层。框 架一般都是遵循好莱坞原则设计的，否则就不叫框架。所谓好莱坞原则，说的 是y o ud o n tc a l lu sw ew i l lc a l ly o u 。意思就是在一个框架下的代码，都是被动 地被框架调用，而不是相反( 如图2 1 所示) 。 第2 章相关理论 图2 1 框架调用代码图 通过这种方式，大量重复的代码就可以隐藏在框架里面，需要特别设计的 代码以预定接口的方式交给开发人员，写好后又框架调用。譬如j s p 就是一个 框架。你写的j s p 脚本会被j s p 引擎编译成s e r v l e t 的一部分。这种s e r v l e t 都带 有大量重复的代码，是j s p 程序员不需要考虑的，由框架负责。框架的主要优 点有：减少编程的代码、增加代码的可靠性和健壮性、更能保证一致性和模块 化、提供了通用领域的问题( 如用户接口、图形界面或网络操作等等) 服务。 因为软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及的知 识、内容、问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你 完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一 般是成熟的，稳健的，它可以处理系统很多细节问题，比如，事务处理，安全 性，数据流控制等问题。还有框架一般都经过很多人使用，所以结构很好，扩 展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。 2 3 设计模式 模式( p a t t e r n ) 的概念最早由建筑大师c h r i s t o p h e ra l e x a n d e r 于2 0 世纪7 0 年代提出，应用于建筑领域，8 0 年代中期由w a r dc u n r l h l g h a r n 和k e n tb e c k 将 其思想引入到软件领域。c h r i s t o p h e r a l e x a n d e r 将模式分为三个部分：首先是周 第2 章相关理论 境( c o n t e x t ，也可以称为上下文) ，指模式在何种状况下发生作用；其二是动 机( s y s t e mo f f o r c e s ) ，意指问题或预期的目标；其三是解决方案( s o l u t i o n ) ， 指平衡各动机或解决所阐述问题的一个构造或配置( c o n f i g u r a t i o n ) 。他提出， 模式是表示周境、动机、解决方案三个方面关系的一个规则，每个模式描述了 一个在某种周境下不断重复发生的问题，以及该问题解决方案的核心所在，模 式既是一个事物( t h i n g ) 又是一个过程( p r o c e s s ) ，不仅描述该事物本身，而且 提出了通过怎样的过程来产生该事物。这一定义已被软件界所接受。 在不同的层面上，模式提供不同层面的指导。根据处理问题的粒度不同， 从高到低，模式分为3 个层次：架构模式( a r c h i t e c t u r a lp a t t e r n ) 、设计模式( d e s i g n p a t t e r n ) 、实现模式( i m p l e m e n t a t i o np a t t e r n ) 。架构模式是模式中的最高层次， 描述软件系统里的基本的结构组织或纲要，通常提供一组事先定义好的子系统， 指定它们的责任，并给出把它们组织在一起的法则和指南。比如，用户和文件 系统安全策略模型，n 层结构，组建对象服务等，我们熟知的m v c 结构也属 于架构模式的层次。一个架构模式常常可以分解成很多个设计模式的联合使用。 设计模式是模式中的第二层次，用来处理程序设计中反复出现的问题。实现模 式是最低也是最具体的层次，处理具体到编程语言的问题。比如，类名，变量 名，函数名的命名规则，异常处理的规则等等。 在f r a m e 中用到了大量的设计模式，下面举例说明策略模式在f r a m e 中的 应用： 策略模式的模型如图2 2 。 图2 2策略模式模型 第2 章相关理论 f r a m e 中对抽象类a b s t r a c t c o n f i g 的五个继承类是对a b s t r a c t c o n f i g 的五种 不同实现，通过c o r t f i g m a n a g e r s e r v e r 对a b s t r a c t c o n f i g 的调用选择五种算 法的一种，是策略模式的应用，如图2 3 。 图2 3 策略模式应用 设计模式的应用对软件开发产生了重大的作用。设计模式是人们在长期的 设计软件、管理组织软件开发等实践中大量经验的提炼和抽象，是复用软件设 计方法、过程管理经验的有力工具。设计模式类似于拳击中的组合拳，它提供 了一系列软件开发中的思想套路。如，通过设计模式的使用，有利于在复杂的 系统中产生简洁、精巧的设计。设计模式为我们提供了一套简洁通用的设计、 管理、组织方面的词汇，同时设计模式也为我们提供了一个描述抽象事物的规 范标准，可大大促进软件开发过程中人与人之间的交流，而软件开发中的交流 是至关重要的，“软件项目失败的原因最终都可追溯到信息没有及时准确地传递 到它应该接受它的人”。 从以上的说明中我们知道软件的大尺度结构就是架构。一个软件不管好坏， 都会有一个架构。软件架构中可以利用框架，也可以不利用框架。譬如前面提 到j s p 是一种框架，而你的系统可以利用j s p 框架，形成自己的架构。从另一 第2 章相关理论 个角度来看，如果用房屋作比喻，架构就是忽略掉细节的抽象建筑结构，在图 纸可以看到，存在于人脑之中，不体现为房屋的某一个物理部分。框架是房屋 的骨架，房屋的骨架是物理存在的。 架构和设计模式应该是一个属于相互涵盖的过程，但是总体来说 a r c h i t e c t u r e 更加关注的是所谓的h i g h l e v e ld e s i g n ，而设计模式关注的重点在 于通过经验提取的“准则或指导方案 在设计中的应用，因此在不同层面考虑 问题的时候就形成了不同问题域上的p a t t e m 。设计模式的目标是，把共通问题 中的不变部分和变化部分分离出来。不变的部分，就构成了设计模式，因此， 设计模式是一个经验提取的“准则”，并且在一次一次的实践中得到验证，在不 同的层次有不同的模式，小到语言实现( 如s i n g l e t o n ) ，大到架构。 对于熟悉架构设计的系统架构师而言，似乎可以这样来解释架构和模式之 间的关系：架构是h i g h - l e v e ld e s i g n ，着眼于不同业务中共性的解决方案，而 模式是g e n e r a lp r i n c i p l e ( 通用原理) 。 2 4 本章小结 本章节介绍简要介绍了架构、框架、设计模式及它们之间的关系。 第3 章总体概述 3 1 逻辑架构 第3 章总体概述 根据三层体系架构的特点，将系统架构细化分为逻辑架构与执行架构。逻 辑架构如图3 1 所示： 图3 1 逻辑架构图 客户层 客户层负责提供不同渠道的展示与呈现能力，它能根据要求将统一应用层 的返回结果以不同的技术手段展现给用户。由于客户层和应用层的交换基于 x m l ，因而客户曾支持不同的实现方式，包括浏览器、电话、手机、语音等。 w e b 层 w r e b 层基于s e r v l e t 和j s p 技术开发，采用了m v c ( 视图一模型一控制器) 架 构模式。 模型：表示企业数据和管理对该数据的访问和更新的业务规则。模型 采用e j b 技术实现。 试图：，展示的内容。它通过模型访问企业数据，并制定应该如何表示 第3 章总体概述 该数据，视图将负责在它的标始终保持一致性。视图可以是j s p ，h t m l ， s w i n g g u i 等。 控制器：将和视图之间的交互转换为由模型执行的操作。在独立的g u i 客户机中，用户交互可能是按钮单击或菜单选择，然而在w e b 应用程 序中，它们则可能是g e t 和p o s th t t p 请求。由模型执行的操作包 括激活业务流程或改变模型状态。控制器根据用户交互和模型操作的 结果选择合适的视图，从而做出响应。 罨 r 麟l u e s t 熊黜荆徽 p ? 、0 “ 震 够_ - r 孑鬻器翳 丞瘸鬻 良- 苷i * 。一； l 誊。；。蠹： 图3 2 w e b 层流转图 如图3 2 所示，客户端所有的请求都发送到一个接入s e r v l e t ，接入s e r v l e t 解析请求的目的服务，然后将请求转发到后端服务处理。服务处理完毕后，根 据配置调用相应的j s p 并返回客户端。处理过程中，有关的上下文将传递到j s p 。 应用层 应用层实现所有的业务逻辑。应用层包含的基础构件有会话管理、安全控 制、服务管理，它们大多由无状态的会话e j b 实现，因此具有e j b 的良好的分 布特性：负载均衡、分布透明等。 以下简要描述这些基础构件： 服务管理器：由一个无状态的s e s s i o n b e a n 实现。它负责分发请求，根 据客户请求的目的启用相应的服务进行处理。 第3 章总体概述 会话管理器：由一个无状态的s e s s i o n b e a n 实现。当用户登录系统后， 为该用户创建会话。当用户退出系统后，销毁会话。 安全管理器：由一个无状态的s e s s i o n b e a n 实现。对登录用户进行身份 认证和权限控制。 缓存管理：由j a v ac l a s s 实现，提供数据缓存。 消息管理器：由消息b e a n 实现，封装消息借口。 日志：由j a v a c l a s s 实现，提供多级别、多媒介的日志输出。 数据层 数据层一般是流行的商用关系数据库系统，如o r a c l e 、s y b a s e 。j 2 e e 推荐使用实体b e a n 来对数据层进行数据存取。然而，实体b e a n 模型尚未成熟， 在效率及易用性方面存在明显不足。因此，f r a m e w o r k 提供数据窗口和对象关 系映射机制来完成对业务对象的持久化处理。 3 2 执行架构 图3 3执行架构图 第3 苹总体概述 由图3 3 可见，“登录管理”和“接入管理两个接入构件完成接入功能。 登录管理构件用于合法身份验证，身份验证通过后，为用户创建工作区。此后 用户的服务请求均由接入管理构件来完成。接入管理构件解析服务请求，确定 响应的服务，并请求权限检查，检查通过后由服务处理请求。 视图控制器实现对客户端的响应导航，它负责将视图返回客户端。 服务接入管理器将上下文( 用户工作区) 绑定到服务，并激活服务。而服 务完成相应的处理逻辑。所有的业务服务都隶属于统一的业务框架，业务层通 用的处理过程被抽象并在框架中实现；具体应用可以分别抽象自己的通用处理 过程，形成子框架。 业务处理过程中所需的各种服务都己封装在框架中：日志服务用于调试、 跟踪、计时以及信息输出；消息服务实现消息分发、通知功能；工作区是应用 处理过程中全局性的信息视图，在整个会话过程中有效；数据对象作为应用层 数据访问与存储的最小单元，它封装了对数据库、x m l 数据流及数据文件的存 取操作，应用相对于数据存储的逻辑独立性由数据对象服务得以保证；事务管 理封装底层具体的事务实现，屏蔽不同o r m a p p i n g 技术对事务管理的实现，提 供基本的事务控制操作；校验服务旨在抽取业务层的校验规则，统一管理有关 的校验逻辑及规则，保证应用的可维护性及配置性；缓存服务提供了缓存对象、 数据以及服务的功能。 3 3 本章小结 本章针对w e b 层、应用层、数据层作了简要描述，并对逻辑架构和执行架 构作了较为细致的分析。 第4 章总体设计 4 1 存储系统设计 4 1 1 存储结构设计 第4 章总体设计 存储备份系统建设的基本方案是采用s a n 和n a s 技术，构建独立于主机环 境及操作系统环境、为多台服务器服务的集中管理的存储系统，既可满足数据 库的基于块的读写操作，又可满足公文处理系统、电子邮件系统等所需的基于 文件的服务，同时能够保证现有的应用存储模式到新存储模式的平滑过渡。 其结构如图4 1 所示： 数据库 主机1 s a n 数据库 主机2 数据库 主机n 备份管理服 务器 l l | 邮件等 竺亭孽i | 文件系 统主机i 硫芏赢 n a s 引擎 光纤交换机1 ii 光纤交换机2 图4 1结构示意图 数据的存储备份过程是每台服务器都分别装有普通网卡和专用光纤网卡， 第4 章总体设计 分别连至局域网和s a n 上，数据库应用系统的用户可通过服务器直接访问s a n 存储备份设备，基于文件服务系统的用户可通过n a s 引擎来利用s a n 上的存储 备份设备，进行文件的读、写、修改和删除操作。在s a n 中，采用两台光纤交 换机分别连至服务器、存储备份设备、n a s 引擎，以实现冗余及负载均衡。每 台光纤交换机与存储备份设备间至少各有2 条链路，保证连接带宽不低于 4 0 0 m b p s ，与n a s 引擎及磁带库之间至少各有l 条链路，保证连接带宽不低于 2 0 0 m b p s 。 4 1 2 应用存储估算方法 考虑到省级集中运行的应用系统主要包括：综合征管信息系统( 两层结构 和三层结构) 、增值税专用发票交叉稽核系统( 两级稽核) 、协查管理系统( 升 级后的大协查) 、网络版防伪税控系统、出口退税系统、税控收款机系统、综合 办公系统( o a ) 、财务管理系统、人事管理系统等，我们首先对这些系统的数据 量进行估算，根据估算结果分配存储设备的空间。 存储的数据量估算按两种方式进行：综合征管系统等业务类系统原则上按 照税收业务量估算( 一般以纳税人数量为基础估算) ，综合办公系统的等政务管 理类系统原则上以税务人员人数或者税务机构数量估算。 按照金税三期数据量估算方法，数据量以现有数据量为基础，再考虑数据 增量，然后按照应用系统的不同应当分别考虑生产、查询的需要，必要时还要 考虑备份的需要，分别计算各类省级的各应用系统的数据量。 对可靠性要求较高，负载较大的业务系统如综合征管信息系统、稽核系统 等可以采用r a i d0 + 1 方式，充分保证数据的安全可靠，其它系统可以采用r a i d 5 - i - h o t s p a r e 方式即保证了对存储空间的充分利用，又具有一定的可靠性。 以综合征管软件为例推算所需空间： 5 0 0 g ( 江西三年的综合征管软件1 1 版数据) 1 6 ( 综合征管软件2 0 版 相对扩展) + 2 0 0 g ( o r a c l e 数据库运行所需的存储空间，如回滚段，临时表空 间，归档日志等空间) = 1 t b ，再做r a i d o + i ，空间2 = 2 t b ，再预留出同样的查 询机存储空间，做r a i d 5 为1 t b 。 综合征管系统类是对系统备份、恢复性能和可靠性要求较高的系统，数据 备份基于一级存储和二级存储相结合的方式，在一级存储上预留出2 t b 空间保 第4 章总体设计 存数据、归档日志的备份、模拟测试环境所需空间，这样一共需要给综合征管 软件分配出5 t b 空间。其它应用系统的空间估算思路基本如上。 4 1 3 应用存储数据量估算 下面的存储数据量是针对江西省国税各个应用系统数据没有结转( 所有历 史数据都导入新系统) 的情况下，在2 3 年内的需求预测。 表4 1 应用数据估算表 序号系统名称数据量( g ) 数据量( t ) 1综合征管信息系统( 两层结构 3 5 0 03 5 和三层结构) 税收 2 增值税专用发票交叉稽核系 8 2 00 8 业务统( 两级稽核) 类协查管理系统( 升级后的大协 2 0 00 2 3 查) 4网络版防伪税控系统8 2 0o 8 5出口退税系统2 0 00 2 6税控收款机系统( 木数据量待 5 l o0 5 定) 7车购税管理系统1 0 00 1 8税务审计系统1 0 0 0 1 行政 9综合办公系统( o a )1 0 2 41 0 办公 1 0财务管理系统1 0 00 1 类1 1人事管理系统 1 0 0 o 1 数据 1 2一户式 分析 1 3纳税评估 类 1 4 、 决策支持 合计 7 4 0 07 4 4 1 4 备份策略 主要采用本地数据集中备份的方式，可适当增加异地数据存储备份功能。 第4 章总体设计 备份系统的磁带库通过光纤交换机与s a n 中的服务器和磁盘阵列相连接， 通过两台光纤交换机实现冗余备份和负载均衡，每台光纤交换机与磁带库之间 至少各有1 条链路，保证连接带宽至少为2 0 0 1 p s 。备份系统通过备份服务器 设置备份策略，系统定时进行全备份、增量备份或差分备份。为了提高系统的 可靠性和数据的安全性，对操作系统、应用系统和数据库三方面内容进行备份。 备份管理软件应配置专用备份管理服务器。 4 1 4 1 备份原则 对于数据保护系统的设计来说，备份策略的考虑通常是至关重要的。备份 策略的制定要基于以下原则： ( 1 ) 简化备份、恢复等操作，提高备份系统的可靠性。 ( 2 ) 减少备份、恢复等数据管理操作对资源的占用，包括c p u 资源，网络 带宽占用，存储介质的用量等。 ( 3 ) 减少备份系统的总体拥有成本。 ( 4 ) 充分利用二级存储( 带库) ，实现备份数据的异地存储，保证数据的安 全可靠。 ( 5 ) 对于操作系统和应用程序代码，可在每次系统更新或安装新软件时做 _ 次全备份。 ( 6 ) 对于一些日常数据更新量大，但总体数据量不是特别大的关键应用数 据，可每天在用户使用量较小的时候安排全备份。 ( 3 ) 对于日常更新量相对于总体数据量较小，而总体数据量非常大的关键 应用数据，可每隔一个月或一周安排一次全备份，在此基础上，每隔一个较短 的时间间隔做增量备份。 4 1 4 2 备份考虑的问题 在考虑备份策略的设置时，通常会考虑以下一些问题： 分类需要进行数据保护的数据的重要级别； 应用系统的运行特点； 第4 章总体设计 ( 3 ) 评估备份数据量的大小； ( 4 ) 设定备份周期的大小，设定备份频率； ( 5 ) 备份操作的流程： ( 6 ) 恢复的流程。 4 1 4 3 三类应用系统备份方案 基于以上策略，同时根据省级集中各系统的需求特点，我们可以把省级集 中系统分为三类：分别是税收业务类、行政办公类和数据利用类。下面针对上 述三类系统分别论述其备份方案： 4 1 4 4 税收业务类 主要包括综合征管信息系统( 两层结构和三层结构) 、增值税专用发票交叉 稽核系统( 两级稽核) 、协查管理系统( 升级后的大协查) 、网络版防伪税控系 统、出口退税系统、税控收款机系统等。该类系统的特点是数据量较大、业务 处理负载较重、对系统性能和可靠性要求高，业务实时性较强，一般不能停机， 针对以上业务系统特点我们建议可以采用以下备份方案： 在每次系统更新或安装新软件时对操作系统和应用备份做一次全备份； 对于一些日常数据更新量大，但总体数据量不是特别大的关键应用数据， 如协查管理系统( 升级后的大协查) 、网络版防伪税控系统、出口退税系统、税 控收款机系统，可每天在用户使用量较小的时候安排全备份； 对于日常更新量相对于总体数据量较小，而总体数据量非常大的关键应用 数据，如综合征管信息系统( 两层结构和三层结构) 、增值税专用发票交叉稽核 系统( 两级稽核) ，可每个月或一周安排一次全备份，在此基础上，每隔一天的 时间间隔做增量备份。 以上系统一般都采用联机备份，在系统允许的情况下可以考虑一月或半年 采用脱机备份。 该方案通过备份增量数据可以减少备份时间( 恢复时间加长) ，采用联机备 份能满足上述系统不问断运行的需要( 备份的实施不可避免的都会对系统性能 第4 章总体设计 产生影响，只能制定策略尽量减少影响) 。 4 1 4 5 行政办公类 主要包括综合办公系统( o a ) 、财务管理系统、人事管理系统等，该类系统 的特点是数据量较小、业务处理负载不高、对系统性能和可靠性要求相对较高， 业务处理时间主要集中在工作时间。针对以上业务系统特点我们建议可以采用 以下备份方案： ( 1 ) 在每次系统更新或安装新软件时对操作系统和应用备份做一次全备 份； ( 2 ) 对于一些日常数据更新量较大，但总体数据量不是特别大的数据，如 综合办公系统( o a ) ，财务软件，可每天在用户使用量较小的时候安排全备份； ( 3 ) 对于数据相对稳定，业务较少的应用，如人事，可每隔一个月或一周 安排一次全备份。 (