結合經驗淺談J2EE Cluster下的開發

通常來講，一個相對大型的J2EE系統，都會採用如下這種Cluster的架構，

 

 Load Balancer －Web Server 1，2 －App Server 1，2

 

而其中Web Server 1，Web Server 2交叉鏈接App Server1，App Server 2叫作Active/Active Mode；Web Server 1直連App Server1，Web Server 2直連App Serer2，叫作Active/Standby Mode。

 

Cluster的好處這裏就不提了，這裏想談談Cluster的Limitation。

 

1. Failover並不能徹底避免錯誤。咱們指望的是，一個Request過來，假如接受請求的App Server Down了，請求可以無縫的鏈接到另外一臺App Server去，沒錯，理論上應當如此。可是請注意Failover自己有其前提條件，「在方法調用之間」。而大多數的狀況是，Client端會直接收到錯誤信息，除非這個方法是「冪等」的，例如Listing，Display，只有在這種狀況下，某些足夠聰明的Load Balancer纔會將Failover轉移到另外一個Instance上面。

 

2. 你可能會認爲在一個Transaction中的全部方法都應該是冪等的，由於當請求失敗時，Transaction會Rollback，對系統狀態所作的改變所有會撤銷，但實際的狀況是，Transaction的界限極可能沒法包含全部的RMI Call的邊界。

 

3. 在Cluster的環境中，HTTP Session的使用有不少的限制，最重要的一點是Session中的Object必須是Serializable的。可是一些Design Pattern或者MVC Framework會在HTTP Session中存儲一些UnSerializable的Object，如Servlet上下文，Web Service的引用等等，這種設計在Cluster下是沒法正常工做的。所以，並非全部的Standalone Application可以透明的遷移到Cluster中來的。

 

4. 靜態變量的使用要很是當心。傳統的Design Pattern 「Singleton」會使用靜態變量來實現對多個Object之間的狀態共享，這個在Cluster中是徹底失效的，由於Cluster中的每一個Server Instance都會有本身的一個JVM，這樣打破了這個Design Pattern的機制。固然，必定要使用這個模式生效，能夠考慮用DB來保存狀態。

 

5. 交叉Mode比直連Mode更靈活？非也。大多數的的Server都是Web Container和EJB Container在同一個JVM Instance中運行的，讓EJB Container處理來自其餘Server的Web Container的Request不見得比處理本身Web Container的Request來得高效。若是EJB Container所在的Server Down了，Web Container也基本上Down了，交叉Mode沒有提升可用性。交叉Mode有可能會致使Performance的低下，由於容易產生沒必要要的，跨Server的交互，若是方法中有Transaction，那麼Transaction的邊界就要包含多個Server Instance。

 

6. 實際上，不少廠商包括JES，Weblogic，JBoss等等，對於EJB的Load Balancer都作了優化，優先選擇在同一個Server Instance上的EJB。這就成了Active/Standby，也就是直連Mode了。