八股文背多了，相信大家都聽說過一個詞， SPI擴展 。

有的面試官就很喜歡問這個問題，SpringBoot的自動裝配是如何實現的？

基本上，你一說是基于spring的SPI擴展機制，再把spring.factories文件和EnableAutoConfiguration提一下，那么這個問題就答的八九不離十了。

就像四五年前，我去面試的時候被問到這個問題，SPI動態擴展機制這幾個詞從嘴里一說出來，就把面試官唬的一愣一愣的?？赡芩麄円矝]見過這么能裝逼的，一句話能簡簡單單說明白，非要拽一個聽上去很高大上的詞。

話說回來，被唬住的可不止是面試官，其實還有我自己。至于SPI擴展究竟是個啥，是怎么實現的，我當時也根本不明白。

不過現在的面試就是這樣，對線八股文，要想唬住面試官，就得先唬住自己。

那么我們今天暫且不提spring的SPI擴展，先來看看java本身自帶的SPI擴展機制是怎么一回事。

1、簡介

SPI的全稱是Service Provider Interface，翻譯過來就是 服務提供者的接口 ，它所實現的其實是一種服務的發現機制。

這么說起來可能還是有點不好理解，我舉個例子來類比一下。

在spring項目中，寫service層代碼前，會約定俗成的會添加一個接口層。然后通過spring中的依賴注入，可以借助@Autowired等方式注入這個接口的實現類的實例對象，之后對于service的調用一般也基于接口操作。

簡單形容就是這樣的：

如圖所示，接口、實現類都是由服務提供方提供，我們可以把controller看作服務調用者，調用方只管調用接口就可以了。

雖然也有聲音認為，大部分情況下service只有一個實現類，接口層顯得有些多余。但是在《Head First Design Patterns》這本書中，大佬們還是建議過：

Program to an interface, not an implementation.

沒錯，就是常說的 要面向接口編程 。至于好處，也不外乎是降低耦合度、方便日后擴展、提高了代碼的靈活性和可維護性等等。

在上面這個例子里，這個接口層和其中的方法我們可以稱之為 API ，而我們要討論的SPI和它相比，有類似也有差異，還是先看圖：

簡單來說，就是服務的調用方定義一個接口規范，可以由不同的服務提供者實現。并且，調用方能夠通過某種機制來發現服務提供方，并通過接口調用它的能力。

通過對比，我們可以看出它們雖然都有著接口這一層面，但還是有很大的不同：

API中的接口是服務提供者給服務調用者的一個功能列表，而SPI中更多強調的是，服務調用者對服務實現的一種約束，服務提供者根據這種約束實現的服務，可以被服務調用者發現。

說白了，Java中的SPI實現的就是，你按我的接口規范實現服務，我就能通過某種機制為這個接口尋找到這個服務。

這么說起來可能還有些抽象，下面我們舉一個例子，類比具體描述一下這個過程。

2、定義接口

說起智能家居系統，大家現在都比較熟悉了，只要是相同品牌下的產品，連上wifi就能夠通過手機app控制了，非常方便。

雖然產品不斷更新換代，型號更新層出不窮，但是同種家電在app上操作起來，功能一般都是一樣的。就拿空調來說，我們在app上操作起來一般也就三個主要功能： 開關 ， 選模式 ， 調節溫度 。

假設我現在在客廳、臥室、書房安裝了3款不同型號的空調，并把它們都接入到了我app中，那么之后的操作都是相同的幾個按鍵，簡單粗暴。

思考一下，無論是開關還是調溫，都是通過app去調用設備的接口罷了，那么如果不同型號的空調各寫各的接口，后端app在開發的時候光對接接口都麻煩的要死。

解決方法也很簡單，我先定義一套接口規范，不管你以后什么型號的空調，都按我的規范來實現接口。以后只要我能發現你的設備，那么都可以按相同的方法來調用接口。

那么下面就先來定義這么一套接口規范，如果你以后想要接入智能家居系統，那么就要遵循這個規范來開發接口。

新建一個項目作為標準，就叫aircondition-standard好了，然后創建一個接口。除了3個操作以外，我們再添加一個獲取空調型號的方法。

public interface IAircondition {
    // 獲取型號
    String getType();
    
    // 開關
    void turnOnOff();

    // 調節溫度
    void adjustTemperature(int temperature);

    // 模式變更
    void changeModel(int modelId);
}

這個接口后面要給服務的實現方來使用，用maven把它打成jar包：

mvn clean install

之后服務提供者在項目中就可以引入這個jar包了，有了這套規范，就保證了產品后期不管怎么更新換代，都能接入到系統來。

3、服務實現

制定并發布完規則后，掛式空調作為第一個服務提供者就來了，新建一個項目aircondition-hanging-type，并引入剛才打好的jar包：

<dependency>
    <groupId>com.cn.hydra<span class="hljs-name"groupId>
    <artifactId>aircondition-standard<span class="hljs-name"artifactId>
    <version>1.0-SNAPSHOT<span class="hljs-name"version>
<span class="hljs-name"dependency>

創建服務類，并實現前面定義的接口：

public class HangingTypeAircondition
        implements IAircondition{
    public String getType() {
        return "HangingType";
    }
    
    public void turnOnOff() {
        System.out.println("掛式空調開關");
    }

    public void adjustTemperature(int i) {
        System.out.println("掛式空調調節溫度");
    }

    public void changeModel(int i) {
        System.out.println("掛式空調更換模式");
    }
}

在項目的resources的目錄下，創建META-INF/services目錄，然后以前面定義的接口名com.cn.hydra.IAircondition創建文件，并在文件中寫入實現類的全限定名。

com.cn.hydra.HangingTypeAircondition

整個項目結構非常簡單：

這樣，一個服務方的簡單實現就搞定了，用maven打成jar包，之后就可以提供給調用方使用了。

同理，我們可以再創建一個立式空調的項目aircondition-vertical-type，也只創建一個服務類：

public class VerticalTypeAircondition
        implements IAircondition{
    public String getType() {
        return "VerticalType";
    }
    
    public void turnOnOff() {
        System.out.println("立式空調開關");
    }

    public void adjustTemperature(int i) {
        System.out.println("立式空調調節溫度");
    }

    public void changeModel(int i) {
        System.out.println("立式空調更換模式");
    }
}

還是按上面的命名規則，創建一個配置文件：

com.cn.hydra.VerticalTypeAircondition

同樣，打成jar包就完事了，至于服務調用者如何去發現和調用這兩個服務，下面詳細再說。