dubbo的微內核機制

dubbo是如何實現的微內核呢

dubbo定義了規則，使用的都是spi的擴展機制，盜用一張圖能夠看到

從上邊能夠看出來，dubbo不實現組件，使用的都是spi的擴展，這樣實現微內核，可擴展。

加載組件使用的是 SpiExtensionFactory 和 SpringExtensionFactory 兩種方式；

而後經過adaptive加載 默認的實現類，若是有的此註解；

默認適應擴展 ：被 @SPI("abc") 註解的 Interface  , 那麼這個擴展點的缺省適應擴展就是 SPI 配置文件中 key 爲 "abc"  的擴展。若是存在被 @Adaptive 註解在類上的擴展點接口實現 ，那麼這個類就做爲擴展點的缺省適應擴展， 一個擴展點只能有一個缺省適應擴展也就是說多個擴展中只能有一個在類上被 @Adaptive 註解，若是有多個 dubbo 會拋出 IllegalStateException("More than 1 adaptive class found : ")。

@SPI （註解在類上） :  @SPI 註解標識了接口是一個擴展點 ， 屬性 value 用來指定默認適配擴展點的名稱。@Activate （註解在類型和方法上） ：  @Activate 註解在擴展點的實現類上 ，表示了一個擴展類被獲取到的的條件，符合條件就被獲取，不符合條件就不獲取 ，根據 @Activate 中的 group 、 value 屬性來過濾 。具體參考 ExtensionLoader 中的  getActivateExtension 函數。

@Adaptive （註解在類型和方法上） ：  @Adaptive 註解在類上 ， 這個類就是缺省的適配擴展。@Adaptive 註解在擴展點 Interface 的方法上時 ， dubbo 動態的生成一個這個擴展點的適配擴展類（生成代碼 ，動態編譯實例化 Class ），名稱爲 擴展點 Interface 的簡單類名 + $Adaptive ，例如 ：ProxyFactory$Adpative  。這麼作的目的是爲了在運行時去適配不一樣的擴展實例 ， 在運行時經過傳入的 URL 類型的參數或者內部含有獲取 URL 方法的參數 ，從 URL 中獲取到要使用的擴展類的名稱 ，再去根據名稱加載對應的擴展實例 ，用這個擴展實例對象調用相同的方法  。若是運行時沒有適配到運行的擴展實例 ， 那麼就使用 @SPI 註解缺省指定的擴展。經過這種方式就實現了運行時去適配到對應的擴展。

ExtensionLoader.getExtensionLoader(Xxx.class).getExtension(extName);

ExtendionLoader 是 實現spi的核心，加載擴展點的順序是，首先找adaptive的擴展實例，沒有則自動生成一個擴展實例

參考： 黑帽子技術 https://mp.weixin.qq.com/s/McjABJcRBaJnRv9aWQr0FQ