软件系统架构设计讨论

majin_com 2005-11-07 07:04:55
技术架构说明书
1 前言
一个企业级的商业软件能够满足用户需要、正常运行、易于维护、易于扩展,必须拥有一个良好的软件架构支撑。本文主要是分析和构建一个企业级商业软件架构。

2 架构分析
企业级的商业软件架构在技术层面的要求主要体系在高性能、健壮性和低成本。

 高性能
对于企业级商业软件来说,软件架构需要尽可能地使软件具有最高的性能,支持最大的并发性。
对于企业级应用,传统的最高性能的软件架构是Sun较早提出的J2EE架构方案。他通过可缩放性――一个应用在给定相应硬件的条件下支持增加的负载的潜力。简单的说,利用J2EE的分布式特性,使软件可以通过添加服务器等硬件设备来提高性能,增加负载能力。
J2EE为实现分布式体系结构提供了出色的支持。同一个分布式J2EE应用的构件可以被分布给运行在一台或多台物理服务器上的多个JVM。分布式J2EE应用以使用具有远程接口的EJB作为基础,而远程接口能够让应用服务器隐藏掉分布式构建的访问和管理的大部分复杂性。
不过尽管J2EE很大的降低了分布式应用的复杂性,但是分布式应用还是很复杂,如果通过分布式来为软件提供可缩放性,代价还是很大的。
我们现在的企业级商业软件迫切需要分布式吗?我们需要怎样的分布式?
现在企业级商业软件的性能主要在由Web容器服务器、逻辑处理服务器和数据库服务器来决定。J2EE实现的分布式体系结构主要是针对逻辑处理服务器。
下面我们分析一下逻辑处理服务器的分布式方案。逻辑处理器采用分布式的话,那么服务器的CPU颗数需要大概70颗以上。因为如果需要大概64颗CPU服务器的话,采用一台多CPU服务器就可以解决。而70颗CPU的逻辑处理服务器的硬件成本已经到了远远超出了目前商业需求所能承担的硬件成本,而且这还不包括想匹配的Web容器服务器和数据库服务器成本。所以如果需要使软件具有可缩放性,通过硬件解决方案(多CPU服务器)比软件解决(分布式系统)要有效得多。
所以就目前的商业需求和硬件环境,架构通过缩放性使得软件获得高性能,缩放性主要通过改善硬件配置来解决。


 健壮性
企业级的商业软件要求软件是可靠的和无缺陷的。现在的架构一般是,服务器模式的。软件的可靠和健壮主要依赖与服务器。服务器的稳定通过良好的代码和完备的测试能够解决这个问题。
由于客户需要,现在需要在客户端也具有一定的健壮性。当服务器由于意外出现故障的时候,客户端也能够继续运行,在客户端发生的数据先保存在服务器,待服务器恢复完备后,再把数据上传到服务器。
对于这点要求,Sun提出的J2EE架构已经事先考虑过,Sun认为软件不仅能够响应浏览器的请求,还能够响应应用服务器的请求,比如Swing编写的应用程序,VB编写的应用程序等。
所以对于健壮性要求而言,一是通过加强代码质量,二是在软件架构上采用兼容应用程序客户端的方案。


 低成本
企业级商业软件还有一个很重要的要求:低成本。软件架构要求简单、易掌握,复杂度低,易于维护和扩展,易于测试。
低成本、高效率的研发架构传统思路是采用分层的思路、OO设计原理、强调重用来。
采用分层的思路是通过把复杂的业务分块来实现降低难度,同时通过业务分拆来达到重用的目的。
采用OO设计原理能够使复杂的系统变得简单化、条理化,使开发、维护变得简单。
通过重用,可以减少开发量,减少出错的概率,易于开发和维护。

一般来说,传统的分层思路是把系统分为界面展示层,控制层,逻辑处理层,数据访问层和数据存储层。OO的设计原理主要是为了降低逻辑处理层的复杂度。
分层是为了把复杂度分解,不过多层次本身也带来了一些额外的复杂性。因此本架构设计分为三层:界面展示层、控制层和数据存储层。取消逻辑处理层和数据访问层。这样做的目的是通过降低系统架构层次来降低开发工作量。整个数据架构以XML为核心,通过XML连接所有的组件层,通过XML进行通讯。把逻辑处理放到数据存储层,通过数据库的处理能力来解决商业逻辑,这样做即可以减少开发量,也可以取消逻辑处理层,同时也可以使用OO设计进行业务处理。由于采用XML为数据为接口,所以数据访问层全部可以采用统一的模式,因此可以取消此数据访问层。


