梳理Dubbo擴展的理解

不得不擴展

從SPI說起

ExtensionLoader

驗證自定義協議

---

不得不擴展

Dubbo分爲很多邏輯層，對於各個層的接口，Dubbo都提供了很多種的實現，
對於需要滿足很多使用個性需求的框架來說，單單是多提供幾個實現是不夠的。
重要的是需要在框架設計層面有一個好的解決方案，能讓框架能應對不斷擴張的需求。
這樣才能在不改動最原始邏輯的基礎上，不斷豐富框架的內容。

Dubbo應對這種需求，實現了內核+插件的方式，草圖如下：

如何讓衆多的實現，以統一的方式準確地接入Dubbo框架中？這是重點需要解決的問題。

如果需要靈活，硬編碼的方式肯定是不行的，
從編碼的角度來說，如果能提供配置，讓框架解析配置，這是比較好的方法。（如果是我，我會這樣想）

從SPI說起

Service Provider Interface，是一種設計方式，而不是某種具體的API，可以理解爲：通過接口尋找實現類。
一般說來，面向接口編程，接口實現方，可以提供多種實現，從而在調用方，屏蔽實現的細節。
SPI設計方式，在此基礎上做了一定的擴展，同樣，服務調用方不在意接口的實現細，並且接口由調用方制定，實現是在另外獨立的包中。
有點抽象，我們可以用生活中很常見的事情來模擬下這種方案：

某天，幼兒園的老師佈置了一個作業：小朋友明天都帶一條小魚來幼兒園，用玻璃瓶裝好，我們明天一起觀察小魚，
然後評選出最漂亮的小魚拍照放貼教室牆上。
消息傳達到家長那裏，第二天，有人帶小鯽魚，有人帶小金魚，有人帶小丑魚，咦，蛋蛋，你帶的是條魚乾嗎？！

玩笑結束 :)
首先，老師佈置的作業，我們可以理解爲一個接口，這個接口是由需要使用接口實現的人發佈的，它的目的就是多樣化，因爲作業(接口)的實現方，是各位小朋友，大家對這個接口的實現肯定不是一樣的。這樣在上課的時候（程序運行期間），大家都把自己的實現帶到教室，由老師（調用方）來使用，至於使用哪個，是需要看當時具體的情況。

從以上的例子可以看出，接口在邏輯上，和接口的使用者更接近，而不是實現者。

Java6提供了一種SPI實現，並且提供一個ServiceLoader類來加載對象。
它約定接口的實現者實現接口後，在自己所在項目的目錄（不一定和調用者在一起項目內）META-INF\services\下，創建一個接口全類名爲名字的文件，將實現類的全類名寫進去。
ServiceLoader的例子網上有很多，此處不再提了。

ExtensionLoader

SPI爲Dubbo需要解決的擴展問題提供了很好的思路。但是JDK原生的SPI實現，不適合拿來用。

• 一次性會加載出接口的所有實現，這樣的性能不會高；

• 沒有辦法做到對內部的擴展對象進行級聯初始化；

• 默認實現不是單例的；

Dubbo自己做了一套基於SPI機制的加載和緩存擴展的實現，ExtensionLoader。
它着重解決如下的幾個方面的問題：

• 對於某個擴展接口，需要可以加載出所有的實現，保證每個實現都是單例的；
• 需要能在運行時決定需要使用哪個擴展；

爲了適配各種實現，Dubbo對每個擴展接口，都對應生成一個唯一的Adaptive對象，這個對象是個適配器，也可以成爲代理，它
會根據每個擴展功能的實際配置，決定需要用哪個實現。
並且對加載出來的擴展Adaptive對象、Class對象、擴展對象和擴展名的對應關係都是存儲在static容器中
在加載的時候甚至還做了雙重判空和必要的同步。

ExtensionLoader默認在如下三個目錄加載擴展：
private static final String SERVICES_DIRECTORY = “META-INF/services/”;
private static final String DUBBO_DIRECTORY = “META-INF/dubbo/”;
private static final String DUBBO_INTERNAL_DIRECTORY = “META-INF/dubbo/internal/”;

每個實現都會有一個對應的key，例如：

default=cn.irving.extension.DefaultExtension
sw=cn.irving.extension.SWExtension
adaptive=cn.irving.extension.AdaptiveExtension

如果某個實現上添加了@Adaptive註解，就說明是個適配類，配置類本身不提供服務，它會去ExtensionLoader中加載實現對象，並且調用相同的方法並返回。
如果沒有任何實現由這個註解，就需要在接口的方法上添加並且提供URL作爲參數，從中提取需要適配的方法，臨時構造一個適配器類，這個適配器類，功能和上面的一致。

擴展實現通過擴展適配器被內核使用，這樣外部的實現也能融合到框架內部。

驗證自定義協議

可以弄個例子，簡單地試一下，做一個簡單的dubbo例子，測試一下dubbo是否可以接納我們自己定義的Protocol：
1、創建接口：

public interface DemoService {
    String sayHello(String name);
}

2、創建provider實現：

public class DemoServiceImpl implements DemoService {
    public String sayHello(String name) {
        return "Hello world, "+name;
    }
}

3、配置dubbo的provider-xml和consumer-xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
    <dubbo:application name="demo-provider-zk"/>
    <dubbo:registry address="zookeeper://localhost:2181" check="false"/>
    <dubbo:protocol name="test" port="20880"/>
    <dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService"/>
    <bean id="demoService" class="com.alibaba.dubbo.demo.provider.DemoServiceImpl"/>
</beans>

注意，此處用到的協議名爲：test

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
    <dubbo:application name="demo-consumer" logger="log4j"/>
    <dubbo:registry address="zookeeper://localhost:2181" check="false"/>
    <dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" check="false"/>
</beans>

4、定義服務啓動類和消費者類：

public class App 
{
    public static void main( String[] args )throws Exception
    {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[]{
                "spring-config-zk-provider.xml"
        });
        context.start();
        System.in.read();
    }
}

public class Consumer {
    public static void main(String[] args) throws IOException, InterruptedException {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[]{
               "spring-config-zk-consumer.xml"
        });
        context.start();
        DemoService demoService = (DemoService)context.getBean("demoService");
        System.in.read();
        for(int i = 0 ; i < 3 ; i++) {
            System.out.println(demoService.sayHello("SUN-中文")+i);
        }
    }
}

此時如果啓動服務，將會得到如下的報錯：

Exception in thread "main" java.lang.IllegalStateException: No such extension com.alibaba.dubbo.rpc.Protocol by name test

找不到Protocol實現:(

接下來我們自己定義一個Protocol擴展，實現Protocol接口：

public class TestProtocol extends DubboProtocol {
    @Override
    public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
        System.out.println("THIS IS TEST EXPORTER");
        return super.export(invoker);
    }
}

這個協議比較簡單，全部都用DubboProtocol的實現，爲了證明它用到了這個實現，在export服務的時候打印一句話。

然後將我們的擴展配置在/META-INF/dubbo/com.alibaba.dubbo.rpc.Protocol中：

test=cn.irving.extension.TestProtocol

然後再運行服務端和客戶端，將得到如下的結果：
服務端：

Connected to the target VM, address: '127.0.0.1:58434', transport: 'socket'
log4j:WARN No appenders could be found for logger (org.springframework.core.env.StandardEnvironment).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
THIS IS TEST EXPORTER

客戶端：

Hello world, SUN-中文0
Hello world, SUN-中文1
Hello world, SUN-中文2

-EOF-