目錄
- 正文
- 為什么要使用SPI？
- 什么是 SPI
- JDK SPI 機(jī)制
- JDK SPI原理
- 為什么不直接使用 JDK SPI
正文
上一篇文章講到了如何去找到 Dubbo 源碼的調(diào)試入口，如果你跟隨文章思路，那你將要閱讀的第一條主線將是 Dubbo 的服務(wù)發(fā)布流程。在閱讀的過(guò)程中你會(huì)發(fā)現(xiàn)，有很多代碼很相似，并且重復(fù)出現(xiàn)，比如這里：
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 服務(wù)發(fā)布的關(guān)鍵流程，其中用到了兩個(gè)類(lèi)都是通過(guò)ExtensionLoader.getExtensionLoader()去獲得的，這其實(shí)體現(xiàn)的就是Dubbo 的SPI機(jī)制，SPI 機(jī)制在 Dubbo 中被大量運(yùn)用，也是 Dubbo 設(shè)計(jì)的亮點(diǎn)所在。
為什么要使用SPI？
這就要談到Dubbo的架構(gòu)設(shè)計(jì)了，之前提到 Dubbo 采用的是分層架構(gòu)的方式，Dubbo 的設(shè)計(jì)體現(xiàn)了程序設(shè)計(jì)中的開(kāi)閉原則，每一層都可以被另一種實(shí)現(xiàn)技術(shù)替換掉，而不影響上下層之間的依賴(lài)和整體邏輯的運(yùn)轉(zhuǎn)，這其實(shí)就是微內(nèi)核架構(gòu)（微內(nèi)核+插件）。
微內(nèi)核架構(gòu)也被稱(chēng)為插件化架構(gòu)（Plug-in Architecture），這是一種面向功能進(jìn)行拆分的可擴(kuò)展性架構(gòu)。內(nèi)核功能是比較穩(wěn)定的，只負(fù)責(zé)管理插件的生命周期，不會(huì)因?yàn)橄到y(tǒng)功能的擴(kuò)展而不斷進(jìn)行修改。功能上的擴(kuò)展全部封裝到插件之中，插件模塊是獨(dú)立存在的模塊，包含特定的功能，全部可被替換，并且可以拓展內(nèi)核系統(tǒng)的功能，而 Dubbo 最終決定采用 SPI 機(jī)制來(lái)加載插件。
開(kāi)閉原則 OCP (Open-Closed Principle )：程序的設(shè)計(jì)應(yīng)該是不約束擴(kuò)展，即擴(kuò)展開(kāi)放，但又不能修改已有功能，即修改關(guān)閉。
什么是 SPI
SPI ，全稱(chēng)為 Service Provider Interface，直接翻譯過(guò)來(lái)是服務(wù)提供者接口，是一種服務(wù)發(fā)現(xiàn)機(jī)制，而我們通常指的是JDK的SPI。
JDK SPI，它是JDK內(nèi)置的一種服務(wù)發(fā)現(xiàn)機(jī)制，可以動(dòng)態(tài)的發(fā)現(xiàn)服務(wù)，即服務(wù)提供商，它通過(guò)在ClassPath路徑下的META-INF/services文件夾查找文件，自動(dòng)加載文件里所定義的類(lèi)。
根據(jù)他的定義就知道他主要是被框架開(kāi)發(fā)人員使用的，通過(guò) SPI 可以加載服務(wù)本身以外的擴(kuò)展。最常用的比如JDBC驅(qū)動(dòng)連接時(shí)候選擇不同的驅(qū)動(dòng)，對(duì)java.sql.Driver的實(shí)現(xiàn)就利用了SPI機(jī)制；Spring框架中也使用了很多，比如在 Spring 中為了支持Servlet3.0規(guī)范不使用web.xml，對(duì)javax.servlet.ServletContainerInitializer的實(shí)現(xiàn)也利用了SPI；在Dubbo中更是大量運(yùn)用了SPI機(jī)制，不但有JDK SPI的運(yùn)用，更重要的是 Dubbo 自己還實(shí)現(xiàn)了一套SPI機(jī)制。
JDK SPI 機(jī)制
當(dāng)服務(wù)提供者想利用SPI機(jī)制去擴(kuò)展，需要遵循以下步驟。
- 首先需要實(shí)現(xiàn)實(shí)現(xiàn)對(duì)應(yīng)接口。
- 然后需要在 Classpath 下的 META-INF/services/ 目錄中創(chuàng)建一個(gè)以服務(wù)接口全路徑命命名的文件。
- 在該文件中記錄服務(wù)接口的所有具體實(shí)現(xiàn)類(lèi)，通常是在外部引入的擴(kuò)展包中，比如引入JDBC的jar包。
- 做好以上配置，就可以利用JDK SPI的查找機(jī)制在META-INF/services/文件夾下根據(jù)配置來(lái)對(duì)具體的實(shí)現(xiàn)類(lèi)加載和實(shí)例化。
如果看完上述流程還不是很清楚，請(qǐng)看如下示例。比如這里有接口 MySPI 需要按照上述流程按照SPI機(jī)制加載。
首先提供了兩個(gè)實(shí)現(xiàn)類(lèi) GoodbyeMySPI 和 HelloMySPI，然后在 META-INF/services 文件夾下保存了文件org.daley.spi.demo.MySPI，文件的內(nèi)容是兩個(gè)實(shí)現(xiàn)類(lèi)的全路徑名。就緒之后就可以在main方法中啟動(dòng)demo，用ServiceLoader.load()加載 MySPI 的兩個(gè)實(shí)現(xiàn)類(lèi)，然后分別調(diào)用接口方法執(zhí)行。代碼如下：
/**
* @author 后端開(kāi)發(fā)技術(shù)
*/
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();
// 開(kāi)始迭代執(zhí)行
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，你有沒(méi)有好奇 JDK SPI 的原理是什么？相信你已經(jīng)猜的八九不離十了。我們從demo的main方法開(kāi)始追蹤起。
很明顯關(guān)鍵的代碼就一行ServiceLoader.load(MySPI.class)，他是整個(gè)類(lèi)加載的入口。
- 調(diào)用
ServiceLoader.load(MySPI.class)開(kāi)始加載，并且會(huì)拿到當(dāng)前線程的類(lèi)加載器。 - 開(kāi)始創(chuàng)建一個(gè)
ServiceLoader，最終可以追蹤到調(diào)用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) {
// 綁定接口和類(lèi)加載器
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，它里面存貯了所有服務(wù)接口的實(shí)現(xiàn)，key為實(shí)現(xiàn)類(lèi)名，value為對(duì)象。然后便會(huì)new一個(gè)LazyIterator，LazyIterator是ServiceLoader內(nèi)部實(shí)現(xiàn)的一個(gè)迭代器，此時(shí)還沒(méi)有真正開(kāi)始加載，只是保存了接口和類(lèi)加載器在迭代器中。
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;
}
}
正如其名懶加載迭代器，在調(diào)用iterator.hasNext()時(shí)才真正發(fā)生加載。在hasNextService()方法中，第一次調(diào)用此方法會(huì)先拼接出配置SPI的文件名，在本demo中也就是META-INF/services/org.daley.spi.demo.MySPI，然后會(huì)使用類(lèi)加載器加載配置文件并且將每行的內(nèi)容設(shè)置到迭代器pending中，每次遍歷都可以按行依次拿到實(shí)現(xiàn)類(lèi)的名字。
比如第一次迭代，返回第一行配置的實(shí)現(xiàn)類(lèi)名org.daley.spi.demo.GoodbyeMySPI。到這里只是加載配置文件拿到類(lèi)名，還未加載類(lèi)。
public boolean hasNext() {
if (acc == null) {
return hasNextService();
} else {
……
}
}
// pengding中保存了配置文件中的實(shí)現(xiàn)類(lèi)名，按行迭代
Iterator<String> pending = null;
private boolean hasNextService() {
……
if (configs == null) {
try {
// 設(shè)置配置文件路徑 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());
}
// 按行拿到實(shí)現(xiàn)類(lèi)名
nextName = pending.next();
return true;
}
當(dāng)執(zhí)行到iterator.next()的時(shí)候才會(huì)真正去加載class類(lèi)。追蹤此方法最終進(jìn)入nextService()方法，在這里你會(huì)看到熟悉的Class.forName()以及newInstance()方法，讀取類(lèi)和實(shí)例化類(lèi)的邏輯一目了然。到這里JDK SPI的核心邏輯就結(jié)束了。
public S next() {
if (acc == null) {
return nextService();
} else {
……
}
}
private S nextService() {
if (!hasNextService())
throw new NoSuchElementException();
//當(dāng)前正在迭代的實(shí)現(xiàn)類(lèi)名
String cn = nextName;
nextName = null;
Class<?> c = null;
try {
// 根據(jù)類(lèi)路徑加載class
c = Class.forName(cn, false, loader);
……
// 實(shí)例化實(shí)現(xiàn)類(lèi)，并且保存在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
}
簡(jiǎn)言之，通過(guò)將實(shí)現(xiàn)類(lèi)名保存在以服務(wù)接口命名的配置文件中，放置在META-INF/services，ServiceLoader會(huì)在先讀取配置文件中實(shí)現(xiàn)類(lèi)的名字，然后根據(jù)調(diào)用newInstance()方法對(duì)其進(jìn)行實(shí)例化。簡(jiǎn)化的原理圖如下：
為什么不直接使用 JDK SPI
既然已經(jīng)有了 JDP SPI 為什么還需要 Dubbo SPI呢？
技術(shù)的出現(xiàn)通常都是為了解決現(xiàn)有問(wèn)題，通過(guò)之前的 demo，不難發(fā)現(xiàn) JDK SPI 機(jī)制就存在以下一些問(wèn)題：
- 實(shí)現(xiàn)類(lèi)會(huì)被全部遍歷并且實(shí)例化，假如我們只需要使用其中的一個(gè)實(shí)現(xiàn)，這在實(shí)現(xiàn)類(lèi)很多的情況下無(wú)疑是對(duì)機(jī)器資源巨大的浪費(fèi)，
- 無(wú)法按需獲取實(shí)現(xiàn)類(lèi)，不夠靈活，我們需要遍歷一遍所有實(shí)現(xiàn)類(lèi)才能找到指定實(shí)現(xiàn)。
所以 Dubbo SPI 以 JDK SPI 為參考做出了改進(jìn)設(shè)計(jì)，進(jìn)行了性能優(yōu)化以及功能增強(qiáng)，Dubbo SPI 機(jī)制的出現(xiàn)解決了上述問(wèn)題。 由于 Dubbo SPI的知識(shí)點(diǎn)太多并且很重要，將專(zhuān)門(mén)安排在下一篇文章講解，更多關(guān)于Dubbo JDK SPI原理的資料請(qǐng)關(guān)注其它相關(guān)文章！
