【正文】 法不是等冪的，在相同方法上的兩次調(diào)用可能會兩次修改系統(tǒng)的狀態(tài)，而使得系統(tǒng)出現(xiàn)不一致的情形。你可能想所有在事務中的方法都是等冪的，畢竟，如果錯誤發(fā)生，事務將被回滾，事務狀態(tài)的改變都將被復位。但事實上事務的邊界可能不包括所有的遠程方法調(diào)用過程。如果事務已經(jīng)在服務器上提交了而返回給客戶端時網(wǎng)絡崩潰怎么辦呢？客戶端不知道服務器的事務是否是成功了。在一些應用程序中，將所有的方法都做成等冪的是不可能的。這樣，你只能通過失效轉(zhuǎn)移減少錯誤，而不是避免它們。拿在線商店為例，假設每臺服務器可以同時處理100個在線用戶的請求，當一臺服務器失效了，沒有失效轉(zhuǎn)移的解決方案將丟失100個用戶的會話數(shù)據(jù)并激怒這些用戶。而有失效轉(zhuǎn)移的解決方案中，當失效發(fā)生的時候有20個用戶正在處理請求，這樣20個用戶將被失效激怒。而其他80個用戶正處于思考時間或在兩個方法調(diào)用之間，這些用戶可以透明地獲得失效轉(zhuǎn)移。這樣，你就需做以下的考慮：l激怒20個用戶和激怒100個用戶造成影響的區(qū)別。l采用失效轉(zhuǎn)移和不采用失效轉(zhuǎn)移產(chǎn)品成本的區(qū)別獨立應用可以透明的遷移到集群結(jié)構(gòu)中——否定盡管一些供應商宣稱他們的J2EE產(chǎn)品有這樣的靈活性。不要相信他們！事實你要在開始系統(tǒng)設計時就要準備集群，而這將影響開發(fā)和測試的所有階段。HttpSession在集群環(huán)境中，如我前面提到的，使用HTTPSession有很多限制，這取決于你的應用程序服務器采用了那種會話失效轉(zhuǎn)移的機制。第一個重要的限制就是所有保存的HTTPSession中的對象必須是可序列化的，這將限制設計和應用程序結(jié)構(gòu)。一些設計模式和MVC框架會用HTTPSession保存一些不序列化的對象（如ServletContext，EJB本地接口和WEB服 務引用），這樣的設計不能在集群中工作。第二，對象的序列的反序列化對性能的影響很大，特別是數(shù)據(jù)庫保存的方式。在這樣的環(huán)境中，應該避免在會話中保存大 的或是眾多的對象。如果你采用了內(nèi)存復制的方式，如前所述你必須小心在會話中屬性的交叉引用。其他在集群環(huán)境中的主要區(qū)別是在會話不管任何屬性修改，你必 須調(diào)用“setAttribute()”方法。這個方法調(diào)用在獨立的系統(tǒng)中是可選的。這個方法的目的是區(qū)別已修改的屬性和那些沒用到屬性，這樣系統(tǒng)可以只為失效轉(zhuǎn)移備份必要的數(shù)據(jù)，從而提高性能。緩存我經(jīng)歷過的大多數(shù)J2EE項目都用了緩存來提高性能，同時流行的應用程序服務器也都提供了不同程度的緩存用來加快應用程序的速度。但這些緩存都是為那些典型的獨立環(huán)境設計的，只能在單JVM實例中工作。我們需要緩存是因為一些對象很“重”，創(chuàng)建它需花費大量的時間和資源。因此我們維護了對象池用于重用這些對象，而不需要在后面創(chuàng)建。我們只有當維護緩存比創(chuàng)建對象更廉價時才能獲得性能的提高。在集群環(huán)境，每個JVM實例都要維護一份緩存的拷貝，這些拷貝必須同步以維持所有服務器實例狀態(tài)的一致性。有時這種類型的同步會比沒有緩存帶來更糟的性能。Static變量當我們設計J2EE應用程序時，在架構(gòu)上經(jīng)常會使用一些設計模式。這些如“Singleton”的設計模式會用到靜態(tài)變量來在多對象之間共享狀態(tài)。這種方式在單服務中工作得很好，但在集群環(huán)境將失效。集群中的每個實例都會在它的JVM實 例中維護一份靜態(tài)變量的拷貝，這樣就破壞了模式的機制。一個使用靜態(tài)變量的例子就是用它來保持在線用戶數(shù)。用靜態(tài)變量來保存在線用戶數(shù)是一個很簡單的辦 法，當用戶進入或離開時就增加和減少它。這種方式在單服務器中絕對是好的，但在集群環(huán)境將失效。在集群中更好的方式是將所有狀態(tài)保存到數(shù)據(jù)庫。外部資源盡管J2EE規(guī)范不支持，但為各種目的仍然會用外部I/O的操作。例如，一些應用會使用文件系統(tǒng)來保存用戶上傳的文件，或是創(chuàng)建一個動態(tài)配置的XML文件。在集群環(huán)境是沒有辦法來在其他實例之間來復制這些文件的。為了在集群中工作，辦法是用數(shù)據(jù)庫作為外部文件的存放點，另外也可以使用SAN（存儲區(qū)域網(wǎng)，StorageAreaNetwork）作為存放點。特殊服務一 些特殊的服務只在獨立的環(huán)境中才有意義，定時服務就一個很好例子，這種服務可以在一個固定的間隔時間有規(guī)律的觸發(fā)。定時服務常用于執(zhí)行一些自動化管理任 務。如日志文件滾動，系統(tǒng)數(shù)據(jù)備份，數(shù)據(jù)庫一致性檢查和冗余數(shù)據(jù)清理等。一些基于事件的服務也很難被遷移到集群環(huán)境中。初始化服務就是個好例子，它只在整 個系統(tǒng)啟動時才發(fā)生。郵件通知服務也一樣，它在一些警告條件下觸發(fā)。這些服務是被事件而不是被請求觸發(fā)的，而且只被執(zhí)行一次。這些服務使得負載均衡和失效轉(zhuǎn)移在集群中沒多少意義。一些產(chǎn)品準備了這些服務，如Jboss使用了“集群單例設施”來協(xié)調(diào)所有實例，保證執(zhí)行這些服務一次且僅有一次?；谀闼x擇的平臺，一些特殊的服務可能會是把你的應用遷移到集群結(jié)構(gòu)中的障礙。分布式結(jié)構(gòu)比并置結(jié)構(gòu)更靈活——不一定J2EE技術(shù)，尤其是EJB，天生就是用來做分布式計算。解耦業(yè)務功能，重用遠程組件，這些使得多層應用非常流行。但是我們不能將所有的東西都分布。一些J2EE架構(gòu)師認為Web層與EJB層并置得越近越好。這些計論后面會繼續(xù)。先讓我解釋一下。圖20分布式結(jié)構(gòu)如圖20所示，這是一個分布式結(jié)構(gòu)。當請求來了，負載均衡器將請求分發(fā)到不同服務器中的不同WEB容器，如果請求包含了EJB調(diào)用，WEB容器將重發(fā)EJB調(diào)用到不同的EJB容器。這樣，請求將被負載均衡和失效轉(zhuǎn)移兩次。一些人看分布式結(jié)構(gòu)，他們會指出：l第二次負載均衡沒有必要，因為它不會使任務分配更平坦。每個服務器實例都有它們自己的WEB容器和EJB容器。把EJB容器用來處理來自其他實例WEB容器的請求比只在服務器內(nèi)部調(diào)用并沒有什么優(yōu)勢。l第二次失效轉(zhuǎn)移沒有必要，因為它不能是高可用性。多數(shù)供應商實現(xiàn)J2EE服務器都會在同一服務器中運行的WEB容器和EJB容器放在一個JVM實例中。如果EJB容器失效了，多數(shù)情況下在同一個JVM中的WEB容器也將同時失效。l性能將下降。想像一下對你的應用的一次調(diào)用包含一組對EJB的調(diào)用，如果你負載均衡了這些EJB，這將跨越每個服務器實例，導致許多不必要的服務器到服務器的交互。還有，如果這個方法在事務范圍內(nèi)，那么事務邊界將包含許多服務器實例，這將嚴重影響性能。實際上在運行期，多數(shù)的供應商（包括SunJES，WebLogic和Jboss）都會優(yōu)化EJB調(diào)用機制，使請求首先選擇同一個服務器中的EJB容器。這樣，如圖21所示，我們只在第一層（WEB層）做負載均衡，然后調(diào)用相同服務器上的服務。這種結(jié)構(gòu)我們稱之為并置結(jié)構(gòu)。技術(shù)上說，并置結(jié)構(gòu)是分布式結(jié)構(gòu)的一種特例。圖21并置結(jié)構(gòu)一個有趣的問題是，既然多數(shù)的部署在運行期都演進成了并置結(jié)構(gòu)，為什么不用本地接口代替遠程接口，這將大提高性能。你當然可以，但是記住，當你使用本地接口后，WEB組件和EJB耦合得很緊，而方法調(diào)用也是直接的而不通過RMI/IIOP。負載均衡和失效轉(zhuǎn)移分發(fā)器沒有機會介入本地接口調(diào)用。“WEB+EJB”整體處理負載均衡和失效轉(zhuǎn)移。但不幸的是，在集群中使用本地接口在多數(shù)J2EE服務器中有局限性。使用本地接口的EJB是本地對象，是不可序列化的，這一個限制就使本地引用不能保存在HTTPSession中。一些產(chǎn)品，如SunJES，會將本地接口區(qū)別看待，使它們可以序列化。這樣就可以用在HTTPSession中。另一個有趣的問題是，既然并置結(jié)構(gòu)這么流行并且有好的性能，為什么還要分布式結(jié)構(gòu)呢？這在多數(shù)情況下是有道理的，但有時分布式結(jié)構(gòu)是不可替代的。lEJB不僅被WEB容器使用，富客戶端也會使用它。lEJB組件和WEB組件需在不同的安全級別上，并需要物理分離。這樣防火墻將被設置用于保護運行EJB的重要機器。lWEB層和EJB層極端不對稱使得分布式結(jié)構(gòu)是更好的選擇。比如，一些EJB組件非常復雜并且很消耗資源，它們只能運行在昂貴的大型服務器上，另一方面，WEB組件（HTML，JSP和Servlet）簡單得只需廉價的PC服務器就能滿足要求。在這種情況下，專門的WEB服務器可以用來接受客戶端連接請求，很快處理靜態(tài)數(shù)據(jù)（HTML和圖像）和簡單的WEB組件（JSP和Servlet）。大型服務器只被用來做復雜計算。這將更好的利用投資。結(jié)論集群與獨立環(huán)境不同，J2EE供應商采用不同的方法來實現(xiàn)集群。如果你的項目為做到高伸縮性而使用集群，你應該在你的項目開始的時候就做準備。選擇符合你的需求的正確的J2EE產(chǎn)品。選擇正確的第三方軟件和框架并確保它們能支持集群。最后設計正確的架構(gòu)使得能從集群中受益而不是受害。