請問Dubbo的SPI機制是啥??？
前言
之前大致的把Dubbo的運作流程簡單的分析了一遍了，Dubbo還有一個很大的優點，就是采用的微內核+SPI擴展設計。
這又是什么呢，這個可以很好的支持一些有特殊需求的三方的接入，可以自定義擴展，自主定制二次開發，良好的擴展性對于框架來說是很重要的。
簡單了解下SPI，全稱為 Service Provider Interface，是一種服務發現機制。
它通過在ClassPath路徑下的META-INF/services文件夾查找文件，自動加載文件里所定義的類。這一機制為很多框架擴展提供了可能，比如在Dubbo、JDBC中都使用到了SPI機制。
舉個例子，比如你有個接口，現在這個接口有 3 個實現類，那么在系統運行的時候對這個接口到底選擇哪個實現類呢?這就需要SPI了，需要根據指定的配置或者是默認的配置，去找到對應的實現類加載進來，然后用這個實現類的實例對象。
Java中JDK自身實現了SPI機制，基于策略模式來實現動態加載的機制 。我們在程序只定義一個接口，具體的實現交個不同的服務提供者;在程序啟動的時候，讀取配置文件，由配置確定要調用哪一個實現。
但是呢，存在一定的缺點，比如不能按照需要加載，會一次性加載所有可用的擴展點，很多是不需要的，會浪費系統資源;不支持AOP和依賴注入，實現類的方式也不夠靈活，只能通過 Iterator 形式獲取。
你不夠強，或者說你做的不符合我的需求，我就替換你。
于是呢，dubbo重新實現了一套功能更強的 SPI 機制, 支持了AOP與依賴注入，并且 利用緩存提高加載實現類的性能，同時支持實現類的靈活獲取。
Java中的SPI
Java中JDK自身實現了SPI機制，基于策略模式來實現動態加載的機制 。我們在程序只定義一個接口，具體的實現交個不同的服務提供者;在程序啟動的時候，讀取配置文件，由配置確定要調用哪一個實現。
首先，我們需要定義一個接口，SPIService。
- public interface SPIService {
- void execute();
- }
然后，定義兩個實現類，沒別的意思，只輸入一句話。
- public class SpiImpl1 implements SPIService{
- public void execute() {
- System.out.println("SpiImpl1.execute()");
- }
- }
- public class SpiImpl2 implements SPIService{
- public void execute() {
- System.out.println("SpiImpl2.execute()");
- }
- }
最后呢，要在ClassPath路徑下配置添加一個文件。文件名字是接口的全限定類名，內容是實現類的全限定類名，多個實現類用換行符分隔。內容就是實現類的全限定類名：
- com.tech.dayu.spi.SpiImpl1
- com.tech.dayu.spi.SpiImpl2
測試
- public class Test {
- public static void main(String[] args) {
- Iterator<SPIService> providers = Service.providers(SPIService.class);
- ServiceLoader<SPIService> load = ServiceLoader.load(SPIService.class);
- while(providers.hasNext()) {
- SPIService ser = providers.next();
- ser.execute();
- }
- System.out.println("###################");
- Iterator<SPIService> iterator = load.iterator();
- while(iterator.hasNext()) {
- SPIService ser = iterator.next();
- ser.execute();
- }
- }
- }
兩種方式的輸出結果是一致的：
- SpiImpl1.execute()
- SpiImpl2.execute()
- --------------------------------
- SpiImpl1.execute()
- SpiImpl2.execute()
我們來看下源碼，位于java.util包下。我們就以ServiceLoader.load為例，通過源碼看看它里面到底怎么做的。
ServiceLoader.load()其實就是 Java SPI 入口
看到最后調用的是reload，最后生效的是在這個LazyIterator的內部，等同于是一個迭代器的遍歷，遍歷相應的文件中的service的實現類，就是我們上面命名的那些。
這里無論是if還是else最后調用的都是nextService()方法，點進去看
可以看到無非就是通過名字獲取到文件路徑，獲取全限定名來加載類，并且創建其實例放入到相應的緩存之后并且返回實例，這大體就是整個的實現邏輯，應該不難吧，咱們自己來實現個這個應該也是分分鐘的事
好了，Java的SPI源碼分析的差不多了，問題也隨之而來，比如不能按照需要加載，會一次性加載所有可用的擴展點，很多是不需要的，會浪費系統資源;不支持AOP和依賴注入，實現類的方式也不夠靈活，只能通過 Iterator 形式獲取
接下來咱們來分析Dubbo的SPI
Dubbo中的SPI
Dubbo 并未使用 Java SPI，而是重新實現了一套功能更強的 SPI 機制。
Dubbo SPI 的相關邏輯被封裝在了 ExtensionLoader 類中，通過 ExtensionLoader，我們可以加載指定的實現類。Dubbo SPI 所需的配置文件需放置在 META-INF/dubbo 路徑下。
Dubbo要判斷一下，在系統運行時，應該選用這個Protocol接口的哪個實現類。它會去找一個你配置的Protocol，將你配置的Protocol實現類，加載進JVM，將其實例化，微內核，可插拔，大量的組件，Protocol負責RPC調用的東西，你可以實現自己的RPC調用組件，實現Protocol接口，給自己的一個實現類就可以啦
Dubbo里很多都是保留一個接口和多個實現，然后在系統運行的時候動態根據配置去找到對應的實現類。如果你沒配置，那就走默認的實現就可以啦
我們隨便來看一下其中的
并且 Dubbo SPI 除了可以按需加載實現類之外，增加了 IOC 和 AOP 的特性，還有個自適應擴展機制。
我們先來看一下 Dubbo 對配置文件目錄的約定，不同于 Java SPI ，Dubbo 分為了三類目錄。
- META-INF/services/ 目錄：該目錄下的 SPI 配置文件是為了用來兼容 Java SPI 。
- META-INF/dubbo/ 目錄：該目錄存放用戶自定義的 SPI 配置文件。
- META-INF/dubbo/internal/ 目錄：該目錄存放 Dubbo 內部使用的 SPI 配置文件。
接下來我們來看Dubbo的SPI的源碼
在Dubbo中ExtensionLoader類似 Java SPI 中 ServiceLoader 的存在。大致流程就是先通過接口類找到ExtensionLoader ，然后再通過 ExtensionLoader.getExtension(name) 得到指定名字的實現類實例。
其實也是很簡單的，就是通過一頓判斷然后在緩存中檢查是否存在這個類型的ExtensionLoader ，沒有的話就新建一個放進去緩存，最后返回接口類的對應的ExtensionLoader
getExtension() 方法，從現象我們可以知道這個方法就是從類對應的 ExtensionLoader 中通過名字找到實例化完的實現類
內部的createExtension()方法，我就不截圖了，比較長，就是先找實現類，判斷是否有該類的緩存，沒有的話就通過反射新建一個實例對象，然后放進去
到這里其實就差不多了分析的，拿到實例對然后就可以執行了
Dubbo的SPI主要就是為了增加框架的可拓展性，可以在其基礎上進行二次開發，還有一個更重要的點就是不會像Java的SPI一樣直接全部加載，那樣可能會造成大量的資源浪費的，甚至可能還會做無用功
【編輯推薦】
