架構設計原則：SPI 與 API 該如何選擇？
背景
第一次聽說 SPI 是閱讀《軟件框架設計的藝術》，以后陸續在 JDBC 和 SpringBoot 中發現了以這種形式組織代碼的方式，本文給出為什么要區分 SPI 和 API 的一個思考過程。
從面向接口編程說起
圖片
我們在“調用方”和“實現方”之間引入了“接口”，上圖沒有給出“接口”應該位于哪個“包”中，從純粹的可能性上考慮，我們有三種選擇：
- “接口”位于“調用方”所在的“包”中。
- “接口”位于“實現方”所在的“包”中。
- “接口”位于獨立的“包”中。
下面讓我們依次分析這三種可能性，如果現實中確實有這種可能性，不如我們就為其起個名字以方便交流。
“接口”位于“調用方”所在的“包”中
圖片
我們將“倉儲接口”放置于“領域層”這個“包”中，實現放在一個獨立的“包”中，我們看DDD大師的實現都是這樣子，現在來思考一下為什么這么做。
“領域層”的“領域服務”會依賴“倉儲接口”，“倉儲接口”也會依賴“聚合根”，這兩者都是除了“實現依賴”之外的依賴關系，如果將“接口”放到“倉儲實現”中就喪失了面向接口編程的意義（編譯也不會通過），如果放到“獨立層”中呢？會編譯不通過，出現雙向依賴了。
對于類似這種情況下接口，我們將其稱為“SPI”，全稱為：service provider interface，“SPI”的規則如下：
- 概念上更依賴調用方。
- 組織上位于調用方所在的包中。
- 實現位于獨立的包中。
- 常見的例子是：插件模式的插件。
“接口”位于“實現方”所在的“包”中
對于類似這種情況下的接口，我們將其稱作為“API”，“API”的規則如下：
- 概念上更接近實現方。
- 組織上位于實現方所在的包中。
- 實現和接口在一個包中。
“接口”位于獨立的“包”中
需要注意的事項
SPI 和 API 也不一定是接口，我這里都是指狹義的具體的接口。
場景圖
圖片
每一次思考都伴隨著收獲，也離不開和朋友們的交流，天更藍了。
SPI 接口
- 定義：SPI 是一種服務提供者接口，它允許在運行時加載不同的服務實現。
- 使用場景：
模塊化設計：當系統需要高度模塊化，且希望將核心功能與具體實現分離時。
可插拔架構：需要支持多種服務實現，并且可以在不修改代碼的情況下替換或增加新的服務實現。
服務發現：在運行時根據配置或服務注冊表動態發現和加載服務。
微服務架構：在微服務架構中，SPI 可用于服務間的動態交互和集成。
- 優點：
- 提供了一種機制來在運行時選擇和加載服務實現，增加了系統的靈活性和可擴展性。
- 支持服務的熱插拔，無需重啟系統即可更換服務實現。
API 接口
- 定義：API 是一組預定義的函數、協議和工具，用于構建軟件應用，它定義了軟件組件之間交互的契約。
- 使用場景：
客戶端和服務器交互：當需要設計客戶端和服務器之間的通信協議時。
庫和框架：提供給開發者使用的庫或框架的公共接口。
第三方集成：需要與第三方系統或服務進行集成。
內部組件通信：在大型系統中，不同組件或模塊之間的交互。
- 優點：
- 為開發者提供了清晰的接口文檔和規范，易于理解和使用。
- 有助于保持系統的穩定性，因為 API 變更需要遵循版本控制和兼容性規則。
- 促進了代碼的重用和模塊化。
如何選擇？
選擇使用 SPI 還是 API 的考慮因素：
- 擴展性：如果需要在不修改代碼的情況下擴展功能，SPI 更合適。
- 交互性：API 更適合定義系統內部或系統之間的穩定交互接口。
- 動態性：SPI 允許在運行時動態發現和加載服務，而 API 通常在編譯時就已經確定。
- 安全性和穩定性：API 由于其穩定性和可預測性，通常更受青睞。SPI 雖然靈活，但可能引入運行時錯誤。
- 版本控制和兼容性：API 變更需要考慮版本控制和向后兼容性，而 SPI 可以通過服務版本協商來處理兼容性問題。
架構是“取舍”，而非“銀彈”。
