Dubbo 系列JDK SPI 原理解析

2023-02-25 06:04:27

正文

上一篇文章講到了如何去找到 Dubbo 原始碼的偵錯入口，如果你跟隨文章思路，那你將要閱讀的第一條主線將是 Dubbo 的服務釋出流程。在閱讀的過程中你會發現，有很多程式碼很相似，並且重複出現，比如這裡：

private static final ProxyFactory PROXY_FACTORY = ExtensionLoader.getExtensionLoader(ProxyFactory.class).getAdaptiveExtension();
private static final Protocol PROTOCOL = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
……
Invoker<?> invoker = PROXY_FACTORY.getInvoker(ref, (Class) interfaceClass, url);
DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker, this);
Exporter<?> exporter = PROTOCOL.export(wrapperInvoker);
exporters.add(exporter);
……

這段程式碼是 Dubbo 服務釋出的關鍵流程，其中用到了兩個類都是通過ExtensionLoader.getExtensionLoader()去獲得的，這其實體現的就是Dubbo 的SPI機制，SPI 機制在 Dubbo 中被大量運用，也是 Dubbo 設計的亮點所在。

為什麼要使用SPI？

這就要談到Dubbo的架構設計了，之前提到 Dubbo 採用的是分層架構的方式，Dubbo 的設計體現了程式設計中的開閉原則，每一層都可以被另一種實現技術替換掉，而不影響上下層之間的依賴和整體邏輯的運轉，這其實就是微核心架構（微核心+外掛）。

微核心架構也被稱為外掛化架構（Plug-in Architecture），這是一種面向功能進行拆分的可延伸性架構。核心功能是比較穩定的，只負責管理外掛的生命週期，不會因為系統功能的擴充套件而不斷進行修改。功能上的擴充套件全部封裝到外掛之中，外掛模組是獨立存在的模組，包含特定的功能，全部可被替換，並且可以拓展核心系統的功能，而 Dubbo 最終決定採用 SPI 機制來載入外掛。

開閉原則 OCP (Open-Closed Principle )：程式的設計應該是不約束擴充套件，即擴充套件開放，但又不能修改已有功能，即修改關閉。

什麼是 SPI

SPI ，全稱為 Service Provider Interface，直接翻譯過來是服務提供者介面，是一種服務發現機制，而我們通常指的是JDK的SPI。

JDK SPI，它是JDK內建的一種服務發現機制，可以動態的發現服務，即服務提供商，它通過在ClassPath路徑下的META-INF/services資料夾查詢檔案，自動載入檔案裡所定義的類。

根據他的定義就知道他主要是被框架開發人員使用的，通過 SPI 可以載入服務本身以外的擴充套件。最常用的比如JDBC驅動連線時候選擇不同的驅動，對java.sql.Driver的實現就利用了SPI機制；Spring框架中也使用了很多，比如在 Spring 中為了支援Servlet3.0規範不使用web.xml，對javax.servlet.ServletContainerInitializer的實現也利用了SPI；在Dubbo中更是大量運用了SPI機制，不但有JDK SPI的運用，更重要的是 Dubbo 自己還實現了一套SPI機制。

JDK SPI 機制

當服務提供者想利用SPI機制去擴充套件，需要遵循以下步驟。

首先需要實現實現對應介面。
然後需要在 Classpath 下的 META-INF/services/ 目錄中建立一個以服務介面全路徑命命名的檔案。
在該檔案中記錄服務介面的所有具體實現類，通常是在外部引入的擴充套件包中，比如引入JDBC的jar包。
做好以上設定，就可以利用JDK SPI的查詢機制在META-INF/services/資料夾下根據設定來對具體的實現類載入和範例化。

如果看完上述流程還不是很清楚，請看如下範例。比如這裡有介面 MySPI 需要按照上述流程按照SPI機制載入。

首先提供了兩個實現類 GoodbyeMySPI 和 HelloMySPI，然後在 META-INF/services 資料夾下儲存了檔案org.daley.spi.demo.MySPI，檔案的內容是兩個實現類的全路徑名。就緒之後就可以在main方法中啟動demo，用ServiceLoader.load()載入 MySPI 的兩個實現類，然後分別呼叫介面方法執行。程式碼如下：

/**
 * @author 後端開發技術
 */
public interface MySPI {
    void say();
}
public class HelloMySPI implements MySPI{
    @Override
    public void say() {
        System.out.println("HelloMySPI say:hello");
    }
}
public class GoodbyeMySPI implements MySPI {
    @Override
    public void say() {
        System.out.println("GoodbyeMySPI say:Goodbye");
    }
}
public static void main(String[] args) {
    ServiceLoader<MySPI> serviceLoader = ServiceLoader.load(MySPI.class);
    Iterator<MySPI> iterator = serviceLoader.iterator();
  // 開始迭代執行
    while (iterator.hasNext()) {
        MySPI spi = iterator.next();
        spi.say();
    }
}
//組態檔 org.daley.spi.demo.MySPI
org.daley.spi.demo.GoodbyeMySPI
org.daley.spi.demo.HelloMySPI
//輸出如下：
//GoodbyeMySPI say:Goodbye
//HelloMySPI say:hello

JDK SPI原理

