最近新寫了一個中間件「運行時動態(tài)日志等級開關」，其中使用Java SPI機制實現(xiàn)了自定義配置中心，保證良好的擴展性。

項目地址，走過路過可以點個star ：）
https://github.com/saigu/LogLevelSwitch

在使用過程中，突然發(fā)現(xiàn)SPI其實和日常寫API接口，然后進行implements實現(xiàn)非常相似，那SPI到底和普通API實現(xiàn)有啥區(qū)別呢？帶著這個問題，我們一起來梳理下SPI機制吧。

本文預計閱讀時間10分鐘，將圍繞以下幾點展開：

• 什么是 SPI 機制？

• SPI 實踐案例

• SPI 和 API 有啥區(qū)別？

1、什么是SPI機制？

SPI（Service Provider Interface） 字面意思是服務提供者接口，本質上是一種「服務擴展機制」。

為什么需要這樣一種「服務擴展機制」呢？

因為系統(tǒng)里抽象的各個模塊，比如日志模塊、xml解析模塊、jdbc模塊等，往往有很多不同的實現(xiàn)方案。

為了滿足可拔插的原則，我們一般推薦模塊之間基于接口編程，模塊之間不對實現(xiàn)類進行硬編碼。這就需要一種「服務擴展機制」，然后就有了SPI。

SPI 機制為我們的程序提供拓展功能。而不必將框架的一些實現(xiàn)類寫死在代碼里面。我們在相應配置文件中定義好某個接口的實現(xiàn)類全限定名，并由服務加載器讀取配置文件，加載實現(xiàn)類。這樣可以在運行時，動態(tài)為接口替換實現(xiàn)類。

最常見的就是Java的SPI機制，另外，還有Dubbo和SpringBoot自定義的SPI機制。

2、SPI實踐案例

2.1?業(yè)界SPI實踐案例

簡單了解了SPI的概念，我們看看業(yè)界有哪些SPI實踐案例，如何利用SPI實現(xiàn)靈活擴展的。

• JDBC驅動加載

最常見的SPI機制實踐案例就是JDBC的驅動加載。利用Java的SPI機制，我們可以根據(jù)不同的數(shù)據(jù)庫廠商來引入不同的JDBC驅動包。

• SpringBoot的SPI機制

用過SpringBoot的同學應該都知道，我們可以在spring.factories中加上我們自定義的自動配置類，這個特性尤其在xxx-starter中應用廣泛。

• Dubbo的SPI機制

Dubbo基本上自身的每個功能點都提供了擴展點，把SPI機制應用的淋漓盡致，比如提供了集群擴展、路由擴展和負載均衡擴展等差不多接近30個擴展點。
如果Dubbo的某個內置實現(xiàn)不符合我們的需求，那么我們只要利用其SPI機制將我們的實現(xiàn)替換掉Dubbo的實現(xiàn)即可。

2.2?在實際項目中如何使用

以上三個例子是業(yè)界最常見的SPI機制的實現(xiàn)。下面，來看看我在實際項目中如何利用Java SPI機制實現(xiàn)了自定義配置中心，保證良好的擴展性。

項目地址，走過路過可以點個star ：）
https://github.com/saigu/LogLevelSwitch

需求很簡單，中間件「運行時動態(tài)日志等級開關」需要在應用運行時獲取開關狀態(tài)，然后動態(tài)改變應用日志等級。

如何獲取開關狀態(tài)呢？我們一般需要配置中心來進行處理。作為一個開源中間件，使用它的應用可能有自己的不同的配置中心（比如Nacos、Apollo、spring cloud config、自研配置中心等），因此，必須支持自定義配置中心接入。

這時候就需要SPI機制來實現(xiàn)了！

1）定義接口interface

package io.github.saigu.log.level.sw.listener;
public interface ConfigListener<T> {    /**     * 獲取初始開關狀態(tài)     * @return initial context of switch     */    SwitchContext getInitSwitch();
    /**     * 獲取變化的配置     * @param changedConfig changed config context     */    void listenChangedConfig(T changedConfig);}

2）SPI加載

