Dubbo源碼分析(2)，Dubbo中採用的設計模式

一、工廠模式 

     ServiceConfig中有個字段，代碼是這樣的： 

private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();

  Dubbo裏有不少這種代碼。這也是一種工廠模式，只是實現類的獲取採用了jdkspi的機制。這麼實現的優勢是可擴展性強，想要擴展實現，只須要在classpath下增長個文件就能夠了，代碼零侵入。另外，像上面的Adaptive實現，能夠作到調用時動態決定調用哪一個實現，可是因爲這種實現採用了動態代理，會形成代碼調試比較麻煩，須要分析出實際調用的實現類。

 

二、裝飾器模式 

       Dubbo在啓動和調用階段都大量使用了裝飾器模式。以Provider提供的調用鏈爲例，具體的調用鏈代碼是在ProtocolFilterWrapper的buildInvokerChain完成的，具體是將註解中含有group=provider的Filter實現，按照order排序，最後的調用順序是 

   EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》  

   TimeoutFilter-》MonitorFilter-》TraceFilter。  

       更確切地說，這裏是裝飾器和責任鏈模式的混合使用。例如，EchoFilter的做用是判斷是不是回聲測試請求，是的話直接返回內容，這是一種責任鏈的體現。而像ClassLoaderFilter則只是在主功能上添加了功能，更改當前線程的ClassLoader，這是典型的裝飾器模式。

 

三、觀察者模式 

      Dubbo的provider啓動時，須要與註冊中心交互，先註冊本身的服務，再訂閱本身的服務，訂閱時，採用了觀察者模式，開啓一個listener。註冊中心會每5秒定時檢查是否有服務更新，若是有更新，向該服務的提供者發送一個notify消息，provider接受到notify消息後，即運行NotifyListener的notify方法，執行監聽器方法。 

 

四、動態代理模式 

      Dubbo擴展jdkspi的類ExtensionLoader的Adaptive實現是典型的動態代理實現。Dubbo須要靈活地控制實現類，即在調用階段動態地根據參數決定調用哪一個實現類，因此採用先生成代理類的方法，可以作到靈活的調用。生成代理類的代碼是ExtensionLoader的createAdaptiveExtensionClassCode方法。代理類的主要邏輯是，獲取URL參數中指定參數的值做爲獲取實現類的key。