3 架构定义
本架构以XML为整个系统的交互接口,包括系统架构内部和外部。整个系统分为界面展示层,流程控制层和数据存储层。系统由架构支撑组件类、独立客户端组件类、AJAX组件类、流程控制组件类、数据存储组件类、消息组件类、邮件组件类、移动组件类、GIS组件类。
架构的核心优势是以AJAX实现最强大的浏览器客户端,以智能客户端实现独立客户端体现最强大的系统健壮性,摒弃O/R Mapping使研发效率得到大幅度提高。

...全文
1646 12 打赏 收藏 转发到动态 举报
写回复
用AI写文章
12 条回复
切换为时间正序
请发表友善的回复…
发表回复
wind_rain 2005-12-21
  • 打赏
  • 举报
回复
基本还可以
litengda 2005-12-21
  • 打赏
  • 举报
回复
这种系统能设计成功!并开发出来的人!可以去IBM应聘架构师了
asiaec 2005-12-16
  • 打赏
  • 举报
回复
非常赞对ejb的评论!
weiyidress 2005-12-01
  • 打赏
  • 举报
回复
开发工具JavaFast
简介
什么是JavaFast
JavaFast是一个自动化的代码生成器。它让开发人员快速的开发出数据库操作程序。只需按数据库结构无需任何编码,自动生成原代码, 那些代码是可以运行通过的,不需要任何调试 ,这样就保证的调试速度, 然后你只需要在生成的代码基础上作些界面调整,来满足你的业务需求就可以了 ,这样JavaFast可以提高开发效率数5倍以上。

优点
1>提高开发速度 。
2>自动生成大部分代码,只需要作相应简单的调整就可以满足自己的业务逻辑。
3>给所有员工统一了开发规范,统一编码风格。
4>本软件目前有3个版本类型,第一个版本是纯jsp,第二个版本是jsp+javaBean,第三个版本是jstl+Spring+ibatis。
5>降低了开发成本,一个人可以相当于4个人的开发速度。
6>降低了开发风险,生成的代码规范、格式和样式都一致,以后维护程序的工作量也很小,并且不同人之间的工作可以很方便相互移交,只要知道模块业务逻辑就可以交叉修改代码
定制开发工具
如果公司有自己的一套开发框架和模式,那我也可以为你们开发一套适合自己的开发工具,可以提高四倍开发速度,在开发过程中让所有员工自觉地遵守规范和标准是很困难的,所以他有助于让员工不自觉的统一了开发规范,统一编码风格

wuhanchenjing@hotmail.com或者电话027-63176530QQ号码54624010联系
bruce_wang 2005-11-25
  • 打赏
  • 举报
回复
好乱
cm22479166 2005-11-25
  • 打赏
  • 举报
回复
恩,虽然写了很多,但看的很累.你重新组织一下再讨论吧.而且废话太多,不实用.
nighthawk 2005-11-24
  • 打赏
  • 举报
回复
用你自己的语言重新组织一下,500字以内。估计这样就可以讨论讨论
kingofhawks 2005-11-09
  • 打赏
  • 举报
回复
看了一点没能看得下去,废话感觉太多了些...
www203 2005-11-08
  • 打赏
  • 举报
回复
加油
majin_com 2005-11-08
  • 打赏
  • 举报
回复
想和大家讨论这个技术方案是否妥当,各位高手是否有其他见解
dssaaa 2005-11-07
  • 打赏
  • 举报
回复
要讨论什么呢?
majin_com 2005-11-07
  • 打赏
  • 举报
回复

4 架构说明
4.1 架构层次图






















4.2 架构组成图




4.3 组件说明
4.3.1 智能客户端组件类
对于现在B/S软件来说,用户体验的要求是致命的。由于浏览器的原因,很难达到应用程序易用性的程度。同时,由于本身的原因,瘦客户依赖于服务器。但是,具体客户实际,需要软件有较强的健壮性,当服务器发生故障的时候,客户端依然能够运行。现在主要的厂商已经在这方面做了大量的工作,Sun主推的是Web Start,微软主推的是Smart Client,比较而言,Smart Client比较成熟、有效。系统集成Rich Client能够极大的扩展系统的能力,满足用户的需求。

