Dubbo SPI

Dubbo 就是通過 SPI 機制加載所有的組件。不過，Dubbo 并未使用 Java 原生的 SPI 機制，而是對其進行了增強，使其能夠更好的滿足需求。在 Dubbo 中，SPI 是一個非常重要的模塊?；?SPI，我們可以很容易的對 Dubbo 進行拓展。如果大家想要學(xué)習(xí) Dubbo 的源碼，SPI 機制務(wù)必弄懂。接下來，我們先來了解一下 Java SPI 與 Dubbo SPI 的用法，然后再來分析 Dubbo SPI 的源碼。 

Dubbo 中實現(xiàn)了一套新的 SPI 機制，功能更強大，也更復(fù)雜一些。相關(guān)邏輯被封裝在了 ExtensionLoader 類中，通過 ExtensionLoader，我們可以加載指定的實現(xiàn)類。Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路徑下，配置內(nèi)容如下（以下demo來自dubbo官方文檔）。

optimusPrime = org.apache.spi.OptimusPrime
bumblebee = org.apache.spi.Bumblebee

與 Java SPI 實現(xiàn)類配置不同，Dubbo SPI 是通過鍵值對的方式進行配置，這樣我們可以按需加載指定的實現(xiàn)類。另外在使用時還需要在接口上標(biāo)注 @SPI 注解。

下面來演示 Dubbo SPI 的用法：

@SPI
public interface Robot {
void sayHello();
}
public class OptimusPrime implements Robot {
@Override
public void sayHello(){
System.out.println("Hello, I am Optimus Prime.");
}
}

public class Bumblebee implements Robot {

@Override
public void sayHello(){
System.out.println("Hello, I am Bumblebee.");
}
}
public class DubboSPITest {

@Test
public void sayHello() throws Exception {
ExtensionLoader<Robot> extensionLoader =
ExtensionLoader.getExtensionLoader(Robot.class);
Robot optimusPrime = extensionLoader.getExtension("optimusPrime");
optimusPrime.sayHello();
Robot bumblebee = extensionLoader.getExtension("bumblebee");
bumblebee.sayHello();
}
}

「Dubbo SPI 和 JDK SPI 最大的區(qū)別就在于支持“別名”」，可以通過某個擴展點的別名來獲取固定的擴展點。就像上面的例子中，我可以獲取 Robot 多個 SPI 實現(xiàn)中別名為“optimusPrime”的實現(xiàn)，也可以獲取別名為“bumblebee”的實現(xiàn)，這個功能非常有用！

通過 @SPI 注解的 value 屬性，還可以默認(rèn)一個“別名”的實現(xiàn)。比如在Dubbo 中，默認(rèn)的是Dubbo 私有協(xié)議：「dubbo protocol - dubbo://」**

來看看Dubbo中協(xié)議的接口：

@SPI("dubbo")
public interface Protocol {
......
}

在 Protocol 接口上，增加了一個 @SPI 注解，而注解的 value 值為 Dubbo ，通過 SPI 獲取實現(xiàn)時就會獲取 Protocol SPI 配置中別名為dubbo的那個實現(xiàn)，??com.alibaba.dubbo.rpc.Protocol??文件如下：

filter=com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper
listener=com.alibaba.dubbo.rpc.protocol.ProtocolListenerWrapper
mock=com.alibaba.dubbo.rpc.support.MockProtocol
dubbo=com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol
injvm=com.alibaba.dubbo.rpc.protocol.injvm.InjvmProtocol
rmi=com.alibaba.dubbo.rpc.protocol.rmi.RmiProtocol
hessian=com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol
com.alibaba.dubbo.rpc.protocol.http.HttpProtocol
com.alibaba.dubbo.rpc.protocol.webservice.WebServiceProtocol
thrift=com.alibaba.dubbo.rpc.protocol.thrift.ThriftProtocol
memcached=com.alibaba.dubbo.rpc.protocol.memcached.MemcachedProtocol
redis=com.alibaba.dubbo.rpc.protocol.redis.RedisProtocol
rest=com.alibaba.dubbo.rpc.protocol.rest.RestProtocol
registry=com.alibaba.dubbo.registry.integration.RegistryProtocol
qos=com.alibaba.dubbo.qos.protocol.QosProtocolWrapper

然后只需要通過getDefaultExtension，就可以獲取到 @SPI 注解上value對應(yīng)的那個擴展實現(xiàn)了

Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getDefaultExtension();
//protocol: DubboProtocol