看完上述 demo，你有沒有好奇 JDK SPI 的原理是什麼？相信你已經猜的八九不離十了。我們從demo的main方法開始追蹤起。

很明顯關鍵的程式碼就一行ServiceLoader.load(MySPI.class)，他是整個類載入的入口。

呼叫ServiceLoader.load(MySPI.class)開始載入，並且會拿到當前執行緒的類載入器。
開始建立一個ServiceLoader，最終可以追蹤到呼叫reload()方法

public static <S> ServiceLoader<S> load(Class<S> service) {
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}
public static <S> ServiceLoader<S> load(Class<S> service,
                                            ClassLoader loader)
{
    return new ServiceLoader<>(service, loader);
}
private ServiceLoader(Class<S> svc, ClassLoader cl) {
  // 繫結介面和類載入器
    service = Objects.requireNonNull(svc, "Service interface cannot be null");
    loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
    acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
  // 載入
    reload();
}

在reload()方法中首先清空了providers，它裡面存貯了所有服務介面的實現，key為實現類名，value為物件。然後便會new一個LazyIterator，LazyIterator是ServiceLoader內部實現的一個迭代器，此時還沒有真正開始載入，只是儲存了介面和類載入器在迭代器中。

private LinkedHashMap<String,S> providers = new LinkedHashMap<>();
public void reload() {
    providers.clear();
    lookupIterator = new LazyIterator(service, loader);
}
private class LazyIterator implements Iterator<S>{
  private LazyIterator(Class<S> service, ClassLoader loader) {
        this.service = service;
        this.loader = loader;
  }
}

正如其名懶載入迭代器，在呼叫iterator.hasNext()時才真正發生載入。在hasNextService()方法中，第一次呼叫此方法會先拼接出設定SPI的檔名，在本demo中也就是META-INF/services/org.daley.spi.demo.MySPI，然後會使用類載入器載入組態檔並且將每行的內容設定到迭代器pending中，每次遍歷都可以按行依次拿到實現類的名字。

比如第一次迭代，返回第一行設定的實現類名org.daley.spi.demo.GoodbyeMySPI。到這裡只是載入組態檔拿到類名，還未載入類。

public boolean hasNext() {
    if (acc == null) {
        return hasNextService();
    } else {
      ……
    }
}
// pengding中儲存了組態檔中的實現類名，按行迭代
Iterator<String> pending = null;
private boolean hasNextService() {
      ……
    if (configs == null) {
        try {
          // 設定組態檔路徑 META-INF/services/org.daley.spi.demo.MySPI
            String fullName = PREFIX + service.getName();
            if (loader == null)
                configs = ClassLoader.getSystemResources(fullName);
            else
                configs = loader.getResources(fullName);
        } catch (IOException x) {
            fail(service, "Error locating configuration files", x);
        }
    }
  // 第一次遍歷 pendind=null
    while ((pending == null) || !pending.hasNext()) {
        if (!configs.hasMoreElements()) {
            return false;
        }
        pending = parse(service, configs.nextElement());
    }
  // 按行拿到實現類名
    nextName = pending.next();
    return true;
}

當執行到iterator.next()的時候才會真正去載入class類。追蹤此方法最終進入nextService()方法，在這裡你會看到熟悉的Class.forName()以及newInstance()方法，讀取類和範例化類的邏輯一目瞭然。到這裡JDK SPI的核心邏輯就結束了。

public S next() {
    if (acc == null) {
        return nextService();
    } else {
        ……
    }
}
private S nextService() {
    if (!hasNextService())
        throw new NoSuchElementException();
        //當前正在迭代的實現類名
    String cn = nextName;
    nextName = null;
    Class<?> c = null;
    try {
      // 根據類路徑載入class
        c = Class.forName(cn, false, loader);
    ……
      // 範例化實現類，並且儲存在providers中
        S p = service.cast(c.newInstance());
        providers.put(cn, p);
        return p;
    } catch (Throwable x) {
        fail(service,
             "Provider " + cn + " could not be instantiated",
             x);
    }
    throw new Error();          // This cannot happen
}

簡言之，通過將實現類名儲存在以服務介面命名的組態檔中，放置在META-INF/services，ServiceLoader會在先讀取組態檔中實現類的名字，然後根據呼叫newInstance()方法對其進行範例化。簡化的原理圖如下：

為什麼不直接使用 JDK SPI

既然已經有了 JDP SPI 為什麼還需要 Dubbo SPI呢？

技術的出現通常都是為了解決現有問題，通過之前的 demo，不難發現 JDK SPI 機制就存在以下一些問題：

實現類會被全部遍歷並且範例化，假如我們只需要使用其中的一個實現，這在實現類很多的情況下無疑是對機器資源巨大的浪費，
無法按需獲取實現類，不夠靈活，我們需要遍歷一遍所有實現類才能找到指定實現。

所以 Dubbo SPI 以 JDK SPI 為參考做出了改進設計，進行了效能優化以及功能增強，Dubbo SPI 機制的出現解決了上述問題。由於 Dubbo SPI的知識點太多並且很重要，將專門安排在下一篇文章講解，更多關於Dubbo JDK SPI原理的資料請關注it145.com其它相關文章！