智能客户端有较高的复用性




智能客户端的优点





智能客户端的商业价值



智能客户端的优势
 充分利用终端设备的优势
 能够调用Web Services
 支持在线和离线两种状态
 能够如同Web应用程序一般简单方便的部署

4.3.2 AJAX组件类
AJAX 英文Asynchronous JavaScript+XML 的缩写, 中文的意思则为“在Web上通过JavaScript, 使用异步的XML Http请求, 实现无刷新的Web界面”。

现在已经有很多成熟产品在使用此技术,比如Google的Gmail、Google Map、Google Suggestion等。



AJAX有以下内容组成
 基于标准化的XHTML和CSS
 通过DOM实现动态显示和交互
 通过XML和XSLT来进行数据交换方式获取数据
 使用JavaScript来整合以上所有的技术



AJAX设计原理
 一个可扩展的核心框架,其中为JavaScript添加很多新特性,如生存期管理、继承、多批事件处理器和接口。
 一个基础类库,提供了通用特性,如丰富的字符串操作功能,计时器和运行任务等。
 一个UI框架,可以跨浏览器实现HTML的动态行为。
 一个网络栈,用于简化对服务器的连接和对Web Services的访问。
 一个具有丰富UI功能的控件,如自动完成文本框、弹出面板、动画控件和拖放。
 一个浏览器兼容的层,用于不同的浏览器中定位不同的脚本行为。



AJAX组件图


组件说明:
(略)







4.3.3 系统支撑组件类
4.3.3.1 MVC
提供标准的MVC框架结构,良好的分层设计使系统易于开发和维护。
4.3.3.2 IoC
IoC指控制反转,通过XML文件的配置使组件不需要在运行时寻找其协作者。Spring的核心就是IoC,Struts也采用了类似的方式。本架构也是以IoC为核心,通过配置来管理类和类的调用。




4.3.3.3 AOP
AOP主要是解决系统横切关注点的问题,主要是系统级服务,如:日志、事务、安全性等。他主要由五种装备构成:
 Before装备
 Throws装备
 After装备
 Around装备
 Introduction装备
4.3.3.4 MQ
由于信息系统的数据交换具有数据量大,持续时间长,不要求同步等特点。因此在数据交换上采用消息队列能够很好的解决这个问题。

4.3.3.5 DAO
提供JDBC的抽象层,使得开发者不用再去编写同RDBMS交互、非业务功能的JDBC代码。统一处理SQL异常,统一事务控制。


4.3.3.6 Mail、移动设备、GIS等
根据具体的应用需求,还有一些特殊的扩展组件。(略)

4.4 数据库
数据库的性能占系统性能的70%~80%, 如果采用O/R Mapping, 则会影响数据库方面的性能发挥,同时如果对于分布式数据库的要求,则需要EJB来完成。如果不采用O/R Mapping的要求,则可以充分发挥数据库本事的特性,实现高效存取数据,实现分布式数据库,实现企业数据整合。









4.5 XML协议组
现在商业软件的发展核心在于建立完善的协议组,例如HL7。本系统架构的核心也是也XML协议组为核心设计的。从客户端,到服务器,到数据,XML协议组贯穿整个流程。





5 综合分析
5.1 架构流程分析
通过AJAX、 智能客户端, 实现强大的客户体验,完全摒弃以往的刷新页面的方法。 客户端将数据收集后,经过整理以XML的形式,按照统一XML协议格式提交到服务器,服务器通过相应的处理、分配和运算到数据库。数据库也以XML的形式接收,处理完成后,也以XML的形式,按照统一XML协议格式返回到服务器,到客户端。

整个架构以XML协议组为核心,通过统一的协议规定指导应用研发,整个研发的主要成本在需求分析、系统设计、编码开发和后期维护。

系统架构主要和编码开发与后期维护成本相关,本系统架构的开发以XML为核心,主要的工作在于客户端组装XML,数据库处理XML,其他的系统组件层基本上不需要开发,这样开发人员的培训主要集中与客户端技术和数据库处理的掌握,从而通过降低开发人员的级别要求和精简代码使得编码开发的成本降低到了最低。后期维护的成本与编码量和代码负责度成正比,由于代码量比较少,而且以XML协议组为基本核心,所以代码的负责度也比较低,所以整体的维护成本也很少。

