Dubbo源碼解析之SPI（一）：擴展類的載入過程

2020 年 3 月 5 日
筆記

Dubbo是一款開源的、高性能且輕量級的Java RPC框架，它提供了三大核心能力：面向介面的遠程方法調用、智慧容錯和負載均衡，以及服務自動註冊和發現。

Dubbo最早是阿里公司內部的RPC框架，於 2011 年開源，之後迅速成為中國該類開源項目的佼佼者，2018年2月，通過投票正式成為 Apache基金會孵化項目。目前宜信公司內部也有不少項目在使用Dubbo。

本系列文章通過拆解Dubbo源碼，幫助大家了解Dubbo，做到知其然，並且知其所以然。

一、JDK SPI

1.1 什麼是SPI？

SPI(Service Provider Interface)，即服務提供方介面，是JDK內置的一種服務提供機制。在寫程式的時候，一般都推薦面向介面編程，這樣做的好處是：降低了程式的耦合性，有利於程式的擴展。

SPI也秉承這種理念，提供了統一的服務介面，服務提供商可以各自提供自己的具體實現。大家都熟知的JDBC中用的就是基於這種機制來發現驅動提供商，不管是Oracle也好，MySQL也罷，在編寫程式碼時都一樣，只不過引用的jar包不同而已。後來這種理念也被運用於各種架構之中，比如Dubbo、Eleasticsearch。

1.2 JDK SPI的小栗子

SPI 的實現方式是將介面實現類的全限定名配置在文件中，由服務載入器讀取配置文件，載入實現類。

了解了概念後，來看一個具體的例子。

1）定義一個介面

public interface Operation {          int operate(int num1, int num2);  }

2）寫兩個簡單的實現

public class DivisionOperation implements Operation {          public int operate(int num1, int num2) {              System.out.println("run division operation");              return num1/num2;          }  }

3）添加一個配置文件

在ClassPath路徑下添加一個配置文件，文件名字是介面的全限定類名，內容是實現類的全限定類名，多個實現類用換行符分隔。

目錄結構

文件內容

com.api.impl.DivisionOperation  com.api.impl.PlusOperation

4）測試程式

public class JavaSpiTest {      @Test      public void testOperation() throws Exception {          ServiceLoader<Operation> operations = ServiceLoader.load(Operation.class);          operations.forEach(item->System.out.println("result: " + item.operate(2, 2)));      }  }

5）測試結果

run division operation  result:1  run plus operation  result:4

1.3 JDK SPI的源碼分析

例子很簡單，實現的話，可以大膽猜測一下，看名字“ServiceLoader”應該就是用類載入器根據介面的類型加上配置文件里的具體實現名字將實現載入了進來。

接下來通過分析源碼進一步了解其實現原理。

1.3.1 ServiceLoader類

PREFIX定義了載入路徑，reload方法初始化了LazyIterator，LazyIterator是載入的核心，真正實現了載入。載入的模式從名字上就可以看出，是懶載入的模式，只有當真正調用迭代時才會載入。

1.3.2 hasNextService方法

LazyIterator中的hasNextService方法負責載入配置文件和解析具體的實現類名。

1.3.3 nextService方法

LazyIterator中的nextService方法負責用反射載入實現類。

看完了源碼，感覺這個程式碼是有優化空間的，實例化所有實現其實沒啥必要，一來比較耗時，二來浪費資源。Dubbo就沒有使用Java原生的SPI機制，而是對其進行了增強，使其能夠更好地滿足需求。

二、Dubbo SPI

2.1 Dubbo SPI的小栗子

老習慣，在拆解源碼之前，先來個栗子。此處示例是在前文例子的基礎上稍做了些修改。

1）定義一個介面

修改介面，加上了Dubbo的@SPI註解。

@SPI  public interface Operation {          int operate(int num1, int num2);  }

2）寫兩個簡單的實現

沿用之前的兩個實現類。

3）添加一個配置文件

新增配置文件放在dubbo目錄下。

目錄結構

文件內容

division=com.api.impl.DivisionOperation  plus=com.api.impl.PlusOperation

4）測試程式

public class DubboSpiTest {      @Test      public void testOperation() throws Exception {            ExtensionLoader<Operation> loader = ExtensionLoader.getExtensionLoader(Operation.class);            Operation division = loader.getExtension("division");            System.out.println("result: " + division.operate(1, 2));      }  }

5）測試結果

run division operation  result:0

2.2 Dubbo SPI源碼

上面的測試例子也很簡單，和JDK原生的SPI對比來看，Dubbo的SPI可以根據配置的kv值來獲取。在沒有拆解源碼之前，考慮一下如何實現。

