WebLogic 叢集負載平衡機制深度解析

在複雜的企業級應用環境中，單一應用伺服器往往難以承擔所有服務請求，因此企業通常部署多個伺服器實例組成叢集。這種架構不僅易於擴展，更支援負載平衡與失效轉移，使後端伺服器故障對客戶端保持透明。WebLogic 叢集提供多層次的負載平衡策略，針對 Web 應用、JNDI、JMS、EJB 及 JDBC 等不同層面皆有獨特實現機制。

一、HTTP 請求的代理負載平衡

當客戶端透過代理（如 Apache、HttpClusterServlet、IIS）訪問叢集業務頁面時，代理採用輪詢演算法分發請求。對於攜帶 Session 的同一客戶端，WebLogic 採用 Session 親和機制將請求導向主伺服器；若主伺服器不可用，則轉發至其他伺服器。Session 親和支援三種實現方式：

• Cookie 機制：瀏覽器支援 Cookie 時，WebLogic 將 JSESSIONID 寫入 Cookie，代理依此決定分發目標。
• URL 重寫：瀏覽器不支援 Cookie 時，伺服器端透過 response.encodeURL() 將 Session ID 附加於 URL。
• POST 資料傳遞：直接將 Session 資料以 POST 方式提交至代理端。

以 HttpClusterServlet 為例，其核心邏輯維護一個受管伺服器列表，每次分發請求後索引遞增，實現基本輪詢：

public synchronized Server next() {
    if (list.size() == 0) return null;
    if (index == -1) index = (int)(Math.random() * list.size());
    else index = ++index % list.size();
    Object[] servers = list.values().toArray();
    return (Server) servers[index];
}

二、InitialContext 的負載平衡

獲取 JDBC、JMS 連線或 EJB Stub 等 RMI 物件時需初始化 InitialContext。若 Provider URL 指定多個伺服器（如 t3://localhost:7011,localhost:7021），客戶端建立 Context 時會依輪演算法分散連線至不同 Managed Server。值得注意的是：

• 同一 JVM 內對同一伺服器的連線為長連線，重複建立 Context 不會產生新連線。
• 此負載平衡僅在建立 Context 時生效，後續操作具有 Server Affinity 特性，即同一 Context 的所有操作均在建立連線的伺服器完成。
• 若後端伺服器故障，Context 不會自動恢復連線至修復的伺服器，除非當前連線伺服器也發生故障。

三、JMS 分散式佇列負載平衡

分散式佇列為邏輯佇列，管理分佈於不同 JMS Server 的實體佇列。其負載平衡由連線工廠與佇列配置共同決定：

• Load Balancing Enabled：啟用時每次 send() 皆負載平衡；停用時僅首次平衡。
• Server Affinity Enabled：優先在同一伺服器實例的實體目的地間平衡。
• Load Balancing Policy：支援 Round-Robin（預設）與 Random，可配合權重調整分發比例。

JMS Connection 建立時採輪詢分散至不同 Managed Server，建立後 Producer/Consumer 固定於該連線對應伺服器，訊息分發再由上述參數控制。

四、EJB 負載平衡

EJB 負載平衡涉及三個層面：

1. InitialContext：同上節所述。
2. EJB Home：透過 home-load-algorithm 配置（round-robin、random、weight-based 及其 Affinity 變體），控制 create() 分發邏輯。
3. EJB Object：僅無狀態 Session Bean 支援，配置 stateless-bean-load-algorithm。有狀態 Bean 與 Entity Bean 因狀態同步開銷大，不支援負載平衡。

五、JDBC 多重連線池

配置 Multi Pool 作為邏輯池管理多個實體池，演算法分為 HA（僅故障轉移）與 Load Balance（平時負載平衡、故障時轉移）兩種模式。