由于架构采用了智能客户端技术,可以实现独立客户端的模式。如果服务器发生故障,客户端不受影响,能够继续工作,工作的数据保存在客户端,等到服务器恢复工作后,再把数据上传到服务器。



5.2 可行性分析
5.2.1 技术层面
 XML协议组
此协议组是整个系统框架的核心,他的优劣是决定系统框架的稳定度和扩展性。
此协议组的核心生命周期大概为两年。两年后,应重新投入资源,制定此协议组的第二版。

 AJAX组件类
现有组件基本能满足业务需求,但都存在两大问题:一是稳定性不够,占用资源大;二是用户体验特性有待提高。
完成此组件类的任务,需要协调、安排资源,各个产品线整理自有组件,一起协商重新制定新的组件接口并实现,在新的项目和产品中使用。

 支撑组件类
此组件类主要为新项目和新产品使用。需要投入资源来研发。

 智能客户端组件类
此组件类主要为新项目和新产品使用。需要投入新资源来完成。


5.2.2 管理层面
此架构在管理层面的风险主要在与架构的推广。架构推广的难度,一个是在于文档和培训,一个是在于核心思想的推广。

 文档和培训
由于技术的复杂性,这一块以往做得很不够。但是对于技术框架的公司层面的推广,需要克服这个难题。通过借鉴公司实施部门的经验,加强相关人员的责任心,管理力度,以及加强技术人员的配合力度来解决这个风险。
 核心思想的推广
本系统架构的核心思想有三,其中关于摒弃O/R Mapping、绑定固定数据库以提高开发效率的思想,还未得到充分认可,待需要大家一起讨论。



6 FAQ
6.1 为什么不用EJB
EJB本身是Sun公司的一个美丽谎言,对于我们目前的商业应用来说,他给我们带来了巨大的复杂度,但并没给研发带来什么好处。现在北京市公共卫生的项目的EJB主要使用的是Session Bean,这和很多使用EJB的项目一样,根本上是浪费研发成本而已。
EJB的分布式,公司的商业上用不到;缓存可以用其他很简单的方式来实现,所以EJB就是鸡肋,本系统架构摒弃。

6.2 为什么不用O/R Mapping
这个话题的争议性比较大。
O/R Mapping的产生是由于OO设计的要求,但是由于本系统以XML协议组为核心,通过XML进行各层之间的通讯,而不是通过对象,同时OO设计也可以应用XML的通讯机制,所以本系统架构放弃O/R Mapping以提高研发效率。

6.3 为什么不考虑主逻辑服务器
这个话题的争议性比较多。
主逻辑服务器主要负责商业逻辑运算。我们通过医院体系的研发经验分析,现有的信息系统的商业逻辑负责度利用SQL的能力就能够处理。由于通过数据库的逻辑处理解决商业逻辑运算,一是可以减少逻辑服务器和数据库服务器之间的数据交互,提高系统性能,二是数据库服务器的运算能力也比Java的逻辑服务器运算能力高得多,因此本架构放弃主逻辑服务器。







6.4 为什么绑定数据库
对不同数据库的支持属于商业方面的选择。系统的性能和开发成本与多数据支持成反比,如果为了保障高性能、低研发成本,就需要在多数据库支持上做一些让步。从做产品的角度考虑,应主推一种数据库,国内成熟的产品是采用的如此的商业方案(例如:用友的财务软件仅支持SQLServer,这样对企业和用户本身都是效率最高、成本最低的选择)
对于技术上来将,移植数据库,我们的产品不论如何都要投入资源。投入的资源比绑定数据库要高出很多。
同时,对于实际商业需求来说,客户给我们提供的利润还不足以使我们的研发团队使每个产品在每个主流数据库(SQLServer、DB2、Oracle、Sybase、Informix、MYSQL等)都提供完善的支持。
所以,我们的产品需要绑定数据库。

6.5 界面技术为什么叫AJAX,不叫HTC
HTC是微软提出的界面组件的一种解决方案,但此方案,微软本身并不推荐。现在技术上主流的是AJAX,微软也在推此方案,并为此方案建立了一个界面架构――Atlas,所以我们的界面组件也随主流,叫AJAX,而不是HTC。

50,523

社区成员

发帖
与我相关
我的任务
社区描述
Java相关技术讨论
javaspring bootspring cloud 技术论坛(原bbs)
社区管理员
  • Java相关社区
  • 小虚竹
  • 谙忆
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