我可能會用雙層Map來實現快取：第一層的key為介面的class對象，value為一個map；第二層的key為擴展名(配置文件中的key)，value為實現類的class。實現懶載入的方式，當運行方法的時候創建空map。在真正獲取時先從快取中查找具體實現類的class對象，找得到就直接返回、找不到就根據配置文件載入並快取。

Dubbo又是如何實現的呢？

2.2.1 getExtensionLoader方法

首先來拆解getExtensionLoader方法。

這是一個靜態的工廠方法，要求傳入的類型必須為介面並且有SPI的註解，用map做了個快取，key為介面的class對象，而value是 ExtensionLoader對象。

2.2.2 getExtension方法

再來拆解ExtensionLoader的getExtension方法。

這段程式碼也不複雜，如果傳入的參數為’true’，則返回默認的擴展類實例；否則，從快取中獲取實例，如果有就從快取中獲取，沒有的話就新建。用map做快取，快取了holder對象，而holder對象中存放擴展類。用volatile關鍵字和雙重檢查來應對多執行緒創建問題，這也是單例模式的常用寫法。

2.2.3 createExtension方法

重點分析createExtension方法。

這段程式碼由幾部分組成：

根據傳入的擴展名獲取對應的class。
根據class去快取中獲取實例，如果沒有的話，通過反射創建對象並放入快取。
依賴注入,完成對象實例的初始化。
創建wrapper對象。也就是說，此處返回的對象不一定是具體的實現類，可能是包裝的對象。

第二個沒啥好說的，我們重點來分析一下1、3、4三個部分。

1）getExtensionClasses方法

老套路，從快取獲取，沒有的話創建並加入快取。這裡快取的是一個擴展名和class的關係。這個擴展名就是在配置文件中的key。創建之前，先快取了一下介面的限定名。載入配置文件的路徑是以下這幾個。

2）loadDirectory方法

獲取配置文件路徑，獲取classLoader，並使用loadResource方法做進一步處理。

3）loadResource方法

loadResource載入了配置文件，並解析了配置文件中的內容。loadClass 方法操作了不同的快取。

首先判斷是否有Adaptive註解，有的話快取到cacheAdaptiveClass（快取結構為class）；然後判斷是否wrapperclasses，是的話快取到cacheWrapperClass中(快取結構為Set)；如果以上都不是，這個類就是個普通的類，存儲class和名稱的映射關係到cacheNames里(快取結構為Map)。

基本上getExtensionClasses方法就分析完了，可以看出來，其實並不是很複雜。

2.2.4 IOC

1）injectExtension方法

這個方法實現了依賴注入，即IOC。首先通過反射獲取到實例的方法；然後遍歷，獲取setter方法；接著從objectFactory中獲取依賴對象；最後通過反射調用setter方法注入依賴。

objectFactory的變數類型為AdaptiveExtensionFactory。

2）AdaptiveExtensionFactory

這個類裡面有個ExtensionFactory的列表，用來存儲其他類型的 ExtensionFactory。Dubbo提供了兩種ExtensionFactory，一種是SpiExtensionFactory, 用於創建自適應的擴展；另一種是SpringExtesionFactory,用於從Spring的IOC容器中獲取擴展。配置文件一個在dubbo-common模組，一個在dubbo-config模組。

配置文件

SpiExtensionFactory中的Spi方式前面已經解析過了。

SpringExtesionFactory是從ApplicationContext中獲取對應的實例。先根據名稱查找，找不到的話，再根據類型查找。

依賴注入的部分也拆解完畢，看看這次拆解的最後一部分程式碼。

2.2.5 AOP

創建wrapper對象的部分，wrapper對象是從哪裡來的呢？還記得之前拆解的第一步么，loadClass方法中有幾個快取，其中wrapperclasses就是快取這些wrapper的class。

從程式碼中可以看出，只要構造方法里有且只有唯一參數，同時此參數為當前傳入的介面類型，即為wrapper class。

此處循環創建wrapper實例，首先將instance做為構造函數的參數，通過反射來創建wrapper對象，然後再向wrapper中注入依賴。

看到這裡，可能會有人有疑問：為什麼要創建一個wrapper對象？其實很簡單，系統要在真正調用的前後干點別的事唄。這個就有點類似於spring的aop了。

三、總結

本文簡單介紹了JDK的SPI和Dubbo的SPI用法，分析了JDK的SPI源碼和Dubbo的SPI源碼。在拆解的過程中可以看出，Dubbo的源碼還是很值得一讀的。在實現方面考慮得很周全，不僅有對多執行緒的處理、多層快取，也有IOC、AOP的過程。不過，Dubbo的SPI就這麼簡單么？當然不是，這篇只拆解了擴展類的載入過程，Dubbo的SPI中還有個很複雜的擴展點-自適應機制。欲知後事如何，請聽下回分解～～

本文作者：宜信支付結算部支付研發團隊Java研發高級工程師鄭祥斌

原文首發於「野指針」