愛恨交織的 OSGi：Spring DM 救得了啟動複雜度，救不了 ClassLoader 地獄

有人稱 OSGi 是「Spring 之後的下一個 Big Thing」，但深度使用數年後，作者對其產生愛恨交織的複雜情感：肯定其高模組化、微服務架構優勢，卻痛恨其將技術複雜度推向新高度。本文從實戰角度剖析 OSGi 的優勢陷阱，並對比 EJB 歷史，反思模組化標準化的代價。

讓人著迷的優勢：真正的模組邊界與生命週期

• Bundle = 微應用：擁有獨立 ClassLoader、生命週期（START/STOP/UPDATE）、服務註冊發現，實現運行時真正隔離與熱插拔。
• 版本化依賴宣告：MANIFEST.MF 中 Import-Package/Export-Package 帶版本區間，將架構約束前置至構建期，強制模組化設計。
• 服務導向：介面與實現分離，動態綁定，支援多版本共存。

讓人抓狂的痛點

1. 生命週期管理的樣板化代碼地獄

手寫 BundleActivator 追蹤服務、狀態機管理依賴順序，代碼冗長易錯。Spring DM（現 Spring Dynamic Modules） 以聲明式 XML/@Bean 大幅簡化：容器自動掃描、註冊、注入 OSGi 服務，讓開發者專注業務邏輯。作者直言：「沒有 Spring DM 絕不碰 OSGi 專案。」

2. ClassLoader 隔離帶來的「測試通過、部署炸裂」

• 每個 Bundle 專屬 ClassLoader，改變類可見性規則：單例類在不同 Bundle 被多次載入、靜態字段不共享、第三方庫（如 Log4j、JDBC 驅動）若未正確導出包，導致 ClassNotFoundException/LinkageError。
• 單元測試跑在扁平 Classpath，與 OSGi 運行時行為差異巨大，缺乏強大的自動化整合測試組件，無法持續驗證。

3. 依傳遞性依賴與版本衝突的無盡調適

調整 Import-Package 版本區間、添加 DynamicImport-Package、拆分 Bundle、使用 Fragment Bundle 掛載資源……每次構建都在與清單頭博鬥，樣板化配置蔓延全專案。

4. Spring DM 也有無力時刻

Spring DM 雖屏蔽服務註冊細節，但無法解決 ClassLoader 隔離導致的類衝突、第三方庫非 OSGi 化、資源載入路徑差異等根本問題，開發者仍需深入理解 OSGi 類加載機制才能除錯。

結論：KISS 原則下的理性選擇

在引入 OSGi 前，嚴格驗證：

1. 是否真正需要不停機熱部署/熱更新 Bundle？
2. 若需動態模組，能否將範圍限制在邊緣區域（如插件系統），核心域保持單體？
3. 是否有替代方案：IoC 容器管理模組依賴、獨立進程微服務、java.lang.ModuleLayer (JDK 9+) 輕量隔離？

作者警示：EJB 曾因過度複雜催生 Spring，OSGi 若不克制複雜度、降低認知門檻，恐重蹈覆轍。時間將驗證一切，但當下，「簡單可行」勝過「理論完美」。