> 现在国内大的网站都是内容网站，是一种方向推的技术，而不是互动网
>站，所以这些内容网站只要前段使用分发器以及缓存就可以了，越是动态>互动性强，对技术要求就高，这也是eBay网站 Google网站技术很高的原
>因所在。
http://blog.csdn.net/yzhz/archive/2005/02/24/300500.aspx
这是我以前翻译的一篇关于ebay架构的文章。文章结论是：
不必为架构一台有状态的服务器所困扰，更进一步，忘掉集群，你不需要它。
ebay是这么说的，也是这么做的，这也是sun做项目所推荐的。除非你的网站没有千万级乃至亿级的访问。
发明ejb是为了分布式计算，分布你的对象而不是集群，分布式和集群是两个概念，这个基本常识我想初学者也会明白的。
理解错误的是BANQ版主本人。
1。从负载平衡的实现机制角度讲，没有人说WEB负载平衡算法只有ROUND ROBIN一种。基于CPU负载的平衡算法，也就是BANQ称作“EJB集群的智能”，同样也适用于WEB负载平衡。这一点上EJB集群和WEB集群毫无区别。
BANQ所谓“EJB集群的智能”，有两个要求：CPU负荷检测，和请求重定向。这两个要求，WEB容器都可以轻松实现。有什么理由认为EJB容器可以做到这些而WEB容器不能？请问BANQ，这两点中哪一点是WEB容器不可实现的？
2。从CPU负载分布模式看， BANQ描述的WEB集群情况下大负荷请求重复定向给同一节点的问题，同样也适用于EJB集群。BANQ描述的WEB负载分配所可能出现的问题（大负荷请求重复发向同一节点），其根本假设是WEB请求的CPU负荷模式很不均匀。请问，同样的假设难道不适用于EJB? 难道EJB的CPU负荷模式莫名其妙地会比WEB请求更均匀？另外，这种情况，是计算机科学中负载平衡方面的经典病理情况，有多种方法解决。最简单的就是所有服务器都支持的随机平衡算法。更重要的，随机平衡算法也是WEB和EJB集群都支持的算法。
负载平衡不是什么EJB独有的特殊算法。EJB负载平衡算法基本上都是计算机科学里大家耳熟能详的东西。EJB和WEB在负载平衡方面，无论机理还是算法，都是一致的。BANQ似乎认为EJB集群的优势在于EJB集群能够根据CPU负荷进行重新负荷分配而WEB集群不具备这个功能。这是完全而彻底的误解。
3。从生产环境的现实角度看，这种“基于CPU负荷重新分配负载”的行为，虽然实现起来并不难，却没有多少实用价值。理论分析，模拟数据和生产实践都表明，ROUND ROBIN，RANDOM, 和根据负荷的“自适应反馈算法”，在性能方面没有很大区别。这是 相关数据在多数操作系统或者计算机网络教科书里都有描述。这听起来似乎有些奇怪，但不过是“大数定理”的必然结果。
4。从现实商业服务器支持角度看：BANQ描述的“根据CPU重新分配负荷”的行为，至少在WEBLOGIC, WEBSPHERE两者都不支持。Weblogic和WebSphere只支持 Round Robin, 加权 Round Robin和随机 这三种算法（Web集群和EJB集群都一样！）。 JBoss支持一种“First Available”的算法，但实质上是随机算法。
当然，WebLogic允许用户自己开发和定制负载分配算法，但是未见有记录表明用户通过自定义负载分配算法提高了性能的。否则，IBM，BEA，JBOSS会只支持这三种算法么？
并且，对于 WEBLOGIC 和 WEBSPHERE, 缺省状况下即使是 REMOTE EJB ， 在JNDI解析时也会被“本地优先”，根本不会做负载平衡。
再者，一旦会话建立，后续请求会由于“Session Affinity”优化而绑定在同一节点，也不会做负载平衡。
如果BANQ知道某款应用服务器支持“根据CPU动态做负载平衡”，不妨指出产品文档链接。如果BANQ或者其他朋友需要以上任何资料的出处，我也乐于提供文档链接。:-)
> 很多人还是不理解EJB动态负载平衡的优势，前面我已经举例?
> ，Web负载平衡是对请求信号分发，但是每次请求对CPU的负载
> 隙ㄊ遣灰谎模饕【鲇谡飧銮肭蟮饔玫哪歉鲎榧椒ǎE
> B方法）的运行量，根据业务逻辑不同，不同EJB方法运行占据
> PU就不一样。
>
> 所以，”Web负载平衡是对请求信号分发“方式很难将每个服?
> 器负载都平衡成50%，因为EJB方法运行量不一样，有的服务器
> 砸桓銮肭罂赡艽砗姆?CPU，但是运气不好的话，下一个?
> 要大负载的请求又可能发给它处理，累死它。
>
> 而EJB的远程方法和JNDI则可以平衡这种处理，当这台服务器?
> 载已经达到80%，又有请求发给它，它会通过JNDI和远程调用?
> 将这个请求调用的EJB方法转发调用其他负载较低的服务器上?
> EJB。
>
> 我想我说的够明白了。这就是EJB集群的智能，这也是EJB诞生
> 氖滓颍蚍植际郊扑愣?
又错了，版主大人。
JNDI查询的是HOME INTERFACE STUB。FAILOVER逻辑，在WEBLOGIC和JBOSS上，是建入在智能REMOTE STUB里的，在WEBSPHERE上是建入在代理服务器上，JES是建入在IIOP运行库里, 和JNDI都压根不搭界。
JNDI是不会根据集群运行状况而返回一个不同的STUB的。
> 接着谈failover，上述服务器转发调用其他服务器时，就需要
> üJNDI查询了（因为这是EJB调用的首要步骤），这时failov
> r就会被激活，因为总不能找一个当机的服务器给它用吧.
>
> 负载平衡以及失效转发行激活有三种方式：
>
>
> [img]http://www.huihoo.com/jboss/clustering/114489.jpg
> /img]
>
>
> 另外负载平衡以及失效转发行激活是时刻都可能发生，但是因
> 庋姆研阅埽裕憧梢允孪壬瓒ú灰闷淦捣狈⑸?
还是错的。
EJB的最初设计思想是“地点透明”（SESSION BEAN，也可以说是分布计算吧），和关系数据对象化（ENTITY BEAN），根本不是由“集群”驱动的。
请考虑：
1。如果集群是EJB的设计初衷，那么JSR里没有一条涉及集群岂不太奇怪了？
2。如果EJB集群这么重要，那么EJB2.1介入完全不能集群的LOCAL EJB岂不太奇怪了？
3。如果EJB集群这么重要，那么WEBSPHERE, WEBLOGIC缺省情况下都禁用EJB集群，而采取“本地优先”岂不太奇怪了？
4。看来BEA,IBM,JBOSS都不明白这个初学者都明白的基本常识，这岂不太奇怪了？
>
> 如果Web集群和EJB集群差不多，何必走这么多弯路，何必发明
> JB呢，这个基本常识我想初学者也会明白的。
>
好，加深了很多理解~~，多谢Kyle_Yin ！
端凳子学习.
我比较赞赏关于EBAY的这篇文章。SUN 给 EBAY 做架构咨询的那个印度伙计JAVAONE上大谈特谈CORE J2EE模式的运用（那个印度伙计本人就是CORE J2EE模式的作者之一），压根没说EBAY架构设计的关键 － 应用服务器无会话状态设计。
但是这种设计不是很容易能够达到的。服务器无会话状态就意味这会话状态转移到了数据库和客户端。客户端存储会话状态首先有COOKIE数量的绝对限制，并且会带来网络传输负荷增加的问题。数据库会话状态也有性能负担的问题。 所以，这样的“无状态”设计，需要仔细的数值性能分析和模拟，不是普通应用开发者能够轻易做好的。
另外再挑BANQ一个毛病： :-)
这个问题是有无会话状态，和会话状态放在哪里的问题，和“动态，互动”啥的毫无干系。要说动态，互动，古时候WINDOWS CLIENT/SERVER架构下会话状态全在客户端，那个年代的应用服务器大多是无状态设计的。
个人看法，现在的B/S架构是不会长久用下去的。
正是BS架构下完全无状态的浏览器客户端导致了服务器必须有会话状态，从而从根本上埋下了整体架构可伸缩性的隐患，也导致了SESSION REPLICATION等等问题。试想，如果服务器只提高SLSB，MDB和ENTITY，那么每个服务器在任何时间都是平等对称的，没有会话状态复制问题，那么系统架构的水平伸缩岂不完全不费吹灰之力？
BS架构的另一个问题是HTML应用的互动性与响应速度问题。试想，一个一天输入成百上千条订单的商用程序，如果用VC/VB/PB/DELPHI写，它的响应速度肯定是用HTML无法比拟的。比如，在VC/VB/PB/DELPHI里写一个下拉组合框做输入过滤是多么轻松，而在HTML上，最近YAHOO和GLLGLE才出现这样的功能。
从计算能力方面看，BS架构也很不合理。从整个系统看，大量的逻辑运算放在服务器方，而功能强大的客户端放着INTEL P4 CPU，却只做个HTML浏览器用。同时，大量重复的HTML反复地占用网络带宽。。。真是BS不除，网难未已。
基于AJAX技术的应用架构，就是对上面这两个问题的一个消极反应。AJAX里大量运用的JS变量，就是会话状态在向客户端转移。而AJAX里DHTML的广泛运用，就是把界面逻辑向客户端转移。其实除了HTML以外，AJAX也可以和XUL, XAML结合适用，从而完全脱离多余的浏览器。
XUL在描述图形界面方面的能力，应该说无需怀疑。请考虑：FIREFOX本身就是一个XUL应用。打开你的C:\Program Files\Mozilla Firefox\chrome\browser.jar\browser.xul看看。是的，那个貌似HTML/XML的文件就是FIREFOX的界面MARKUP。而FIREFOX的菜单命令，是实现在JAVASCRIPT里面的。也就是说，FIREFOX这样复杂的图形界面，就建立在XML和JAVASCRIPT上。不止FIREFOX，MOZILLA的JS DEBUGGER - VENKAMAN, EMAIL AGENT － PHOENIX，通通是XUL + JAVASCRIPT的架构。
也就是说，如果你有了XUL ENGINE (打包在FIREFOX里)，或者XAML(打包在WIN VISTA里)，那么你的 JSP 就不必在输出HTML，而需要输出XUL, 或者XAML。并且，这个JSP不会每个请求都重新被运行一次，而是在客户第一次运行你的程序是运行一次，此后的每个请求，你的WEB SERVER只返回少量的XML业务数据（SOAP消息），而不返回任何界面数据，没有HTML，没有XUL。 而你的应用程序本身，也不在浏览器里运行，而是向FIREFOX那样的真正的RICH CLIENT。所有的会话状态存在客户端JAVASCRIPT里，服务器真正实现了无会话状态从而大大提高了水平伸缩性，而网络传输因为界面数据的大大减少，响应速度也会大幅度提高。
XUL/XAML + JAVASCIPT + SOAP
多么诱人啊。
AJAX的问题，在于JAVASCRIPT。JAVASCRIPT既不能隐藏数据，也不能隐藏逻辑。另外，JAVASCRIPT的弱类型（其实是无类型），不支持真正意义上的OO（没有内建的类，继承，多态，虽然这些可以用FUNCTION, TEMPLATE来模拟），解释而不是编译，导致了JAVASCRIPT 故障/代码率远远高于JAVA。在XUL/XAML替代了HTML，从而解决了界面描述语言之后，业界必定会找到替代JAVASCRIPT的逻辑运行语言。那时候，天下就太平了。
另一个可能，是 JNLP + SOAP。JAVA既做界面描述，也做逻辑语言，传输层用SOAP，在MVC方面不如XUL + JAVASCRIPT那么干净，倒也不坏。
还有一个可能，就是 MS-Office + SOAP。是的。OFFICE做所有应用程序的界面，VBSCRIPT/JSCRIPT/C作为逻辑语言，SOAP做传输。如果去年微软真的并购了SAP，那这个可能就更现实了。
离题万里了。
>
> >
> 现在国内大的网站都是内容网站，是一种方向推的技术，而不
> 腔ザ?
> >站，所以这些内容网站只要前段使用分发器以及缓存就可以?
> ，越是动态>互动性强，对技术要求就高，这也是eBay网站
> Google网站技术很高的原
> >因所在。
>
> http://blog.csdn.net/yzhz/archive/2005/02/24/300500.as
> x
> 这是我以前翻译的一篇关于ebay架构的文章。文章结论是：
>
>
> 不必为架构一台有状态的服务器所困扰，更进一步，忘掉集?
> ，你不需要它。
>
>
> ebay是这么说的，也是这么做的，这也是sun做项目所推荐的
> ３悄愕耐久挥星蚣赌酥烈诩兜姆梦省?
我比较赞赏关于EBAY的这篇文章。SUN 给 EBAY 做架构咨询的那个印度伙计JAVAONE上大谈特谈CORE J2EE模式的运用（那个印度伙计本人就是CORE J2EE模式的作者之一），压根没说EBAY架构设计的关键 － 应用服务器无会话状态设计。
但是这种设计不是很容易能够达到的。服务器无会话状态就意味这会话状态转移到了数据库和客户端。客户端存储会话状态首先有COOKIE数量的绝对限制，并且会带来网络传输负荷增加的问题。数据库会话状态也有性能负担的问题。 所以，这样的“无状态”设计，需要仔细的数值性能分析和模拟，不是普通应用开发者能够轻易做好的。
另外再挑BANQ一个毛病： :-)
这个问题是有无会话状态，和会话状态放在哪里的问题，和“动态，互动”啥的毫无干系。要说动态，互动，古时候WINDOWS CLIENT/SERVER架构下会话状态全在客户端，那个年代的应用服务器大多是无状态设计的。
个人看法，现在的B/S架构是不会长久用下去的。
正是BS架构下完全无状态的浏览器客户端导致了服务器必须有会话状态，从而从根本上埋下了整体架构可伸缩性的隐患，也导致了SESSION REPLICATION等等问题。试想，如果服务器只提高SLSB，MDB和ENTITY，那么每个服务器在任何时间都是平等对称的，没有会话状态复制问题，那么系统架构的水平伸缩岂不完全不费吹灰之力？
BS架构的另一个问题是HTML应用的互动性与响应速度问题。试想，一个一天输入成百上千条订单的商用程序，如果用VC/VB/PB/DELPHI写，它的响应速度肯定是用HTML无法比拟的。比如，在VC/VB/PB/DELPHI里写一个下拉组合框做输入过滤是多么轻松，而在HTML上，最近YAHOO和GLLGLE才出现这样的功能。
从计算能力方面看，BS架构也很不合理。从整个系统看，大量的逻辑运算放在服务器方，而功能强大的客户端放着INTEL P4 CPU，却只做个HTML浏览器用。同时，大量重复的HTML反复地占用网络带宽。。。真是BS不除，网难未已。
基于AJAX技术的应用架构，就是对上面这两个问题的一个消极反应。AJAX里大量运用的JS变量，就是会话状态在向客户端转移。而AJAX里DHTML的广泛运用，就是把界面逻辑向客户端转移。其实除了HTML以外，AJAX也可以和XUL, XAML结合适用，从而完全脱离多余的浏览器。
XUL在描述图形界面方面的能力，应该说无需怀疑。请考虑：FIREFOX本身就是一个XUL应用。打开你的C:\Program Files\Mozilla Firefox\chrome\browser.jar\browser.xul看看。是的，那个貌似HTML/XML的文件就是FIREFOX的界面MARKUP。而FIREFOX的菜单命令，是实现在JAVASCRIPT里面的。也就是说，FIREFOX这样复杂的图形界面，就建立在XML和JAVASCRIPT上。不止FIREFOX，MOZILLA的JS DEBUGGER - VENKAMAN, EMAIL AGENT － PHOENIX，通通是XUL + JAVASCRIPT的架构。
也就是说，如果你有了XUL ENGINE (打包在FIREFOX里)，或者XAML(打包在WIN VISTA里)，那么你的 JSP 就不必在输出HTML，而需要输出XUL, 或者XAML。并且，这个JSP不会每个请求都重新被运行一次，而是在客户第一次运行你的程序是运行一次，此后的每个请求，你的WEB SERVER只返回少量的XML业务数据（SOAP消息），而不返回任何界面数据，没有HTML，没有XUL。 而你的应用程序本身，也不在浏览器里运行，而是向FIREFOX那样的真正的RICH CLIENT。所有的会话状态存在客户端JAVASCRIPT里，服务器真正实现了无会话状态从而大大提高了水平伸缩性，而网络传输因为界面数据的大大减少，响应速度也会大幅度提高。
XUL/XAML + JAVASCIPT + SOAP
多么诱人啊。
AJAX的问题，在于JAVASCRIPT。JAVASCRIPT既不能隐藏数据，也不能隐藏逻辑。另外，JAVASCRIPT的弱类型（其实是无类型），不支持真正意义上的OO（没有内建的类，继承，多态，虽然这些可以用FUNCTION, TEMPLATE来模拟），解释而不是编译，导致了JAVASCRIPT 故障/代码率远远高于JAVA。在XUL/XAML替代了HTML，从而解决了界面描述语言之后，业界必定会找到替代JAVASCRIPT的逻辑运行语言。那时候，天下就太平了。
另一个可能，是 JNLP + SOAP。JAVA既做界面描述，也做逻辑语言，传输层用SOAP，在MVC方面不如XUL + JAVASCRIPT那么干净，倒也不坏。
还有一个可能，就是 MS-Office + SOAP。是的。OFFICE做所有应用程序的界面，VBSCRIPT/JSCRIPT/C作为逻辑语言，SOAP做传输。如果去年微软真的并购了SAP，那这个可能就更现实了。
离题万里了。
>
> >
> 现在国内大的网站都是内容网站，是一种方向推的技术，而不
> 腔ザ?
> >站，所以这些内容网站只要前段使用分发器以及缓存就可以?
> ，越是动态>互动性强，对技术要求就高，这也是eBay网站
> Google网站技术很高的原
> >因所在。
>
> http://blog.csdn.net/yzhz/archive/2005/02/24/300500.as
> x
> 这是我以前翻译的一篇关于ebay架构的文章。文章结论是：
>
>
> 不必为架构一台有状态的服务器所困扰，更进一步，忘掉集?
> ，你不需要它。
>
>
> ebay是这么说的，也是这么做的，这也是sun做项目所推荐的
> ３悄愕耐久挥星蚣赌酥烈诩兜姆梦省?
我非常关系Yin是对我前面两个算法如何看的，因为这是我们讨论问题的关键，其他方面如果我有错误也是正常的。
"同样的假设难道不适用于EJB? 难道EJB的CPU负荷模式莫名其妙地会比WEB请求更均匀？另外，这种情况，是计算机科学中负载平衡方面的经典病理情况，有多种方法解决。最简单的就是所有服务器都支持的随机平衡算法。更重要的，随机平衡算法也是WEB和EJB集群都支持的算法。"
这是用一种猜测的思维来看EJB集群，其实我们可以用组件构件概念来解释为什么EJB集群比Web集群复杂或更科学。
我们编程时大量代码集中在组件EJB中，具体是这些EJB方法，Web的每次请求都会调用EJB方法。注意，这里你可以认为组件不一定用EJB实现，用JavaBeans实现也可以，那么同样你也需要对javaBeans的方法进行基础功能的支持，例如方法事务、方法安全，方法负载平衡，前两者Spring已经实现，后一种目前只有使用EJB才能实现，也就是将你的Javabeans使用EJB的会话Bean包装就可以了。
这是目前面向组件技术的现状。
每次客户端发出的请求会调用不同的组件方法，每个组件方法内容不同，导致服务器负载就不一样，所以对组件方法进行集群是一种细粒度的集群。
Web集群是基于请求Request，而EJB集群是基于方法，前者是粗粒度，后者是细粒度，这个道理和权限Acl道理一样，Web安全是基于请求Request和Url资源，是一种粗粒度，而组件安全，如EJB方法安全Permission配置是基于方法的，是细粒度的，Spring的Acegi是将这两种结合在一起，所以Acegi不是很容易被理解的，这是其他话题。
需要我指出一些资料的话，我们还是使用Wang Yu的那篇文章吧，EJB的负载平衡和容错几乎每时每刻都发生，这从EJB调用的每个步骤都可以看出：
他说：EJB technology is born for distributed computing.EJB是为分布式计算而生。
Wangyu说调用一个EJB经过三个步骤，第一个步骤是：Look up the EJBHome stub from a JNDI server. 然后说，负载平衡和Failover发生在第一个步骤（就是这个步骤），Load balancing and failover can happen during JNDI lookup (the 1 st step).也就是JNDI的寻找获得一个EJBHome Stub，然后他指出这个寻找有三个方式：Smart stub、IIOP Runtime Library、Interceptor Proxy。
然后，EJB集群又会发生下面两个步骤，他认为EJB能够在两个层次潜在实现负载平衡和容错EJBs can potentially realize the load balancing and failover ：
1.hen a client create or looks up an EJB object using the EJBHome stub 当客户端使用EJBHome stub来创建或寻找EJB objects。
2. When a client makes method calls against the EJB using the EJBObject stub ，当客户端使用EJBObject stub来调用EJB方法时，注意这是我前面讲的组件方法调用。
当然Wangyu这里没有详细叙说调用EJB方法是如何实现集群的，他只是说无态会话bean更容易实现集群，Stateless session bean is most probably the easiest case: as no state is involved, All EJB instances are considered identical. So the method invoking from EJBObject can be load-balanced or failed over on any participating server instances。
调用EJB方法时如何集群不同服务器实现不同，这里不是我们讨论重点，关键是验证了我前面说的基于组件方法进行集群，因为组件方法是应用系统核心代码，这些代码可能占CPU负载最多，通过对组件方法集群来实现对CPU进行负载动态平衡，而不是Yin理解的直接对CPU负载进行平衡，看这句话：
"如果BANQ知道某款应用服务器支持“根据CPU动态做负载平衡”，不妨指出产品文档链接。如果BANQ或者其他朋友需要以上任何资料的出处，我也乐于提供文档链接。:-)"
看来我们理解点不一样啊，:)
我的关于集群观点到此结束，不会再发表其他观点，也多谢Yin能够真诚地和我认真讨论，从Yin发言中可以看出Yin是具备非常经验的高手，我不再象以前喜欢太过于认真较劲（最后对大家是一种伤害），如果我有错误，相信大家也能看出，只要吸取精华，剔除糟粕即可，每个人都必须有自己的判断力。
如果你赞同我的观点，并想继续深入讨论，可以请我帮你做一次企业内训，以达到共同提高和交流，当然如果你认为是错误的，就嗤之以鼻吧。
也希望和Yin能够在其他更多话题深入展开讨论，让双方收益，让更多人收益。
Banq的回复相当令人失望。让人不禁想起一个笑话：
有人问一个政客，“如何才能成为一个政治家呢？”
“哦，成为政治家，那你需要预言某段时间后的局势以及可能发生的事情”
“那如果预测错了呢？”
“错了？那就要找一个理由出来。”
首先，我的猜测、假设，是基于并始于BANQ的假设。这一点很清楚。
猜测和假设本身并没有问题。任何问题的讨论都必须首先建立讨论对象的模型。所谓模型，本身就是假设。不过这个假设的合理性，是需要验证的。忘了那位高人曾经说过：“所有的模型都是错的。但有些模型是有用的。”
那我们就来看WEB粗粒度，EJB细粒度这个假设，或者模型的“有用性”有多少。
今天的J2EE应用，大概少不了SESSION FACADE模式。说到这里，明眼人应该已经明白我的意思了。如果你有耐心，再听我细说。
EJB的细粒度，尤其是REMOTE EJB的细粒度，事实上被生产经验证明是系统性能的杀手。这个经验观察导致了两个结果：LOCAL EJB 标准, 和 SESSION FACADE模式。
SESSION FACADE的根本意图，正是把REMOTE EJB编程粗粒度的组件。
而细粒度的LOCAL EJB，根本不具备远程调用的能力，更无从谈起集群。
也就是说，远程EJB细粒度这种作法，是一种典型的，广泛被批评的J2EE ANTI-PATTERN。所以，WEB粗粒度，EJB细粒度的模型，或者假设，可以说基本没有实际价值。
第二，WANG YU在他的文章中说什么我很清楚。需要给各位的建议是，网上的文章，毕竟是二手资料。二手资料 ＋ 猜测 ＋ 想当然 是导致概念混乱的最佳方式。如果你真想了解某个技术问题，最直接的方法，是自己写个HELLO WORLD EJB，运行起来试试。JBOSS的代码都是公开的，联上 ELIPSE 调试几下，自然比什么文档都清楚明了。毕竟，“你不能和事实辩论”。缺乏实证精神，在中国学者和技术人员里是常见病，不知是当前教育系统的问题，还是中国文化重论道轻实践的表现。
再次，如果你懒得看代码，那就仔细读读产品文档。WEBLOGIC, WEBSPHERE和JBOSS的文档对集群解释得相当细致。尤其WEBLOGIC，甚至详细地介绍集群内部实施机制和算法，比如在FAIL-OVER情况下，外部负载平衡器和服务器节点的互动时序。
最后，也许我对BANQ关于CPU负载的最初说法理解错了。不过BANQ兄弟，技术讨论可以抽象，但是一定要精确，尽量无歧义。“软件工程”相比起硬件，到现在为止仍然是一个笑话，一部分原因就是从业者缺乏对数学概念和语义精确性的尊重和追求。
在下不敢自认高手，不过和BANQ一样，性格向来顶真。
认真较劲没问题，只要讨论严格限于客观问题本身。有些没有必要的字眼，比如“初学者”，“基本常识”云云，容易刺激别人的敌对情绪，导致技术和理论讨论流于针对个人的讽刺和攻击。大家来技术论坛的目的是探讨问题，不是来膨胀自我意识，或者打击别人的自我意识。
> 我的关于集群观点到此结束，不会再发表其他观点，也多谢Yi
> 能够真诚地和我认真讨论，从Yin发言中可以看出Yin是具备非
> ＞榈母呤郑也辉傧笠郧跋不短谌险娼暇ㄗ詈蠖源蠹
> 是一种伤害），如果我有错误，相信大家也能看出，只要吸取
> 蕹闫杉纯桑扛鋈硕急匦胗凶约旱呐卸狭Α?
>
> 如果你赞同我的观点，并想继续深入讨论，可以请我帮你做一
> 纹笠的谘担源锏焦餐岣吆徒涣鳎比蝗绻闳衔谴砦蟮
> ，就嗤之以鼻吧。
>
> 也希望和Yin能够在其他更多话题深入展开讨论，让双方收益?
> 让更多人收益。
倡导开放客观的讨论，能和Yin这样成熟理性的人交流非常有益，也请多多包含本人之前的用词不当。
Yin的观点多来自实战，非常有实用性，很多观点我在以前帖子也表达了，初学者在EJB学习上，应注重动手配置运行，EJB难学是两个原因：原理复杂；使用不方便，所以先攻克“使用不方便”这个关口。