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