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

每個節點上的 ClusterPartition MBean 定義的群集拓撲結構（clustering topography）對系統管理者很重要。但是對于大部分的應用程式開發者來說，你可能更關心從客戶應用程式的角度來看的群集架構。JBoss AS 支援兩種群集架構：用戶端攔截器（client-side interceptors）（proxies 或 stubs）和負載平衡系統（load balancers）。

JBoss 應用伺服器提供的大部分遠端服務，包括 JNDI、EJB、RMI 和 JBoss Remoting，都要求用戶端獲得（如，查找和下載下傳）一個 stub（或 proxy）對象。占位對象（stub object）由伺服器生成，它實作服務的商業接口。客戶可對占位對象調用本地方法。這個調用會自動尋找路由，并被伺服器管理的服務對象引用。在群集環境裡，伺服器生成的占位對象也是一個懂得怎樣把調用指引向不同節點的攔截器。占位對象尋找合适的伺服器節點、配置調用參數、解釋調用結果，并把結果傳回給調用程式。

stub interceptors 擁有群集系統的更新資訊。例如，它們知道所有可用網絡節點的 IP 位址，怎樣在節點上分攤負載的算法（請參考下一部分内容），和如果目标節點不可用時對請求進行失效切換（failover）。對于每個服務請求，伺服器節點都用群集裡最新的資訊來更新 stub interceptor。例如，如果一個節點退出群集系統後，每個客戶 stub interceptor 在下一次連接配接活動的節點時，都會用新的配置來更新。在 service stub 上的所有操作對于客戶應用程式都是透明的。

如圖1.2, “叢集中的用戶端攔截(代理)體系結構” 裡說明了用戶端攔截器群集架構。

圖 1.2. 叢集中的用戶端攔截 (代理) 體系結構

其他的 JBoss 服務，特别是 HTTP web 服務，不要求客戶下載下傳任何東西。用戶端（如，web 浏覽器）按照某種通信協定（如 HTTP 協定）直接發送請求和接收回複。在這種情況下，負載平衡系統需要處理所有的請求并把它們配置設定給群集裡的伺服器節點。負載平衡系統是群集裡的一個典型概念。它了解群集配置和失效切換政策（failover policies）。客戶隻需要知道它的存在。如圖 1.3, “叢集的負載均衡體系” 說明了負載平衡系統的群集架構。

圖 1.3. 叢集的負載均衡體系

負載平衡本身就是一個單點故障，這對于負載均衡是一個潛在的問題。它需要受到密切的監控，以確定高可用性的叢集服務。

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