架構設計階段的決策深遠影響 J2EE 應用的效能與擴展性。效能不足影響全體使用者,遠比功能缺失嚴重。在「以較少資源完成更多工作」的壓力下,採用組件化與中介軟體服務的 J2EE 是首選,但必須遵循核心架構策略才能真正發揮優勢。
將高頻存取資料保存在記憶體或持久化存儲,避免重複磁碟 I/O 與網路傳輸。典型部署模式:
適用場景:參考資料、組態設定、熱門商品目錄、權限規則等讀多寫少資料。
在多台實體機器建立服務的多份副本,理論上 N 個副本可處理 N 倍請求。透過負載平衡器分散流量,降低單節點負載。關鍵在於:
將大任務拆解為獨立子任務,同時在多執行緒/多 CPU 執行。J2EE 容器本身即為多執行緒環境,善用 ExecutorService、CompletableFuture 或非同步 Servlet (Servlet 3.0+) 可顯著縮短單一請求處理時間。
同步串行流程強迫使用者等待所有步驟完成。非同步模式僅處理關鍵路徑(如驗證、下單),其餘任務(發信、報表產生、第三方通知)放入訊息佇列稍後處理。使用者感知回應即時,系統整體吞吐不變但體驗大幅提升。
建立預先初始化的資源集合(資料庫連線、執行緒、物件實例),請求借用歸還而非逐一建立銷毀。效益評估:
典型池化資源:JDBC 連線池、執行緒池、EJB 實例池、大型物件快取。
實務上需依業務特性組合:
| 策略 | 適用場景 | 代價 |
|---|---|---|
| 快取 | 讀多寫少、資料相對靜態 | 一致性維護、記憶體佔用 |
| 複寫 | 無狀態服務、高並發讀取 | 部署複雜度、會話同步 |
| 平行處理 | CPU 密集型、可拆解任務 | 執行緒管理、共享資源競爭 |
| 非同步 | 長耗時副作業、最終一致性可接受 | 程式複雜度、錯誤處理、監控 |
| 資源池 | 資源建立昂貴、高頻重用 | 池大小調優、洩漏風險 |
高效能 J2EE 架構非單一銀彈,而是上述策略在具體業務約束下的權衡組合。架構師應建立效能基準、持續量測,並在演進中逐步引入適當策略,而非一開始就過度設計。