Dubbo中的設計模式

Dubbo中的設計模式

最近在看阿里開源RPC框架Dubbo的源碼，順帶梳理了一下其中用到的設計模式。下面將逐個列舉其中的設計模式，並根據本身的理解分析這樣設計的緣由和優劣。

責任鏈模式

責任鏈模式在Dubbo中發揮的做用舉足輕重，就像是Dubbo框架的骨架。Dubbo的調用鏈組織是用責任鏈模式串連起來的。責任鏈中的每一個節點實現Filter接口，而後由ProtocolFilterWrapper，將全部Filter串連起來。Dubbo的許多功能都是經過Filter擴展實現的，好比監控、日誌、緩存、安全、telnet以及RPC自己都是。若是把Dubbo比做一列火車，責任鏈就像是火車的各車箱，每一個車箱的功能不一樣。若是須要加入新的功能，增長車箱就能夠了，很是容易擴展。

觀察者模式

Dubbo中使用觀察者模式最典型的例子是RegistryService。消費者在初始化的時候回調用subscribe方法，註冊一個觀察者，若是觀察者引用的服務地址列表發生改變，就會經過NotifyListener通知消費者。此外，Dubbo的InvokerListener、ExporterListener 也實現了觀察者模式，只要實現該接口，並註冊，就能夠接收到consumer端調用refer和provider端調用export的通知。Dubbo的註冊/訂閱模型和觀察者模式就是天生一對。

修飾器模式

Dubbo中還大量用到了修飾器模式。好比ProtocolFilterWrapper類是對Protocol類的修飾。在export和refer方法中，配合責任鏈模式，把Filter組裝成責任鏈，實現對Protocol功能的修飾。其餘還有ProtocolListenerWrapper、 ListenerInvokerWrapper、InvokerWrapper等。我的感受，修飾器模式是一把雙刃劍，一方面用它能夠方便地擴展類的功能，並且對用戶無感，但另外一方面，過多地使用修飾器模式不利於理解，由於一個類可能通過層層修飾，最終的行爲已經和原始行爲偏離較大。

工廠方法模式

CacheFactory的實現採用的是工廠方法模式。CacheFactory接口定義getCache方法，而後定義一個AbstractCacheFactory抽象類實現CacheFactory，並將實際建立cache的createCache方法分離出來，並設置爲抽象方法。這樣具體cache的建立工做就留給具體的子類去完成。

抽象工廠模式

ProxyFactory及其子類是Dubbo中使用抽象工廠模式的典型例子。ProxyFactory提供兩個方法，分別用來生產Proxy和Invoker（這兩個方法簽名看起來有些矛盾，由於getProxy方法須要傳入一個Invoker對象，而getInvoker方法須要傳入一個Proxy對象，看起來會造成循環依賴，但其實兩個方式使用的場景不同）。AbstractProxyFactory實現了ProxyFactory接口，做爲具體實現類的抽象父類。而後定義了JdkProxyFactory和JavassistProxyFactory兩個具體類，分別用來生產基於jdk代理機制和基於javassist代理機制的Proxy和Invoker。

適配器模式

爲了讓用戶根據本身的需求選擇日誌組件，Dubbo自定義了本身的Logger接口，併爲常見的日誌組件（包括jcl, jdk, log4j, slf4j）提供相應的適配器。而且利用簡單工廠模式提供一個LoggerFactory，客戶能夠建立抽象的Dubbo自定義Logger，而無需關心實際使用的日誌組件類型。在LoggerFactory初始化時，客戶經過設置系統變量的方式選擇本身所用的日誌組件，這樣提供了很大的靈活性。

代理模式

Dubbo consumer使用Proxy類建立遠程服務的本地代理，本地代理實現和遠程服務同樣的接口，而且屏蔽了網絡通訊的細節，使得用戶在使用本地代理的時候，感受和使用本地服務同樣。