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结构一样,设计和性能是实际架构选择的两个基本点,善于平衡才是我们实际架构选择的主要宗旨。


ejb要保存状态的话,使用sfsb不一样也需要复制策略,效率照样不高。分布式部署效率最高的时候是不考虑状态保持的情况下,不过这种情况下集群的效率也一样比较高吧……
再说了,with out ejb 并没有完全否认ejb的功能,只不过说在很多的情况下并不需要分布式部署,也不需要ejb提供的功能。我们电信boss的前台也不过只要两台机器作集群就ok了。

没好好读这篇文章,这篇文章没有激动人心的所谓“新概念”,没有令人蒙人的“耳目一新”,踏踏实实用逻辑来分析了状态的复制策略,比较了它们之间的区别。

"只不过说在很多的情况下并不需要分布式部署,也不需要ejb提供的功能"
以前我们眼睛看到地球是平的,所以我们就认为地球是平的,在我们眼界范围内的企业系统不需要分布式,但是以后呢?以后是否能够从单机顺利迁移到分布式系统呢?

选择架构是需要长远眼光,发展眼光,需要全面的了解所有知识,不能因为我们个人能力限制或眼光短浅而毁送一个系统的生命。

这篇文章询问为什么要使用有态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其实是一个分布式组件模型,这没有必要指责,就象你指责某个男人不是女人一样,它其实就是男人,所以这种指责是无来由的,无中生有,制造话题....

"JBoss Weblogic Websphere等对有态Session bean机制都比Web层的HttpSession failover要好。" ----

