分布式架構不是銀彈：何時選擇、何時放棄？

J2EE 提供優異的分布式支援，但「分布式＝高可用/可擴展」是危險的迷思。本文理性剖析分布式架構的三大收益（共享業務層、負載均衡部署、故障隔離）與三大代價（效能損耗、複雜度爆炸、OO 設計受限），並給出決策判斷框架。

分布式的真實收益

1. 多客戶端共享業務層：適用於豐富客戶端（Swing/RCP）場景，Web 應用本身已有中間層，此項收益不適用
2. 組件級部署靈活性：Web 層輕量、EJB 層計算密集時，可分離部署至不同物理機，通過增加計算節點破解瓶頸
3. 故障域隔離：單節點故障不波及全系統

不可忽視的代價

1. 效能懸殊：遠程呼叫比本地慢數量級（序列化、網路、反序列化）
2. 複雜度指數級上升：開發、除錯、部署、監控、事務傳播、異常處理全鏈路加難
3. OO 設計受損：遠程介面需粗粒度、傳值而非傳引用、無法透明使用多態、繼承等核心特性

決策判斷框架

若無明確的「多物理節點承載」或「異構客戶端共享」剛需，優先選擇單 JVM 部署。將所有組件佈署在同一伺服器，利用叢集實現高可用，避免不必要的遠程呼叫開銷。分布式是手段而非目的。

現實觀察

多數採用遠程介面的 J2EE 專案，最終仍佈署於單一伺服器，白白承擔了分布式複雜度卻未享受任何紅利。架構選型務必回歸業務實際。