yangzheng
2005-10-28 11:28

> 现在国内大的网站都是内容网站,是一种方向推的技术,而不是互动网
>站,所以这些内容网站只要前段使用分发器以及缓存就可以了,越是动态>互动性强,对技术要求就高,这也是eBay网站 Google网站技术很高的原
>因所在。

http://blog.csdn.net/yzhz/archive/2005/02/24/300500.aspx
这是我以前翻译的一篇关于ebay架构的文章。文章结论是:
不必为架构一台有状态的服务器所困扰,更进一步,忘掉集群,你不需要它。
ebay是这么说的,也是这么做的,这也是sun做项目所推荐的。除非你的网站没有千万级乃至亿级的访问。

yuxie
2005-10-28 13:50
发明ejb是为了分布式计算,分布你的对象而不是集群,分布式和集群是两个概念,这个基本常识我想初学者也会明白的。

Kyle_Yin
2005-10-28 13:50
理解错误的是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诞生
> 氖滓颍蚍植际郊扑愣?

Kyle_Yin
2005-10-28 14:07
又错了,版主大人。
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]
>
>
> 另外负载平衡以及失效转发行激活是时刻都可能发生,但是因
> 庋姆研阅埽裕憧梢允孪壬瓒ú灰闷淦捣狈⑸?

Kyle_Yin
2005-10-28 14:17
还是错的。
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呢,这个基本常识我想初学者也会明白的。
>

yuxie
2005-10-28 14:43
好,加深了很多理解~~,多谢Kyle_Yin !

xidaboy
2005-10-28 15:17
端凳子学习.

Kyle_Yin
2005-10-28 15:33
我比较赞赏关于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做项目所推荐的
> 3悄愕耐久挥星蚣赌酥烈诩兜姆梦省?

Kyle_Yin
2005-10-28 15:34
我比较赞赏关于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做项目所推荐的
> 3悄愕耐久挥星蚣赌酥烈诩兜姆梦省?

banq
2005-10-28 17:16
我非常关系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或者其他朋友需要以上任何资料的出处,我也乐于提供文档链接。:-)"

看来我们理解点不一样啊,:)

banq
2005-10-28 17:27
我的关于集群观点到此结束,不会再发表其他观点,也多谢Yin能够真诚地和我认真讨论,从Yin发言中可以看出Yin是具备非常经验的高手,我不再象以前喜欢太过于认真较劲(最后对大家是一种伤害),如果我有错误,相信大家也能看出,只要吸取精华,剔除糟粕即可,每个人都必须有自己的判断力。

如果你赞同我的观点,并想继续深入讨论,可以请我帮你做一次企业内训,以达到共同提高和交流,当然如果你认为是错误的,就嗤之以鼻吧。

也希望和Yin能够在其他更多话题深入展开讨论,让双方收益,让更多人收益。

yuxie
2005-10-28 18:05
Banq的回复相当令人失望。让人不禁想起一个笑话:
有人问一个政客,“如何才能成为一个政治家呢?”
“哦,成为政治家,那你需要预言某段时间后的局势以及可能发生的事情”
“那如果预测错了呢?”
“错了?那就要找一个理由出来。”

Kyle_Yin
2005-10-29 00:16
首先,我的猜测、假设,是基于并始于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兄弟,技术讨论可以抽象,但是一定要精确,尽量无歧义。“软件工程”相比起硬件,到现在为止仍然是一个笑话,一部分原因就是从业者缺乏对数学概念和语义精确性的尊重和追求。

Kyle_Yin
2005-10-29 00:25
在下不敢自认高手,不过和BANQ一样,性格向来顶真。

认真较劲没问题,只要讨论严格限于客观问题本身。有些没有必要的字眼,比如“初学者”,“基本常识”云云,容易刺激别人的敌对情绪,导致技术和理论讨论流于针对个人的讽刺和攻击。大家来技术论坛的目的是探讨问题,不是来膨胀自我意识,或者打击别人的自我意识。


> 我的关于集群观点到此结束,不会再发表其他观点,也多谢Yi
> 能够真诚地和我认真讨论,从Yin发言中可以看出Yin是具备非
> >榈母呤郑也辉傧笠郧跋不短谌险娼暇ㄗ詈蠖源蠹
> 是一种伤害),如果我有错误,相信大家也能看出,只要吸取
> 蕹闫杉纯桑扛鋈硕急匦胗凶约旱呐卸狭Α?
>
> 如果你赞同我的观点,并想继续深入讨论,可以请我帮你做一
> 纹笠的谘担源锏焦餐岣吆徒涣鳎比蝗绻闳衔谴砦蟮
> ,就嗤之以鼻吧。
>
> 也希望和Yin能够在其他更多话题深入展开讨论,让双方收益?
> 让更多人收益。

banq
2005-10-29 09:42
倡导开放客观的讨论,能和Yin这样成熟理性的人交流非常有益,也请多多包含本人之前的用词不当。

Yin的观点多来自实战,非常有实用性,很多观点我在以前帖子也表达了,初学者在EJB学习上,应注重动手配置运行,EJB难学是两个原因:原理复杂;使用不方便,所以先攻克“使用不方便”这个关口。

猜你喜欢