J2EE 規範定義了 EAR 打包標準，但未規定部署拓撲：是「一服務器一應用」還是「一服務器多應用」？IBM WebSphere 兩種模式均支持。本文從性能、可伸縮性、運維控制、故障轉移、安全性五個維度深度剖析，給出決策框架。
一、 性能對比：共享 JVM 通常更優
進程越少 → 內存交換/上下文切換越少 → 更多資源用於業務處理。
實測數據 (2GB RAM, 2 CPU, HP-UX, WebSphere 4.03, iPlanet 6.01)
| 場景 | 應用 A 吞吐 (req/s) | 應用 B 吞吐 (req/s) |
|---|
| 兩獨立服務器 (各 50% CPU) | 31.15 | 48.86 |
| 單服務器雙應用 (50% CPU) | 36.97 (+18.7%) | 53.57 (+9.6%) |
| 兩獨立服務器 (各 85% CPU) | 38.22 | 57.66 |
| 單服務器雙應用 (85% CPU) | 45.02 (+17.8%) | 64.58 (+12.0%) |
圖 1. 單服務器部署多應用性能顯著優於多服務器
結論：大規模環境 (數十應用) 合併部署可顯著節省內存/CPU 開銷。但必須實測確認無資源爭用瓶頸。
二、 性能測試與問題定位策略
- 基線測試：單應用單服務器，消除應用級瓶頸
- 混合測試：所有共享應用並發壓測，驗證無相互干擾
- 工具鏈：WebSphere PMI、Tivoli Performance Viewer、第三方 APM
共享部署出現性能問題時，定位「哪個應用惹的禍」較難，需完善監控體系。
三、 應用可伸縮性限制
- HTTP Session 體積：1MB Session × 1000 用戶 = 1GB 堆壓力。大 Session 應用可能強制獨享 JVM 甚至需多克隆分流
- 其他瓶頸：線程池、數據庫連接池、原生內存等資源競爭可能迫使物理隔離
四、 運維控制權與維護靈活性
| 維度 | 單應用/服務器 | 多應用共享 |
|---|
| 啟停自主權 | 完全獨立 | 需協調，或單獨啟停應用 (WebSphere 支持) |
| 安全補丁/配置變更 | 單獨滾動升級 | 可能需整服務器重啟 (涉及 JVM 級配置) |
| 文件系統權限隔離 | OS 用戶隔離天然安全 | 同 OS 用戶，無法防禦惡意/脆弱應用訪問他方文件 |
| 類加載器可見性 | 無衝突 | 需謹慎選擇 (PARENT_LAST 等)，避免 Singleton 洩漏、版本衝突 |
| 故障隔離 | JVM Crash 僅影響單應用 | 惡意代碼 (無限線程、內存洩漏) 可拖垮全服務器 |
五、 故障轉移與負載管理
WebSphere 通過服務器叢集實現 HA。部署拓撲應與叢集策略對齊：
- 相似 SLA/伸縮需求的應用分組到同一叢集
- 物理機級故障域：生產環境必須跨物理機部署叢集成員 (圖 3)，單機部署無論單/多應用都不是真 HA
圖 2. 單機部署：機器故障導致全業務中斷
圖 3. 生產級跨物理機叢集部署
六、 決策框架：何時選哪種？
傾向「一服務器一應用」的場景
- 任務關鍵型、大型應用 (核心交易、ERP)
- 極高安全/合規要求 (數據隔離、獨立認證)
- 應用自身需特定 JVM 參數/類路徑/原生庫
- 團隊獨立交付、獨立運維、獨立擴容
- 存在已知資源洩漏/不穩定風險的老舊應用
傾向「多應用共享」的場景
- 中小型、非核心應用 (報表、門戶、內部工具)
- 相關緊密的應用套件 (如 HR 全家桶，共享後端、數據模型)
- 資源受限環境 (數十應用、有限物理機)
- 團隊統一運維、統一發布窗口、統一技術棧
- Siebel 等套件原生設計為共享 JVM
七、 總結
「多應用共享 JVM」在性能、資源利用率上通常勝出，但以運維靈活性、故障隔離、安全邊界為代價。無銀彈，**決策取決於組織的：應用關鍵性、安全合規、團隊技能、發布流程成熟度、基礎設施預算**。
建議：核心獨享、邊緣共享、混合部署、持續觀測。定期壓測驗證共享環境無退化，隨業務演進動態調整拓撲。
- 上一篇文章： 深度探索 Eclipse JDT ASTParser：從零構建 Java 類、編譯運行、解析遍歷全攻略
- 下一篇文章： J2EE探索者：五步輕鬆掌握JSP自定義標籤開發
Copyright ©
程式碼之家 All Rights Reserved
