這篇文章被放置于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結構一樣，設計和性能是實際架構選擇的兩個基本點，善于平衡才是我們實際架構選擇的主要宗旨。