選擇框架需要考慮的問題

2008-12-2

需要考慮的問題：

1.集羣

2.事務處理

3.安全   
4. 日誌   
5. cache  
6.國際化  
7.報表  
8.打印   
9. 客戶端校驗  
10.重複提交  
11.異常處理  
12.分頁      等等

 

 

考慮集羣的目的：

負載均衡和高可用性（HA）,需要分佈式集羣,在不同的機器發佈不同的模塊的集羣是很少的.

 

需要集羣的對象：

 

能集羣的對象只能是哪些部署的分佈式對象。因此，負載均衡和故障轉移發生在調用分佈式對象方法時。這樣的分佈式對象包括：JSP&Servlet(HTTP),DB Object(Statement execute),EJB Object(method invoke),JMS Broker(message.send),JNDI Object(Context.lookup),Web Service(SOAP/HTTP)

 

 

按照層次劃分集羣可以分爲：

1. web層集羣

2.app（業務邏輯）層集羣

3.數據庫層集羣

 

按照這3層分別簡述ejb和spring的區別

 

對於ejb集羣：

1.web層集羣

2. Application集羣

3. 再加上一個數據庫層集羣

ejb集羣,一般web和app物理上分開好處：
  1：更加安全，因爲app   server一般部署在放火牆裏面；  
  2：對於一些關鍵業務，不會相互搶佔資源；  
  3：如果採用ejb的話，可以在不同的機器發佈不同的模塊，進行分佈式計算； （也可以不進行分佈式計算）

 

對於spring的集羣：

1. 對於spring只能做一個web層集羣；

2. 加上一個數據庫層集羣；

 

web服務器和App服務器在物理上分開的好處有：

 

 

 

Cache ：

 

 

 

結論：

 

1. spring不支持集羣是指：

spring   不支持集羣，是指業務層的集羣，但每層都可以做集羣，包括數據庫層，所以我們可以在web層集羣，就用lvs，或tomcat、jboss、weblogic、apache等都可以

 

 

 

 

其他網站上的一些其他論調:  供參考： 以後理解了，再放到上面的文章裏；

 

標準的JavaEE集羣，一般情況下是這樣的。
入口是一個負載均衡器（有時候也用apache之類的），然後是若干臺web服務器（如Tomcat），再後邊是EJB集羣。最後是數據庫。
這是JavaEE集羣模型的標準構造。JavaEE集羣的核心是EJB集羣。但是如果應用沒有達到足夠大的規模，且設計不好的話，會產生很多問題。這也是當初爲什麼老EJB架構被人詬病的地方。

單機應用是中小型項目的主流。我們在中小型項目中一般只用到事務處理，分佈式、容災等功能一般用不上。所以Spring纔會發展這麼快。但是企業在發展，當初用Spring開發的程序需要跑集羣了，結果發現無法在集羣上使用，所以纔會出現用AOP方式對Spring添加集羣和JVM分佈式緩存來進行集羣化的方案。但即使如此，很多單機下可以使用的代碼，在集羣下可能是根本無法跑的。單例、靜態對象等等，在集羣模式下會出現各種問題。
所以，現在很多人都只用F5和Apache做分發器，後邊跟一大堆互不往來的Tomcat之類的Web服務器。這麼做最大的問題是無法使用緩存。因爲如果使用緩存，那麼其他機器更改了數據庫的話，緩存無法刷新而形成髒數據。結果大大拖累了性能。
如果你的應用是中小型低負載應用，那麼可以只考慮單機。如果以後要使用集羣，可以先用Spring集羣（好像是叫Cluster4Spring）和JVM分佈式緩存。如果應用大到必須分佈式的程度，那麼還是更換成EJB架構吧。

 

 

另外一個觀點  ：

EJB解決的是分佈式計算問題，不是羣集問題，就算你用EJB，你照樣無法做到緩存同步，Session同步，分佈式和羣集是兩個不同的概念；

Spring的集羣應該不是問題，我倒比較頭疼像hibernate這樣的orm，如果用於集羣，那麼cache就完全不能使用，否則一臺機器修改了數據，另一臺不知道還在用cache中的數據， 解決方式如下：

 

 

可以用memcached作爲緩存服務器，Hibernate把二級緩存放進memcached，現在Java的memcached client已經比較成熟了，性能還不錯

 

可是如果是屬於需要記錄一些數據的單例就不好說了。比如監聽者模式、記錄在線人數的Bean

 

要做大規模的羣集，就得走SNA架構，所以在編程模式上面，這種東西就不能用，但你可以把這些狀態數據放進緩存服務器，效果是一樣的

 

 

 

繼續增加中 ........