Dubbo2.7的Dubbo SPI實現原理細節

總結/朱季謙

本文主要記錄我對Dubbo SPI實現原理的理解，至於什麼是SPI，我這裏就不像其他博文一樣詳細地從概念再到Java SPI細細分析了，直接開門見山來分享我對Dubbo SPI的見解。

Dubbo SPI的機制比較類似Spring IOC的getBean()加載，當傳入一個存在的beanName，就可以返回該beanName對應的對象。同理，在Dubbo SPI中，我們同樣傳入一個存在的name，Dubbo框架會自動返回該key對應的對象。不難猜測，Dubbo SPI與Spring IOC在底層應該都有一個大致相似的邏輯，簡單的說，就是兩者都可通過beanName或key值，到框架裏的某個map緩存當中，找到對應的class類名，然後對該class類名進行反射生成對象，初始化完成該對象，最後返回一個完整的對象。然而，在這個過程當中，Spirng相對來說會更復雜，它裏面還有一堆後置處理器......

簡單舉一個例子，大概解釋一下Dubbo SPI實現原理，然後再進一步分析源碼。

首先，我在org.apache.dubbo.test目錄下，定義一個@SPI註解到接口：

package org.apache.dubbo.test;

import org.apache.dubbo.common.extension.SPI;

@SPI("dog")
public interface Animal {
    void haveBehavior();
}

然後，在同一個目錄下，創建兩個實現該接口的類，分別爲Dog，Cat。

Dog——

package org.apache.dubbo.test;

public class Dog implements Animal {

    @Override
    public void haveBehavior() {
        System.out.println("狗會叫");
    }
}

Cat——

package org.apache.dubbo.test;

public class Cat implements Animal {
    @Override
    public void haveBehavior() {
        System.out.println("貓會抓老鼠");
    }
}

注意看，Animal接口的類名爲org.apache.dubbo.test.Animal，接下來，我們在resource目錄的/META_INF/dubbo需新建一個對應到該接口名的File文件，文件名與Animal接口的類名一致：org.apache.dubbo.test.Animal。之所以兩者名字要一致，是因爲這樣只需拿到Animal接口的類名，到resource目錄的/META_INF/dubbo，就可以通過該類名，定位到與Animal接口相對應的文件。

在Dubbo中，文件名org.apache.dubbo.test.Animal的文件裏，其實存了類似Spring bean那種的數據，即id對應bean class的形式——

cat=org.apache.dubbo.test.Cat
dog=org.apache.dubbo.test.Dog

這兩行數據，分別是Animal接口的實現類Cat和Dog的class全限名。

整個的目錄結構是這樣的——

最後寫一個測試類DubboSPITestTest演示一下效果——

package org.apache.dubbo.test;

import org.apache.dubbo.common.extension.ExtensionLoader;
import org.junit.jupiter.api.Test;

class DubboSPITestTest {

    @Test
    public void test(){

        Animal dog = ExtensionLoader.getExtensionLoader(Animal.class).getExtension("dog");
        dog.haveBehavior();

        Animal cat = ExtensionLoader.getExtensionLoader(Animal.class).getExtension("cat");
        cat.haveBehavior();

    }
}

執行結果如下——

先簡單捋一下這個思路是怎麼實現的，ExtensionLoader.getExtensionLoader(Animal.class).getExtension("dog")這行代碼內部，會根據Animal接口完整名org.apache.dubbo.test.Animal找到某個指定目錄下的同名File文件org.apache.dubbo.test.Animal，然後按行循環解析文件裏的內容，以key-value形式加載到某個map緩存裏。

類似這樣操作（當然，源碼裏會更復雜些）——

Map<String,String> map = new HashMap<>();
map.put("cat","org.apache.dubbo.test.Cat");
map.put("dog","org.apache.dubbo.test.Dog");

當然，真實源碼裏，value存的是已根據類名得到的Class，但其實無論是類名還是Class，最後都是可以反射生成對象的，

這時候，就可以根據運行代碼去動態獲取到該接口對應的實現類了。例如，需要使用的是org.apache.dubbo.test.Cat這個實現類，那麼在調用getExtension("cat")方法中，我們傳入的參數是"cat"，就會從剛剛解析文件緩存的map中，根據map.get("cat")拿到對應org.apache.dubbo.test.Cat。既然能拿到類名了，不就可以通過反射的方式生成該類的對象了嗎？當然，生成的對象裏可能還有屬性需要做注入操作，這就是Dubbo IOC的功能，這塊會在源碼分析裏進一步說明。當對象完成初始化後，就會返回生成的對象指向其接口引用Animal dog = ExtensionLoader.getExtensionLoader(Animal.class).getExtension("dog")。

