现在的位置: 首页 > 综合 > 正文

仅仅Spring+hibernate系统架构为什么不可取

2013年12月10日 ⁄ 综合 ⁄ 共 2162字 ⁄ 字号 评论关闭

http://dev.firnow.com/course/3_program/java/javashl/2008510/115053.html

 

 

对于大的应用程序来讲,如果仅仅使用Spring+hibernate 对于系统的性能和可扩展性来讲将是很大的限制。

 

        
首先我们要知道Spring+hibernate的技术架构只支持Web应用系统,因为Spring可以仅仅看成是一个JavaBean的反射管理机制,
实际上Spring+hibernate的技术架构通常用于中小系统中。这是因为Spring+hibernate没有针对系统的性能做出任何的事情,关
键的问题是Spring不支持集群。

       
Spring+hibernate设计开发的系统实际上不用使用WebLogic,WebSphere这样的应用服务器,仅仅使用一个支持JSP和
Servlet的容器的Web服务器(例如:Tomcat)就可以运行了。从运行的角度上来讲,这已经说明了
Spring+hibernate设计开发的系统是不能充分利用应用服务器提供的各种性能扩展和集群的功能的。我们下面使用Tomcat来说明原因:
        
因为Tomcat是只支持Web应用系统,所以采取tag+Spring+hibernate、struts+Spring+hibernate、
struts+hibernate或tapestry+hibernate都属于Web应用系统,他们都是单机Stand-alone系统,当系统的访问
量很大并且需要进行负载均衡,利用上述Web服务器的负载平衡只能勉强支撑两三台服务器,而且随着访问量增加,Tomcat等Web服务器将趋于缓慢,
Web应用程序在性能的伸缩性不太高。因此在大型的核心应用系统中,应当避免仅仅使用Web容器来完成系统的功能。也就是说仅仅使用Spring+
hibernate的机制是不够的。而他们都是单机Stand-alone系统不支持分布式事务,均衡负载,因为使用Spring,如果抛开Spring

管理Bean的功能来看,实际上就是jsp+javaBean+db来完成的系统。在简单一点就是jsp直接调用DB,大家想一下,这样的系统是如果支持
大的应用系统呢?在实际的实现过程中为了使Spring支持分布式事务,可以在Spring中替换使用本地JDBC连接换成JNDI数据库连接就可以了的
说法,又看到在Action(Servlet)里面使用2段式JTA的提交方法就可以支持分布式事务的说法。但是上面的解决方法,仅仅更换数据源
JNDI,只是利用了容器提供的数据库连接池等一些特性,包括跨数据库的一些事务机制。这适合一个app server + 多台db
server。如果使多台app server + 一台db
server,目前除非自己手工做,只有使用EJB是最直接方便的办法。同时如果单机结构要实现集群,需要考虑很多问题,如状态/缓存
httpsession以及特殊的服务等,而这些东西如果使用EJB的方式将自动完成,否则非常困难。

          这是因为EJB
的整体解决了所有的功能,让开发人员从系统级的开发精力放到了业务逻辑的关注中来。spring+hibernate
的确是轻量级的,分布式自己去搞,花的精力要多的多。而且代码耦合性很高,业务逻辑和事务处理代码混杂在一起。分层次很伤脑筋。使用EJB的确会使开发大
型系统在能力,安全,负载,事务,伸缩性,从体系上提高不止一个档次。spring +hibernate 轻量、快速、方便,有他的作用。EJB 架构
从开始就是从标准工业化布局,非常重量级。

         
在大型的应用系统中,我们的建议是一定要使用EJB来提高系统的响应时间和性能,这一点已经在前几年我们使用应用服务器的实际经验中证明是正确的,前几年
在系统的结构中没有使用EJB的系统到目前为止往往是效率成了困扰系统运行的主要瓶颈。如果在系统中已经使用的Spring我们建议是使用EJB来调用
Spring的结构,否则系统未来的性能、集群、分布式事务将不能保证。

        
在大型的应用系统架构中一定要设计为集群架构,集群架构是完全不同于单机结构的。在建立一个大型的可伸缩系统之前,我们必须对不同的J2EE服务器产品实
现集群有不同的了解和掌握,选择合适的第三方框架保证确认他们也是支持集群环境的,合适的架构设计将从集群中得益,而不是将苦难留给你的企业及其其他后来
的同事。

       
一直以来,所谓轻量的架构系统受到狂热分子的鼓吹和极端追从,甚至提出否定EJB的观点(如Spring作者提出的without
EJB),这些祸患人心的观点不能说是完全错误的,但是至少是极端,属于一叶遮目,看待EJB不能只从OO设计角度,还要从实际应用性能上考虑,就象看到
SOA结构一样,设计和性能是实际架构选择的两个基本点,善于平衡才是我们实际架构选择的主要宗旨。

       
如果是大型的分布式应用,那ejb是目前综合因数最强的一种选择,当然你也可以选择基于rmi,web
service,或则其它协议(比如cacho的hessian)的实现。而spring和hibernate和这些实现都不是什么对立的方面,完全可以
嵌入到这些应用中。

抱歉!评论已关闭.