當前位置：首頁 > server > anz > 詳細頁面

Dubbo 系列JDK SPI 原理解析

時間：2023-03-01來源：系統城裝機大師作者：佚名

上一篇文章講到了如何去找到 Dubbo 源碼的調試入口，如果你跟隨文章思路，那你將要閱讀的第一條主線將是 Dubbo 的服務發布流程。在閱讀的過程中你會發現，有很多代碼很相似，并且重復出現，比如這里：

1
2
3
4
5
6
7
8 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 的兩個實現類，然后分別調用接口方法執行。代碼如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33 /**
* @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()方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 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內部實現的一個迭代器，此時還沒有真正開始加載，只是保存了接口和類加載器在迭代器中。

1
2
3
4
5
6
7
8
9
10
11 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。到這里只是加載配置文件拿到類名，還未加載類。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34 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的核心邏輯就結束了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29 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
}