JBoss企業級應用服務平台群集指南(三)

JBoss 用戶端攔截器（stub）和負載平衡系統都使用了負載平衡政策來決定把新請求發送給哪個節點。讓我們來看看 JBoss AS 裡的負載平衡政策。

在JBoss 3.0.x中, 有以下兩種負載均衡選項。

u  Round-Robin (org.jboss.ha.framework.interfaces.RoundRobin): 每次調用都分派給新節點。第一個目标節點從清單裡随機選擇。

u  First Available (org.jboss.ha.framework.interfaces.FirstAvailable): 選擇其中一個可用目标節點作為主目标節點，用于每次調用：這個節點是在群集裡的節點清單裡随機選取的。當目标節點的清單改變時（因為有節點啟動或退出），除非目前選用的節點仍然可用，這個政策會重新選擇一個目标節點。每個用戶端攔截器或者負載平衡系統都會根據自己的政策獨立地選擇目标節點。

在 JBoss 3.2+ 裡，有三個負載平衡政策可用。其中 Round-Robin 和 First Available 選項和 JBoss AS 3.0.x 裡的一樣。

JBoss 3.2 裡的新的負載平衡選項是 "First AvailableIdenticalAllProxies" (org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies)。它與 "First Available" 有相同的行為，但選取的目标節點由所有同一 "family" 的用戶端攔截器共享。

在 JBoss 3.2（或更新的版本）裡定義了 "Proxy Family" 辨別。代理族（Proxy Family）是所有對同一被複制目标調用的 stub interceptors 的集合。拿 EJB 來說，在給定群集裡所有以同一 EJB 為目标的 stubs 屬于同一代理族。給定族裡攔截器共享相同的目标節點的清單。每個攔截器也能夠與同一族裡的其他攔截器共享任何資訊。在圖 3.1, “在 EJB 2.x 中的Stateless Session Bean”裡給出了代理族的一個用例。

把應用程式部署到群集裡最簡單的方法就是使用 farming 服務。那就是在任何群集節點的 all/farm/ 目錄下熱部署（hot-deploy）應用程式檔案檔案（如 EAR，WAR 或 SAR 檔案），而且應用程式自動地在同一群集裡的節點間複制。如果節點後來才加入到群集裡，它會引入群集裡所有用 farm 部署的應用程式并在啟動時把它們部署在本地。如果你從某一正運作的群集節點的 farm/ 檔案夾裡把應用程式删除，這個應用程式将從本地移除并從所有其他群集伺服器節點 farm 檔案夾移走（觸發移除）。對于目前未與群集系統相連的伺服器節點，你應該手工地從 farm 檔案夾裡把應用程式删除。

在 JBoss AS 發行版本裡，Farming 在 all 配置裡是預設被啟用的，是以你不需要自己來設定它。配置檔案放在 deploy/deploy.last 目錄下。如果你想在自定義的配置檔案裡啟用 farming，隻需要建立如下所示的 XML 檔案（farm-service.xml）并把它拷貝到 JBoss 的 $JBOSS_HOME/server/your_own_config/deploy 目錄下。請確定你的自定義配置檔案啟用了群集系統。

在部署了 farm-service.xml 之後，下面所列是配置 farm 所需的 FarmMemberService MBean 屬性。

u  <b>PartitionName</b>指定了部署這個farm的群集的名字。它的預設值是 DefaultPartition。

u  <b>URLs</b>指向部署者（deployer）用來觀察檔案部署的目錄。如果這個目錄不存在，MBean 将建立它。而且，"." 指向配置目錄（也就是：$JBOSS_HOME/server/all/）。

u  <b>ScanPeriod</b>指定了掃描檔案夾變化的時間間隔。它的預設值是 5000。

Farming 服務是 URLDeploymentScanner 的擴充，它掃描 deploy/ 目錄下的熱部署（hot deployment）。是以，你能夠使用 FarmMemberService MBean 裡的 URLDeploymentScanner MBean 定義的所有屬性。實際上，上列 URLs和 ScanPeriod 屬性都是從 URLDeploymentScanner MBean 繼承過來的。

在群集伺服器環境裡，分布式狀态管理（distributed state management）是群集系統必須提供的一個關鍵服務。例如，在 stateful session bean 應用程式裡，會話狀态（session state）必須在所有節點的 bean 執行個體中同步，這可以使客戶應用程式獲得相同的會話狀态，而不用管是哪個節點處理請求。在 entity bean 應用程式裡，bean 對象有時候需要跨群集地緩存來減少資料庫負載。目前，JBoss AS 裡的狀态複制（state replication）和分布式緩存服務（distributed cache service）由兩個途徑提供：HASessionState MBean 和 JBoss Cache framework。

u  HASessionState MBean為 EJB 2.x 的 stateful session beans 和 JBoss 3.x 和 4.x 裡的 HTTP 負載平衡提供會話複制（session replication）和分布式緩存服務（distributed cache service）。all/deploy/cluster-service.xml 檔案裡定義了這個 MBean。我們會在後面的 EJB 2.x stateful session bean 部分展示它的配置選項。

JBoss Cache 是個一個能用在任何應用程式和獨立伺服器環境裡的分布式緩存架構。它逐漸地代替了 HASessionState 服務。JBoss AS 內建了 JBoss Cache 來為 HTTP 會話，EJB 3.0，entity beans 和 Hibernate 持久化對象 （persistence objects）提供緩存服務，每個緩存服務都在不同的 MBean 裡定義。我們将在後面讨論特定服務時介紹這些 MBean。

本文轉自xudayu 51CTO部落格，原文連結：http://blog.51cto.com/xudayu/65486，如需轉載請自行聯系原作者