本項目通過Java SPI實現(xiàn)，不需要依賴額外的組件，通過ServiceLoader來動態(tài)加載

public class ChangeListenerFactory {    public static ConfigListener getListener() {        final ServiceLoader loader = ServiceLoader.load(ConfigListener.class);        for (ConfigListener configListener : loader) {            return configListener;        }        throw new IllegalArgumentException("please choose valid listener");    }}

3）應用自定義配置中心接入

使用這個中間件的應用，只需要三步即可接入自定義配置中心。

• STEP 1: 應用中pom引入依賴

  io.github.saigu
  log-switch-core
  1.0.0-beta

• STEP 2: 構建config Bean

@Configurationpublic class LogLevelSwitchConfig {    @Bean    LogLevelSwitch logLevelSwitch() {        return new LogLevelSwitch();    }}

• STEP 3: 接入配置中心

聲明配置中心的SPI實現(xiàn)。

在resource路徑下新建?META-INF/services，創(chuàng)建文件名為

io.github.saigu.log.level.sw.listener.ConfigListener的文件，并寫入自定義配置中心的「實現(xiàn)類名」。

3、SPI和API有啥區(qū)別？

我們已經介紹了什么是SPI，怎么使用SPI機制，現(xiàn)在，回頭來看看一開始提出的問題，SPI和API有啥區(qū)別呢？

它們都需要定義接口interface，然后自定義實現(xiàn)類implements，看起來基本一致呀。

區(qū)別在哪？各自的使用場景是啥？

別急，我們從頭梳理一下。

從「面向接口編程」的思想來看，「調用方」應該通過調用「接口」而不是「具體實現(xiàn)」來處理邏輯。那么，對于「接口」的定義，應該在「調用方」還是「實現(xiàn)方」呢？

理論上來說，會有三種選擇：

• 「接口」定義在「實現(xiàn)方」

• 「接口」定義在「調用方」

• 「接口」定義在 獨立的包中

1)「接口」定義在「實現(xiàn)方」

先來看看「接口」定義在「實現(xiàn)方」的情況。這個很容易理解，實現(xiàn)方同時提供了「接口」和「實現(xiàn)類」，「調用方」可以引用接口來達到調用某實現(xiàn)類的功能，這就是我們日常使用的API。API的最顯著特征就是：

實現(xiàn)和接口在一個包中。自己定義接口，自己實現(xiàn)類。

2)「接口」定義在「調用方」

再來看看「接口」屬于「調用方」的情況。這個其實就是SPI機制。以JDBC驅動為例，「調用方」（用戶或者說JDK)定義了java.sql.Driver接口，這個接口位于「調用方」JDK的包中，各個數(shù)據(jù)庫廠商實現(xiàn)了這個接口，比如mysql驅動com.mysql.jdbc.Driver。因此，SPI最顯著的特征就是：

「接口」在「調用方」的包，「調用方」定義規(guī)則，而自定義實現(xiàn)類在「實現(xiàn)方」的包，然后把實現(xiàn)類加載到「調用方」中。

3)「接口」定義在獨立的包

最后一種情況，如果一個「接口」在一個上下文是API，在另一個上下文是SPI，那么就可以把「接口」定義在獨立的包中。

4、小結

本文介紹了什么是SPI機制，然后結合業(yè)界案例與項目實踐來說明SPI的使用場景，最后對Java SPI和API的區(qū)別進行了分析。

本文不對SPI原理進行深入解析，下一篇文章會詳細分析下Java SPI的實現(xiàn)《大名鼎鼎的Java SPI機制，究竟有沒有破壞雙親委派呢？》，應該會挺有意思，歡迎關注。

往期熱門筆記合集推薦：

• HBase原理與實戰(zhàn)筆記合集

• MySQL實戰(zhàn)筆記合集

• Canal/Otter源碼與實戰(zhàn)筆記合集

• Java實戰(zhàn)技巧筆記合集

原創(chuàng)：阿丸筆記（微信公眾號：aone_note），歡迎?分享，轉載請保留出處。

沒有留言功能的悲傷，掃描下方二維碼「加我」聊些有的沒的吧～