還有一個 Adaptive 的機制，雖然非常靈活，但……用法并不是很“優(yōu)雅”，這里就不介紹了

Dubbo 的 SPI 中還有一個“加載優(yōu)先級”，優(yōu)先加載內(nèi)置（internal）的，然后加載外部的（external），按優(yōu)先級順序加載，「如果遇到重復(fù)就跳過不會加載」了。

所以如果想靠classpath加載順序去覆蓋內(nèi)置的擴展，也是個不太理智的做法，原因同上 - 加載順序不嚴(yán)謹(jǐn)

Spring SPI?

Spring 的 SPI 配置文件是一個固定的文件 - ??META-INF/spring.factories??，功能上和 JDK 的類似，每個接口可以有多個擴展實現(xiàn)，使用起來非常簡單：

//獲取所有factories文件中配置的LoggingSystemFactory
List<LoggingSystemFactory>> factories =
SpringFactoriesLoader.loadFactories(LoggingSystemFactory.class, classLoader);

下面是一段 Spring Boot 中 spring.factories 的配置

# Logging Systems
org.springframework.boot.logging.LoggingSystemFactory=\
org.springframework.boot.logging.logback.LogbackLoggingSystem.Factory,\
org.springframework.boot.logging.log4j2.Log4J2LoggingSystem.Factory,\
org.springframework.boot.logging.java.JavaLoggingSystem.Factory

# PropertySource Loaders
org.springframework.boot.env.PropertySourceLoader=\
org.springframework.boot.env.PropertiesPropertySourceLoader,\
org.springframework.boot.env.YamlPropertySourceLoader

# ConfigData Location Resolvers
org.springframework.boot.context.config.ConfigDataLocationResolver=\
org.springframework.boot.context.config.ConfigTreeConfigDataLocationResolver,\
org.springframework.boot.context.config.StandardConfigDataLocationResolver

......

Spring SPI 中，將所有的配置放到一個固定的文件中，省去了配置一大堆文件的麻煩。至于多個接口的擴展配置，是用一個文件好，還是每個單獨一個文件好這個，這個問題就見仁見智了（個人喜歡 Spring 這種，干凈利落）。

Spring的SPI 雖然屬于spring-framework(core)，但是目前主要用在spring boot中……

和前面兩種 SPI 機制一樣，Spring 也是支持 ClassPath 中存在多個 spring.factories 文件的，加載時會按照 classpath 的順序依次加載這些 spring.factories 文件，添加到一個 ArrayList 中。由于沒有別名，所以也沒有去重的概念，有多少就添加多少。

但由于 Spring 的 SPI 主要用在 Spring Boot 中，而 Spring Boot 中的 ClassLoader 會優(yōu)先加載項目中的文件，而不是依賴包中的文件。所以如果在你的項目中定義個spring.factories文件，那么你項目中的文件會被第一個加載，得到的Factories中，項目中spring.factories里配置的那個實現(xiàn)類也會排在第一個

如果我們要擴展某個接口的話，只需要在你的項目（spring boot）里新建一個??META-INF/spring.factories??文件，「只添加你要的那個配置，不要完整的復(fù)制一遍 Spring Boot 的 spring.factories 文件然后修改」**
比如我只想添加一個新的 LoggingSystemFactory 實現(xiàn)，那么我只需要新建一個??META-INF/spring.factories??文件，而不是完整的復(fù)制+修改：

org.springframework.boot.logging.LoggingSystemFactory=\
com.example.log4j2demo.Log4J2LoggingSystem.Factory

對比?

• JDK SPI
• DUBBO SPI
• Spring SPI

三種 SPI 機制對比之下，JDK 內(nèi)置的機制是最弱雞的，但是由于是 JDK 內(nèi)置，所以還是有一定應(yīng)用場景，畢竟不用額外的依賴；Dubbo 的功能最豐富，但機制有點復(fù)雜了，而且只能配合 Dubbo 使用，不能完全算是一個獨立的模塊；Spring 的功能和JDK的相差無幾，最大的區(qū)別是所有擴展點寫在一個 spring.factories 文件中，也算是一個改進，并且 IDEA 完美支持語法提示。

到此這篇關(guān)于Java Spring Dubbo三種SPI機制的區(qū)別的文章就介紹到這了,更多相關(guān)Java SPI機制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！