这样说有什么具体根据吗? HTTPSESSION 和 SFSB 的状态复制用的是同一个机制 (见http://e-docs.bea.com/wls/docs81/cluster/failover.html#1008850). 除非 JBOSS, BEA 和 IBM 程序写错了, 否则这两者在状态复制方面的性能不会有差别.

另外, 对于 WEB + EJB 系统而言, EJB层面的集群功能(主要指状态复制)是用不到的. 比如WEBLOGIC, 如果EJB是被JSP, SERVLET引用, 那么EJB的LOAD BALANCE是被禁止的, 这是WEBLOGIC内部的基本优化之一. EJB的LOAD BALANCE只有在被外部客户直接引用才有效果.

并且对于 WEB + EJB 系统而言, EJB的FAIL OVER本身也没有实际意义. 原因很简单: WEB容器和EJB容器在一个JVM里, 如果EJB容器死了, WEB容器必定也死掉了. EJB的FAIL OVER, 只有在客户继续存在的情况下才能发生. 作为客户的WEB已经死了, FAIL-OVER一个EJB呼叫是没有意义的. 从 EJB 集群的具体实现也可以看出这一点: WEBLOGIC里, EJB 的 LOAD BALANCE是通过 STUB 来实现的. 当STUB已经随WEB CLIENT 消失了, EJB LOAD BALANCE有从何谈起? 这也是 WEB 引用 EJB 时 EJB LOAD BALANCE 被禁止的原因所在.

单就性能而言, 使用SFSB并不会比使用HTTPSESSION更好. 这不仅仅是一个理论推断, 也有实际数据支持: (见http://dev2dev.bea.com/pub/a/2002/10/zadrozny.html). 这篇BEA DEV2DEV的实验文章表明, 二者的性能是大体相当的.

采用SFSB的效益, 主要在于:
1. EJB容器对交易/事物处理的支持.
2. 更符合OO设计, 可以节省某些"CONTEXT OBJECT"这样的WEB层设计模式, 和由此而来的每个WEB请求重构CONTEXT OBJECT的性能代价.
3. 支持WEB以外的外部客户.

采用SFSB的代价, 在于:
1. 必须使用EJB容器.
2. 实现时必须保证SFSB在SESSION结束或者超时后被EJBREMOVE().

在集群支持方面, 尤其在WEB系统场合下, 二者并没有性能区别.

再说几句:

在多数情况下, 尤其是WEB + EJB的情况下, 也就是说, 没有外部客户的情况下, EJB的集群不但不需要, 也没有实际意义, 而且无法实现, 至少对于WEBLOGIC是如此 (如果JBOSS和WEBSPHERE支持 WEB + EJB 情况下的EJB LOAD BALANCING, 那将十分令人发指).

对于有外部客户的情况, 外部客户多数情况下是J2SE, J2ME之类的所谓RICH CLIENT. 这样的情况下, SESSION 状态可以放在客户段. 这也是C/S传统的做法. 事实上, 即使今天, 象EBAY这样需要处理大量交易的系统, 采用的也是完全"无状态"的结构. 也就是说, 虽然EBAY系统使用J2EE, 但是状态参量是放在客户端(COOKIE, 隐藏HTML参数, JAVASCRIPT 参数, 等等), 或者直接写入数据库的. 我想, 随着AJAX, XAML和XUL的普及, 这种结构回越来越多, 越来越容易实现的.

另外, 记得前面有人讨论到硬件LOAD BALANCER和 WEBLOGIC 集群 "配对服务器" 状态复制算法不匹配的说法. 这是对"配对服务器" 状态复制算法的误解. "配对服务器"的主服务器如果脱线, 硬件服务器会把下一个请求根据 ROUND ROBIN 或其他算法分配到集群中的某服务器. 该服务器会从请求中解析出该SESSION 的主/从服务器, 然后从"从服务器"把状态复制过来, 形成新的"配对". 这种牺牲"FAIL OVER"情况下一次性性能的设计, 远胜于TOMCAT的全局复制的设计. 使用全局复制的集群, 如果节点比较多, 那么复制状态的网络流量将远超出正常工作的流量.

现在的趋势是, "分布"的手段是通过WEB SERVICES而不是RMI-IIOP. "分布"单元的入口是基于WEB 的END POINT, 而不是EJB. EJB3的COMPONENT CONTRACT新加了一条关于WEB SERVICES的要求, 即是印证了这个趋势.
也就是说, 在"分布"问题上眼光短浅(或者说算计错误)的, 恰恰是主张分布EJB的.

简单的说,有状态Bean的设计可以说是个错误,因为状态有很多地方可以放~谁说的,不是我,是MS.

在WEB+EJB COLLOCATION集群环境下, SFSB的确有点麻烦, 因为状态如果在HTTPSESSION里, 还可以复制, 在LOCAL SFSB里, 反而不行了. 当然可以用REMOTE SFSB INTERFACE, 但是这样就一定要选有优化的容器, 否则每次本地CALL也要通过SOCKET.

不过SFSB的确提供了另一个选择方案. 否则, 如果有的BO非常非常"STATEFUL",比如BO的界面本身有类似协议的逻辑(logon, logoff, appl. transaction之类的东西), 没有SFSB真的就太麻烦了. 每次EJB CALL都要象HTTP那样解析和恢复SESSION, 每个EJB成员方法界面都要有个什么context, session之类的参数, 岂不郁闷.

:D

看来 banq 很看中Clustering啊 , 的确集群是解决我们系统性能的有利手段, 但对于普通的 web 应用来说并不需要集群的, 不被人了解也正常, 就是了解, 能实现自己的集群策略的那就更少了,记的我当时想做 Jive Messenger 的集群的时候就是一直在想集群的实现策略, 当是我在 javaeye 上发了一篇关于 clustring 的贴子,希望别人能谈谈一点想法,, 但不想马上被删除了, 我想也许是我违法了BBS规则, 不过从此可以看出中国做程序人的确做集群人少, 在自己程序中实现自己的集群策略的就更少,

后来也是看
http://www.theserverside.com/articles/article.tss?l=J2EEClustering 知道了一些, 昨天听了王昱的演讲的确很精彩!

不过banq 说 Tomcat 的集群是摆设我不认同, 主要是他的目标只是两三台机器, 那么就不能说是摆设, 其次你一般的应用又能做多少机器哩, 我认为国内的集群除去电信的应用, QQ SERVER 的集群应该也不错, 只是猜想!

>QQ SERVER 的集群应该也不错
我2001年去过QQ和它的机房,他们当时是很朴素的多服务器计算,类似sina那种思路,现在不知是否上集群。