J2EE集群原理

这篇文章被放置于TSS右边重要栏目第二个，说明很多人对J2EE集群原理认识严重不足，而且在进行架构选择时，极其容易被忽视。
http://www.theserverside.com/articles/article.tss?l=J2EEClustering

TSS上这篇来自Wang yu的文章，文章阐述了负载平衡和failover的意思，比较了Web层Tomcat的动态负载平衡和HttpSession Failover原理，由于Tomcat 5采取的是多服务器内存复制策略实现的HttpSession Failover，当一个服务器中的session改变，Tomcat要通知所有的服务器，Tomcat作为Web服务器主要负责客户端连接，当访问量增加时，Tomcat的这种Session复制策略无疑是雪上加霜，因此没有太大的实用价值。

因为Tomcat是只支持Web应用系统，所以采取struts+hibernate或tapestry+hibernate（或者中间加上Spring/Jdon）都属于Web应用系统，他们都是单机Stand-alone系统，利用上述Tomcat的负载平衡只能勉强支撑两三台服务器，而且随着访问量增加，Tomcat等Web服务器将趋于缓慢，从这篇文章观点来看，Web应用程序在性能的伸缩性不太高。

下面讨论的都是因为使用EJB后而使得你的应用程序自动获得的能力：

以Weblogic JBoss为主的采取的paired servers 对服务器复制策略则要提高性能很多，但是对load balancer算法要求高，有些普通的load balancer不一定符合要求。

IBM采取的是中央状态服务器策略；而SUN则采取的是特殊数据库复制HADB策略。

该文最后分析了JNDI EJB和JMS的集群原理，实际也是阐述了从性能集群原理上说，为什么会诞生EJB等复杂技术以及对于一些大型应用为什么需要使用EJB的原因所在。

文章还否定了这样的观点：单机系统几乎可以透明的迁移到集群结构。
在迁移时，需要考虑很多问题，如状态/缓存 httpsession以及特殊的服务等。

另外观点：分布式结构一定比配置定制结构可靠吗？不一定。
在使用EJB时有人喜欢什么都实现分布式，其实这是不必的，一般可让Web应用程序首先选择同台服务器中的EJB服务，这叫配置结构。

作者的结论是：
Clustering is different from the stand-alone environment
集群架构是完全不同于单机结构的。在建立一个大型的可伸缩系统之前，我们必须对不同的J2EE服务器产品实现集群有不同的了解和掌握，选择合适的第三方框架保证确认他们也是支持集群环境的（如Jdon框架），合适的架构设计将从集群中得益，而不是将苦难留给你的企业及其其他后来的同事（国人经常是在架构设计时，喜欢方便自己，害了系统和他人）。

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

这篇文章询问为什么要使用有态Session bean,而不是httpSession，从以上J2EE集群原理我们已经了解了原因，如果有状态尽量使用有态Session bean,因为你的J2EE容器在集群failover时，JBoss Weblogic Websphere等对有态Session bean机制都比Web层的HttpSession failover要好。

http://www.jdon.com/jive/thread.jsp?forum=16&thread=22281

关于Spring+hibernate的讨论基本可以完结：

http://www.jdon.com/jive/article.jsp?forum=121&thread=18249

Spring+hibernate属于Web系统，只能利用Web容器的集群能力，或者使用分布式缓存系统，如文中提到的：Tangosol with Distributed Cache 很贵。

那么我们什么样的代码才会自动支持集群呢？文章回答必须是分布式对象，而这篇文章告诉我们Spring不是一个分布式对象的模型：
http://jroller.com/page/kdonald?entry=spring_is_not_a_distributed

正如在Spring作者指责EJB不是一个OO组件模型一样，EJB其实是一个分布式组件模型，这没有必要指责，就象你指责某个男人不是女人一样，它其实就是男人，所以这种指责是无来由的，无中生有，制造话题....

测试表明weblogic/websphere在10台以上服务器集群cluster情况下，性能表现优越！从这里看出集群真正意义是几十台服务器的计算能力。
http://dev2dev.bea.com/blog/estahl/archive/2005/09/analysis_of_spe_1.html

网上拷贝很多的文章“JBoss 4.0.2集群指南”其实只是谈论Tomcat集群（因为JBoss的Web容器是使用Tomcat的），不是一篇完整的J2EE集群指南，存在一定的误导性。
而Tomcat集群则可以在Tomcat文档中获得非常方便简单的配置，但是它的集群在TSS上面文章提到了，是一种无可伸缩性的简陋集群。

相关讨论：
http://www.jdon.com/jive/thread.jsp?forum=46&thread=23302

集群概念不但包括负载平衡，还有更重要的容错failover，你的图只是负载平衡，而且是一种算法策略很弱智（一般是Robbin算法）的平衡，不能根据服务器内部实际线程运行来动态平衡，这个讨论在上面帖子的链接里有持续讨论，欢迎关注。

我也要哭了，我说了那么多，yuxie怎么还没有明白我的意思，你查查我回kely_Yin最后的技术帖子。

我再次重复一下我的观点：
EJB集群是组件方法级别的集群，这是一种细粒度的集群，因为EJB是一种组件架构，你在Web层能有到POJO的方法集群吗？现在Spring提供POJO方法事务，还没到POJO方法集群呢。

你在下面这个网址：
http://e-docs.bea.com/wls/docs81/ejb/understanding.html
搜索"method level and home level" 会有一个table，对EJB这两个级别的集群进行总结，总结网址如下：
http://e-docs.bea.com/wls/docs81/ejb/understanding.html#1128703

组件方法集群这种细粒度经常会需要使用，你认为没必要用，只是他的实践没有达到这个要求，如果你要求不高，EJB都可以不用呢，就是这个意思。

>我特喜欢看你到处 GOOGLE 来那些不相干的答案。搬出 BEA 的 EDOCS 有什么意义，对 WEBLOGIC 你还没入门呢。

我搬出这些文档，是因为你以前要我找证据啊，我说EJB集群可以平衡CPU处理能力，你让我给你指引，我说EJB集群是靠方法集群来达到CPU处理能力，因为你当时对EJB集群是方法级别集群概念一无所知啊。

现在我们的讨论已经到了要校验对方言论的地步，这种讨论已经没有意义了。

你对EJB方法级别的集群总是认为是实体Bean的方法级别集群，而实体Bean一般是被绑定在本地JVM的，所以你就认为整个EJB方法级别集群是无意义的。

EJB还有一个会话Bean，会话Bean不能调用会话Bean吗？会话Bean包含大量业务逻辑代码，才真正需要集群。当然不是所有的会话Bean都需要满网络得找，但是我们可以指定个别的会话Bean为集群，这样可将负载分担出去。

Web层的HttpSession导致的failover是存在的，但是Bea架构师早在TSS上专题采访中说过，尽量勿采取HttpSession。

所以Cluster中的failover几乎不太起作用，但是你的有状态机制不使用HttpSession，还要有一个东西实现啊，那么就使用有态Session Bea，在我的Jdon框架中，也提供POJO下无态和有态，但是这个POJOService是不能集群的。

另外，我觉得有兴趣的人想知道我的水平，看看我的Jdon框架便知有没有，提出疑问，很多设计有相当知识背景的。

》对于JBoss，单机最大并发量可达到多少？
取决于硬件和应用系统，自己可以使用jmeter测试一下。

>网站用weblogic集群，把apache架在前面负载均衡weblogic好？还是域名直接定向到weblogic server好？

多种集群策略合用，动态DNS也是必须的，apache相当于负载平衡器，可以有多台apache，动态域名解析到这多台apache上。apache可以实现图片静态html的缓存优化，这方面网上文章很多。