1 2 3
►
Go
共有 42 回复( 3页) 阅读202次
|
|
|
|
|
|
这篇文章被放置于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结构一样，设计和性能是实际架构选择的两个基本点，善于平衡才是我们实际架构选择的主要宗旨。
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年08月24日 18:12
|
|
|
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年08月25日 10:39
|
|
|
ejb要保存状态的话，使用sfsb不一样也需要复制策略，效率照样不高。分布式部署效率最高的时候是不考虑状态保持的情况下，不过这种情况下集群的效率也一样比较高吧……
再说了，with out EJB 并没有完全否认EJB的功能，只不过说在很多的情况下并不需要分布式部署，也不需要EJB提供的功能。我们电信boss的前台也不过只要两台机器作集群就ok了。
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年08月25日 14:46
|
|
|
没好好读这篇文章，这篇文章没有激动人心的所谓“新概念”，没有令人蒙人的“耳目一新”，踏踏实实用逻辑来分析了状态的复制策略，比较了它们之间的区别。
"只不过说在很多的情况下并不需要分布式部署，也不需要EJB提供的功能"
以前我们眼睛看到地球是平的，所以我们就认为地球是平的，在我们眼界范围内的企业系统不需要分布式，但是以后呢？以后是否能够从单机顺利迁移到分布式系统呢？
选择架构是需要长远眼光，发展眼光，需要全面的了解所有知识，不能因为我们个人能力限制或眼光短浅而毁送一个系统的生命。
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年08月26日 17:56
|
|
|
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年08月27日 19:13
|
|
|
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年09月09日 05:22
|
|
|
"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系统场合下, 二者并没有性能区别.
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年09月09日 05:47
|
|
|
再说几句:
在多数情况下, 尤其是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的全局复制的设计. 使用全局复制的集群, 如果节点比较多, 那么复制状态的网络流量将远超出正常工作的流量.
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年09月09日 10:36
|
|
|
现在的趋势是, "分布"的手段是通过WEB SERVICES而不是RMI-IIOP. "分布"单元的入口是基于WEB 的END POINT, 而不是EJB. EJB3的COMPONENT CONTRACT新加了一条关于WEB SERVICES的要求, 即是印证了这个趋势.
也就是说, 在"分布"问题上眼光短浅(或者说算计错误)的, 恰恰是主张分布EJB的.
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年09月09日 10:36
|
|
|
|
简单的说，有状态Bean的设计可以说是个错误，因为状态有很多地方可以放~谁说的，不是我，是MS.
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年09月09日 12:29
|
|
|
在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之类的参数, 岂不郁闷.
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年09月09日 15:37
|
|
|
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年09月15日 13:16
|
|
|
看来 banq 很看中Clustering啊 , 的确集群是解决我们系统性能的有利手段, 但对于普通的 web 应用来说并不需要集群的, 不被人了解也正常, 就是了解, 能实现自己的集群策略的那就更少了,记的我当时想做 Jive Messenger 的集群的时候就是一直在想集群的实现策略, 当是我在 javaeye 上发了一篇关于 clustring 的贴子,希望别人能谈谈一点想法,, 但不想马上被删除了, 我想也许是我违法了BBS规则, 不过从此可以看出中国做程序人的确做集群人少, 在自己程序中实现自己的集群策略的就更少,
后来也是看
http://www.theserverside.com/articles/article.tss?l=J2EEClustering 知道了一些, 昨天听了王昱的演讲的确很精彩!
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年09月15日 13:24
|
|
|
|
不过banq 说 Tomcat 的集群是摆设我不认同, 主要是他的目标只是两三台机器, 那么就不能说是摆设, 其次你一般的应用又能做多少机器哩, 我认为国内的集群除去电信的应用, QQ SERVER 的集群应该也不错, 只是猜想!
|
|
|
|
|
|
Re: J2EE集群原理
|
2005年09月16日 09:06
|
|
|
>QQ SERVER 的集群应该也不错
我2001年去过QQ和它的机房，他们当时是很朴素的多服务器计算，类似sina那种思路，现在不知是否上集群。
|
|
|
|
上一主题
下一主题
登陆
.text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://my.poco.cn/fav/storeIt.php?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t)+'&img=http://www.h-strong.com/blog/logo.gif','keyit','scrollbars=no,width=475,height=575,status=no,resizable=yes'));keyit.focus();){kind=logo}
返回本主题
返回页首
