一位ID是jackson1225的网友在javaeye询问了一个大型Web系统的架构和部署选型问题，希望能提高现有的基于Java的Web应用的服务能力。由于架构模式和部署调优一直是Java社区的热门话题，这个问题引发了很多热心网友的讨论，其中一些意见对其它大型Web项目也有很好的指导意义。在讨论之初jackson1225这样描述了当前的应用的架构和部署方案：

目前系统架构如下:

1. web层采用struts+tomcat实现，整个系统采用20多台web服务器，其负载均衡采用硬件F5来实现；
2. 中间层采用无状态会话Bean+DAO+helper类来实现，共3台weblogic服务器，部署有多个EJB，其负载均衡也采用F5来实现；
3. 数据库层的操作是自己写的通用类实现的，两台ORACLE数据库服务器，分别存放用户信息和业务数据；一台SQL SERVER数据库，是第三方的业务数据信息；

web层调用EJB远程接口来访问中间件层。web层首先通过一个XML配置文件中配置的EJB接口信息来调用相应的EJB远程接口；

该系统中一次操作涉及到两个ORACLE库以及一个SQL SERVER库的访问和操作，即有三个数据库连接，在一个事务中完成。

这样的架构其实很多公司都在使用，因为Struts和Tomcat分别是最流行的Java Web MVC框架和Servlet容器，而F5公司的负载均衡是横向扩展常见的解决方案（例如配置session sticky方案）。由于这个系统中有跨数据源的事务，所以使用Weblogic Server EJB容器和支持两阶段提交的数据库驱动就可以保证跨数据源的事物完整性（当然，容器管理的分布式事务并非是唯一和最优的解决方案）。

但是随着Rod Johnson重量级的著作《J2EE Development without EJB》和其中的Spring框架的流行，轻量级框架和轻量级容器的概念已经深入人心。所以对于jackson1225提出的这个场景，大多数网友都提出了置疑，认为这个系统滥用了技术，完全是在浪费钱。网友们大都认为SLSB（无状态会话Bean）完全没有必要出现在这个场景中，认为SLSB通过远程接口访问本地资源会有很大的性能开销，这种观点也是Rod johnson在without EJB中批判EJB 2.x中的一大反模式。

由于JavaEE是一个以模式见长的解决方案，模式和架构在JavaEE中占有很重要的地位，所以很多业内专家也都警惕“反模式（Anti-patterns）”的出现。对于上面所述的方案是否是反模式，jackson1225马上站出来申辩：

我们项目就是把EJB作为一个Facade，只是提供给WEB层调用的远程接口，而且只用了无状态会话Bean，所以性能上还可以的。

这个解释很快得到了一些网友的认可，但是大家很快意识到架构的好坏决定于是否能够满足用户的需求，davexin（可能是jackson1225的同事）描述了这个系统的用户和并发情况：

现在有用户4000万，马上要和另一个公司的会员系统合并，加起来一共有9000万用户。数据量单表中有一亿条以上的数据。这是基本的情况，其实我觉得现在的架构还是可以的，现在支持的并发大概5000并发用户左右，接下来会进行系统改造，目标支持1万个并发用户。

具体的并发量公布后又有网友置疑这个数据，认为这个系统的Servlet容器支持的并发数太小，怀疑是否配置不够优化。davexin又补充了该项目的服务器配置：

系统前端tomcat都是用的刀片，配置在2G内存，cpu大概在2.0G，每台机器也就支持250-400个并发，再多的话，就会相应时间非常的常，超过20秒，失去了意义 ，所以我们才得出这样的结论的。

一位ID是cauherk的网友提出了比较中肯的意见，他没有从Web容器单纯的并发支持能力上提出改进方案，而是提出了对于类似的应用的一些通用的改进提示，这里摘要一下：

1. 数据库压力问题

   可以按照业务、区域等等特性对数据库进行配置，可以考虑分库、使用rac、分区、分表等等策略，确保数据库能正常的进行交易。