整個過程，就是可根據代碼去動態獲取到某個接口的實現類，方便靈活調用的同時，實現了接口和實現類的解耦。

Dubbo SPI是在Java SPI基礎上做了拓展，Java SPI中與接口同名的文件裏，並不是key- value的形式，純粹是按行來直接存放各實現類的類名，例如這樣子——

org.apache.dubbo.test.Cat
org.apache.dubbo.test.Dog

這就意味着，Java SPI在實現過程中，通過接口名定位讀取到resource中接口同名文件時，是無法做到去選擇性地根據某個key值來選擇某個接口的實現類，它只能全部讀取，再全部循環獲取到對應接口實現類調用相應方法。這就意味着，可能存在一些並非需要調用的實現類，也會被加載並生成對象一同返回來，無法做到按需獲取。

因此，Dubbo在原有基礎上，則補充了Java SPI無法按需通過某個key值去調用指定的接口實現類，例如上面提到的，Dubbo SPI可通過cat這個key，去按需返回對應的org.apache.dubbo.test.Cat類的實現對象。

下面就來分析一下具體實現的原理細節，以下代碼做案例。

Animal cat = ExtensionLoader.getExtensionLoader(Animal.class).getExtension("cat");
cat.haveBehavior();

先來分析ExtensionLoader.getExtensionLoader(Animal.class)方法——

public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
    //判斷傳進來參數是否空
    if (type == null) {
        throw new IllegalArgumentException("Extension type == null");
    }
    //判斷是否爲接口
    if (!type.isInterface()) {
        throw new IllegalArgumentException("Extension type (" + type + ") is not an interface!");
    }
  
    //判斷是否具有@SPI註解
    if (!withExtensionAnnotation(type)) {
        throw new IllegalArgumentException("Extension type (" + type +
                ") is not an extension, because it is NOT annotated with @" + SPI.class.getSimpleName() + "!");
    }

    ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
    if (loader == null) {
        EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type));
        loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
    }
    return loader;
}

在這個方法裏，若傳進來的Class參數爲空或者非接口或者沒有@SPI註解，都會拋出一個IllegalArgumentException異常，說明傳進來的Class必須需要滿足非空，爲接口，同時具有@SPI註解修飾，才能正常往下執行。我們在這裏傳進來的是Animal.class，它滿足了以上三個條件。

@SPI("cat")
public interface Animal {
    void haveBehavior();
}

接下來，在最後這部分代碼裏，主要是創建一個ExtensionLoader對象。

ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
    if (loader == null) {
        EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type));
        loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
    }
return loader;

最後，返回的也是創建的ExtensionLoader對象，該對象包括了兩個東西，一個是type，一個是objectFactory。這兩個東西在後面源碼裏都會用到。

創建完ExtensionLoader對象後，就會開始調用getExtension方法——

Animal cat = ExtensionLoader.getExtensionLoader(Animal.class).getExtension("cat");

進入到getExtension("cat")方法當中，內部會調用另一個重載方法getExtension(name, true)。

public T getExtension(String name) {
    return getExtension(name, true);
}

讓我們來看一下該方法內部實現——

public T getExtension(String name, boolean wrap) {
    if (StringUtils.isEmpty(name)) {
        throw new IllegalArgumentException("Extension name == null");
    }
    if ("true".equals(name)) {
        return getDefaultExtension();
    }
    //step 1
    final Holder<Object> holder = getOrCreateHolder(name);
    Object instance = holder.get();
    
    //step 2
    //雙重檢查
    if (instance == null) {
        synchronized (holder) {
            instance = holder.get();
            if (instance == null) {
                //創建擴展實例
                instance = createExtension(name, wrap);
                //設置實例到holeder中
                holder.set(instance);
            }
        }
    }
    return (T) instance;
}

該方法主要有兩部分。

step 1，先從緩存裏查找name爲“cat”的對象是否存在，即調用getOrCreateHolder(name)，在該方法裏，會去cachedInstances緩存裏查找。cachedInstances是一個定義爲ConcurrentMap<String, Holder