1.1.2 服務架構
每個節點上的 ClusterPartition MBean 定義的群集拓撲結構（clustering topography）對系統管理員很重要。但是對于大部分的應用程序開發者來說，你可能更關心從客戶應用程序的角度來看的群集架構。JBoss AS 支持兩種群集架構：客戶端攔截器（client-side interceptors）（proxies 或 stubs）和負載平衡系統（load balancers）。
1.1.2.1 客戶端攔截器
JBoss 應用服務器提供的大部分遠程服務，包括 JNDI、EJB、RMI 和 JBoss Remoting，都要求客戶端獲得（如，查找和下載）一個 stub（或 proxy）對象。占位對象（stub object）由服務器生成，它實現服務的商業接口?？蛻艨蓪φ嘉粚ο笳{用本地方法。這個調用會自動尋找路由，并被服務器管理的服務對象引用。在群集環境里，服務器生成的占位對象也是一個懂得怎樣把調用指引向不同節點的攔截器。占位對象尋找合適的服務器節點、配置調用參數、解釋調用結果，并把結果返回給調用程序。
stub interceptors 擁有群集系統的更新信息。例如，它們知道所有可用網絡節點的 IP 地址，怎樣在節點上分攤負載的算法（請參考下一部分內容），和如果目標節點不可用時對請求進行失效切換（failover）。對于每個服務請求，服務器節點都用群集里最新的信息來更新 stub interceptor。例如，如果一個節點退出群集系統后，每個客戶 stub interceptor 在下一次連接活動的節點時，都會用新的配置來更新。在 service stub 上的所有操作對于客戶應用程序都是透明的。
如圖1.2, “集群中的客戶端攔截(代理)體系結構” 里說明了客戶端攔截器群集架構。
圖 1.2. 集群中的客戶端攔截 (代理) 體系結構
1.1.2.2負載平衡系統
其他的 JBoss 服務，特別是 HTTP web 服務，不要求客戶下載任何東西?？蛻舳耍ㄈ纾瑆eb 瀏覽器）按照某種通信協議（如 HTTP 協議）直接發送請求和接收回復。在這種情況下，負載平衡系統需要處理所有的請求并把它們分配給群集里的服務器節點。負載平衡系統是群集里的一個典型概念。它理解群集配置和失效切換策略（failover policies）?？蛻糁恍枰浪拇嬖?。如圖 1.3, “集群的負載均衡體系” 說明了負載平衡系統的群集架構。
http://blog.51cto.com/viewpic.php?refimg=http://xudayu.blog.51cto.com/attachment/200803/200803091205050005890.jpg
圖 1.3. 集群的負載均衡體系
負載平衡本身就是一個單點故障，這對于負載均衡是一個潛在的問題。它需要受到密切的監控，以確保高可用性的集群服務。