2. 事务问题

   要在两个数据库中操作，那么必须考虑到分布式事务。你应该仔细的设计你的系统，来避免使用分布式事务，以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并不保证数据的完整)，来避免分布式事务的问题，毕竟commit失败的几率很低。

3. web的优化

   将静态、图片独立使用不同的服务器，对于常态的静态文件，采用E-TAG或者客户端缓存， google很多就是这样干的。对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力。

   对于几乎除二进制文件，都应该在L4上配置基于硬件的压缩方案，减少网络的流量。提高用户使用的感知。

4. 网络问题

   可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资，可以采用CDN(内容分发网)，减轻你的服务器压力。

cauherk的这个分析比较到位，其中ETags的方案是最近的一个热点，InfoQ的“使用ETags减少Web应用带宽和负载”里面对这种方案有很详细的介绍。一般以数据库为中心的Web应用的性能瓶颈都在数据库上，所以cauherk把数据库和事务问题放到了前两位来讨论。但是davexin解释在所讨论的这个项目中数据库并非瓶颈：

我们的压力不在数据库层，在web层和F5。 当高峰的时候 ，F5也被点死了，就是每秒点击超过30万，web动态部分根本承受不了。根据我们程序记录，20台web最多承受5000个并发，如果再多，tomcat就不响应了。就像死了一样。

这个回复让接下来的讨论都集中于Web容器的性能优化，但是JavaEye站长robbin发表了自己的意见，将话题引回了这个项目的架构本身：

performance tuning最重要的就是定位瓶颈在哪里，以及瓶颈是怎么产生的。

我的推测是瓶颈还是出在EJB远程方法调用上！

tomcat上面的java应用要通过EJB远程方法调用，来访问weblogic上面的无状态SessionBean，这样的远程方法调用一般都在100ms~500ms级别，或者更多。而如果没有远程方法调用，即使大量采用spring的动态反射，一次完整的web请求处理在本地JVM内部的完成时间一般也不过20ms而已。一次web请求需要过长的执行时间，就会导致servlet线程被占用更多的时间，从而无法及时响应更多的后续请求。

如果这个推测是成立的话，那么我的建议就是既然你没有用到分布式事务，那么就干脆去掉EJB。weblogic也可以全部撤掉，业务层使用spring取代EJB，不要搞分布式架构，在每个tomcat实例上面部署一个完整的分层结构。

另外在高并发情况下，apache处理静态资源也很耗内存和CPU，可以考虑用轻量级web server如lighttpd/litespeed/nginx取代之。

robbin的推断得到了网友们的支持，davexin也认同robbin的看法，但是他解释说公司认为放弃SLSB存在风险，所以公司倾向于通过将Tomcat替换为Weblogic Server 10来提升系统的用户支撑能力。robbin则马上批评了这种做法：

坦白说我还从来没有听说过大规模互联网应用使用EJB的先例。为什么大规模互联网应用不能用EJB，其实就是因为EJB性能太差，用了EJB几乎必然出现性能障碍。

web容器的性能说到底无非就是Servlet线程调度能力而已，Tomcat不像WebLogic那样附加n多管理功能，跑得快很正常。对比测试一下WebLogic的数据库连接池和C3P0连接池的性能也会发现类似的结论，C3P0可要比WebLogic的连接池快好几倍了。这不是说WebLogic性能不好，只不过weblogic要实现更多的功能，所以在单一的速度方面就会牺牲很多东西。

以我的经验来判断，使用tomcat5.5以上的版本，配置apr支持，进行必要的tuning，使用BEA JRockit JVM的话，在你们目前的刀片上面，支撑500个并发完全是可以做到的。结合你们目前20个刀片的硬件，那么达到1万并发是没问题的。当然这样做的前提是必须扔掉EJB，并置web层和业务层在同一个JVM内部。

接下来robbin还针对davexin对话题中的应用分别在tomcat和weblogic上的测试数据进行了分析：

引用：

2。1台weblogic10 Express（相当于1台tomcat，用于发布jsp应用）加1台weblogic10（发布ejb应用），能支持1000个并发用户......
......
4。1台tomcat4.1加1台weblogic8，只能支持350个并发用户，tomcat就连结超时，说明此种结构瓶颈在tomcat。

这说明瓶颈还不在EJB远程调用上，但是问题已经逐渐清楚了。为什么weblogic充当web容器发起远程EJB调用的时候可以支撑1000个并发，但是tomcat只能到350个？只有两个可能的原因：

1. 你的tomcat没有配置好，严重影响了性能表现
2. tomcat和weblogic之间的接口出了问题

 

接着springside项目发起者江南白衣也提出了一个总体的优化指导：

1.基础配置优化

tomcat 6？ tomcat参数调优?
JRockit JVM? JVM参数调优？
Apache+Squid 处理静态内容？

2.业务层优化

部分功能本地化，而不调remote session bean?
异步提交操作,JMS？
cache热点数据？

3.展示层优化

动态页面发布为静态页面？
Cache部分动态页面内容？

davexin在调整了Tomcat配置后应验了robbin对tomcat配置问题的质疑，davexin这样描述经过配置优化以后的测试结果：

经过测试，并发人数是可以达到像robbin所说的一样，能够在600人左右，如果压到并发700人，就有15%左右的失败，虽然在调整上面参数之后，并发人数上去了，但是在同样的时间内所完成的事务数量下降了10%左右，并且响应时间延迟了1秒左右，但从整体上来说，牺牲一点事务吞吐量和响应时间，并发人数能够提高500，觉得还是值得的。

至此这个话题有了一个比较好的结果。这个话题并非完全针对一个具体的项目才有意义，更重要的是在分析和讨论问题的过程中网友们解决问题的思路，尤其是cauherk、robbin、江南白衣等几位网友提出的意见可以让广大Java Web项目开发者了解到中、大型项目所需要考虑的架构和部署所需要考虑的关键问题，也消除了很多人对轻量Servlet容器与EJB容器性能的一些误解。

在讨论中还有一些小插曲，如davexin和江南白衣讨论了JRocket的实时（Realtime）版本是否可以提升Servlet容器的相应能力，答案是不可以。还有ID为mfc42d的网友从Servlet容器的并发支持能力引申到了Java的线程调度能力和NIO对Servelet容器的意义，他推荐了自己的两篇不错的blog“java的线程实现”和“java进程使用的最大内存的数值”，blog文章里面从JVM源码级别分析了Java的线程支持能力，面临JVM性能调优问题的网友可以认真阅读一下。

Ganesh的原文：
Hibernate - Difference between session's get() and load()
http://gmarwaha.blogspot.com/2007/01/hibernate-difference-between-sessions.html
TSS上的讨论：
Difference between Hibernate's get() and load()?
http://www.theserverside.com/news/thread.tss?thread_id=43887

我以前翻译的Hibernate的session的javadoc，当时好像从字面上没有什么大的区别，配合这个帖子，要重新想一想:D
http://www.blogjava.net/iamtin/archive/2006/03/06/33910.html

BTW：因为做手术在家休养，所以才有时间发发牢骚:D

其实关键问题是DetachedCriteria.getExecutableCriteria返回的Criteria实例中已经包含了投影和排序信息，如果你­想先查总数，
就得先去掉这些信息；查完总数，再查实际数据时，又得加上这些信息。而Criteria可没提供对它改来改去的接口。

不过，仔细考察一下DetachedCriteria可以发现，它类似一种暂存了查询条件的值对象，通过与一个session对象结合生成
一个“可执行的”Criteria，相当于先执行session.createCriteria，然后把自己保存的条件设置进去。

既然如此，我干脆自己提供一个类似的类，暂存查询条件，与session结合生成executableCriteria；但我先提供给用户一个只包含
查询条件的Criteria实例，让用户先拿着它去查总数；然后再提供加入投影和排序信息的方法，让用户拿着它去查数据，不就解决问题了。

-------------- 示例代码：

MyDetachedCriteria dc =  
Criteria c = dc.getExecutableCriteria( session );       //这里的c只包含查询条件，不包括投影和排序 
c.setProjection( Projections.rowCount() ); 
Integer total = (Integer) c.uniqueResult();             //得到总数 
dc.fillProjectionSetting( c );          //把dc中保存的投影信息设置进去 
dc.fillOrdersSetting( c );          //把dc中保存的排序信息设置进去 
List data = c.list();                           //取回数据 


-------------- MyDetachedCriteria的代码： 
/** 
 * 单独的值对象，用于暂存与Criteria相关的查询条件，并可与Session结合生成一个可执行的Criteria<br> 
 * <br> 
 * 该类继承自DetachedCriteria只是为了保持接口兼容性，其实与DetachedCriteria没关系 <br> 
 * （之所以叫“Detached”，是指与Session脱离） 
 */ 
public class MyDetachedCriteria extends DetachedCriteria { 


        private Class entityClass; 


        private ArrayList criterions = new ArrayList(); 


        private ArrayList orders = new ArrayList(); 


        private Projection projection; 


        /** 
         * @param entityClass 
         */ 
        public MyDetachedCriteria( Class entityClass ) { 
                super( entityClass.getName() ); 
                this.entityClass = entityClass; 
        } 


        /** 
         * @see org.hibernate.criterion.DetachedCriteria#add(org.hibernate.criterion.Criter­ion) 
         */ 
        public DetachedCriteria add( Criterion criterion ) { 
                criterions.add( criterion ); 
                return this; 
        } 


        /** 
         * @see org.hibernate.criterion.DetachedCriteria#addOrder(org.hibernate.criterion.O­rder) 
         */ 
        public DetachedCriteria addOrder( Order order ) { 
                orders.add( order ); 
                return this; 
        } 


        /** 
         * @see org.hibernate.criterion.DetachedCriteria#setProjection(org.hibernate.criter­ion.Projection) 
         */ 
        public DetachedCriteria setProjection( Projection projection ) { 
                this.projection = projection; 
                return this; 
        } 


        // --------------------------------------------------------------------------- 


        /** 
         * 根据Session实例创建一个Criteria实例，并填充入此对象自身保存的条件后返回<br> 
         * 注意：返回的Criteria实例不含排序和投影信息，用户需要自己调用fillOrdersSetting、 
         * fillProjectionSetting填充入排序和投影信息 
         * 
         * @see org.hibernate.criterion.DetachedCriteria#getExecutableCriteria(org.hibernat­e.Session) 
         */ 
        public Criteria getExecutableCriteria( Session session ) { 
                Criteria result = session.createCriteria( entityClass ); 


                for ( Iterator i = criterions.iterator(); i.hasNext(); ) { 
                        Criterion criterion = ( Criterion ) i.next(); 
                        result.add( criterion ); 
                } 


                return result; 
        } 


        /** 
         * 填充入排序信息设置 
         * 
         * @param criteria 
         * @return 
         */ 
        public Criteria fillOrdersSetting( Criteria criteria ) { 
                for ( Iterator i = orders.iterator(); i.hasNext(); ) { 
                        Order order = ( Order ) i.next(); 
                        criteria.addOrder( order ); 
                } 


                return criteria; 
        } 


        /** 
         * 填充入投影信息设置 
         * 
         * @param criteria 
         * @return 
         */ 
        public Criteria fillProjectionSetting( Criteria criteria ) { 
                criteria.setProjection( projection ); 
                return criteria; 
        } 



} 

Update 2006-6-6 20:52：
恩，谢谢诸位。想了想还是DetachedCriteria设计的目的和我想要的不一样。DetachedCriteria目前只是为了脱离session就可以构造，而并不是为了反复使用。
因为：1、它里面只包装了一个CriteriaImpl，所以实际上两者生命周期比较一致。而且每次getExecutableCriteria都直接返回这个CriteriaImpl，而不是重新创建，这就造成了容易被意外修改。 2、它没有提供与add对应的remove方法，这就造成它只能累积而不能擦拭（对于Order），用反射就太脏了。
whimet写的这个MyDetachedCriteria倒是可以解决问题，更符合我们想要复用DetachedCriteria的需求，不过我觉得调用起来接口上不太统一。Order和Projection一般不用复用，我想就可以不用实现DetachedCriteria接口，干脆修改GenericDAO的方法好了，写个接受List<Criteria>或者Criteria...的方法对应就可以了。反正觉得DetachedCriteria目前的实现是不如意，hack它吧……我就想提供remove这些Order和Projection的方法。
这里用反射解决了他遇到的Order的问题，大家可以参考，看来DetachedCriteria目前实现的还不够令人满意：
关于Hibernate的DetachedCriteria查询的addOrder问题的解决办法

org.hibernate
Interface Session

All Superinterfaces:

Serializable

All Known Subinterfaces:

EventSource, Session

All Known Implementing Classes:

SessionImpl

public interface Session

extends Serializable

Java应用程序与Hibernate之间的主要运行时接口。它是抽象了持久化服务概念的核心抽象API类。

Session的生命周期绑定在一个物理的事务（tansaction）上面。（长的事务可能跨越多个数据库事物。）

Session的主要功能是提供对映射的实体类实例的创建，读取和删除操作。实例可能以下面三种状态存在：

自由状态（transient）: 不曾进行持久化，未与任何Session相关联
持久化状态（persistent）: 仅与一个Session相关联
游离状态（detached）: 已经进行过持久化，但当前未与任何Session相关联

游离状态的实例可以通过调用save()、persist()或者saveOrUpdate()方法进行持久化。持久化实例可以通过调用 delete()变成游离状态。通过get()或load()方法得到的实例都是持久化状态的。游离状态的实例可以通过调用 update()、0saveOrUpdate()、lock()或者replicate()进行持久化。游离或者自由状态下的实例可以通过调用merge()方法成为一个新的持久化实例。

save()和persist()将会引发SQL的INSERT，delete()会引发SQLDELETE，而update()或merge()会引发SQLUPDATE。对持久化（persistent）实例的修改在刷新提交的时候会被检测到，它也会引起SQLUPDATE。saveOrUpdate()或者replicate()会引发SQLINSERT或者UPDATE。

其具体实现并不一定是线程安全的。每个线程/事务应该从一个SessionFactory获取自己的session实例。

如果其持久化对象类是可序列化的，则Session实例也是可序列化的。

一个典型的事务应该使用下面的形式：

 Session sess = factory.openSession();
 Transaction tx;
 try {
     tx = sess.beginTransaction();
     //do some work
     ...
     tx.commit();
 }
 catch (Exception e) {
     if (tx!=null) tx.rollback();
     throw e;
 }
 finally {
     sess.close();
 }
 

Author:

Gavin King

See Also:

SessionFactory

equals:
就是判断是否相等的方法。
基本约定如下：
自反：就是x.equals(x)应该返回true
对称：x.equals(y)返回true则y.equals(x)返回true
传递：x.euqls(y)==true，y.equals(z)==true，那么x.equals(z)也必须返回true
持续性：就是说如果x.equals(y)==true，不管它调用多少次都应该返回true
非空引用：x.equals(null)应该返回false

准则原因这里：
http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html#hashCode()

在实际Domain中如何实现他们比较好呢？从eclipseWork中的模板生成如下：

public boolean equals(Object rhs) {
        if (rhs == null) {
            return false;
        }

        if (!(rhs instanceof Town)) {
            return false;
        }

        Town that = (Town) rhs;

        if ((this.getId() == null) || (that.getId() == null)) {
            return false;
        }

        return (this.getId().equals(that.getId()));
    }

public int hashCode() {
        if (this.hashValue == 0) {
            int result = 17;
            int idValue = (this.getId() == null) ? 0 : this.getId().hashCode();
            result = (result * 37) + idValue;
            this.hashValue = result;
        }

        return this.hashValue;
    }