第2章 Dubbo框架內(nèi)核原理剖析

2.1 Dubbo分層架構(gòu)概述

本節(jié)我們從整體上來看看Dubbo的分層架構(gòu)設(shè)計，架構(gòu)分層是一個比較經(jīng)典的模式，比如網(wǎng)絡(luò)中的7層協(xié)議，每層執(zhí)行固定的功能，上層依賴下層提供的功能，下層的改變對上層不可見等，并且每層都是一個可被替換的組件。

圖2.1是Dubbo官方提供的Dubbo整體架構(gòu)圖。

Dubbo官方提供的該架構(gòu)圖很復(fù)雜，一開始我們沒必要深入細(xì)節(jié)，下面我們簡單講解一下其中的主要模塊。

· Service和Config層為API接口層，是為了讓Dubbo使用方方便地發(fā)布服務(wù)和引用服務(wù)；對于服務(wù)提供方來說需要實現(xiàn)服務(wù)接口，然后使用ServiceConfig API來發(fā)布該服務(wù)；對于服務(wù)消費方來說需要使用ReferenceConfig對服務(wù)接口進(jìn)行代理。Dubbo服務(wù)發(fā)布與引用方可以直接初始化配置類，也可以通過Spring配置自動生成配置類。

· 其他各層均為SPI（Service Provider Interface，服務(wù)提供者接口）層，SPI意味著下面各層都是組件化的，是可以被替換的，這也是Dubbo設(shè)計比較好的一點。Dubbo增強了JDK中提供的標(biāo)準(zhǔn)SPI功能，在Dubbo中除了Service和Config層，其他各層都是通過實現(xiàn)擴(kuò)展點接口來提供服務(wù)的；Dubbo增強的SPI增加了對擴(kuò)展點IoC和AOP的支持，一個擴(kuò)展點可以直接使用setter（）方法注入其他擴(kuò)展點，并且不會一次性實例化擴(kuò)展點的所有實現(xiàn)類，這就避免了當(dāng)擴(kuò)展點實現(xiàn)類初始化很耗時，但當(dāng)前還沒用上它的功能時仍進(jìn)行加載實例化這種浪費資源的情況；增強的SPI是在具體用某一個實現(xiàn)類的時候才對具體實現(xiàn)類進(jìn)行實例化。后續(xù)會具體講解Dubbo增強的SPI的實現(xiàn)原理。

· Proxy服務(wù)代理層：該層主要是對服務(wù)消費端使用的接口進(jìn)行代理，把本地調(diào)用透明地轉(zhuǎn)換為遠(yuǎn)程調(diào)用；另外對服務(wù)提供方的服務(wù)實現(xiàn)類進(jìn)行代理，把服務(wù)實現(xiàn)類轉(zhuǎn)換為Wrapper類，這是為了減少反射的調(diào)用，后面會具體講解。Proxy層的SPI擴(kuò)展接口為ProxyFactory，Dubbo提供的實現(xiàn)類主要有JavassistProxyFactory（默認(rèn)使用）和JdkProxyFactory，用戶可以實現(xiàn)ProxyFactory SPI接口，自定義代理服務(wù)層的實現(xiàn)。

· Registry服務(wù)注冊中心層：服務(wù)提供者啟動時會把服務(wù)注冊到服務(wù)注冊中心，消費者啟動時會去服務(wù)注冊中心獲取服務(wù)提供者的地址列表，Registry層主要功能是封裝服務(wù)地址的注冊與發(fā)現(xiàn)邏輯，擴(kuò)展接口Registry對應(yīng)的擴(kuò)展實現(xiàn)為ZookeeperRegistry、RedisRegistry、MulticastRegistry、DubboRegistry等。擴(kuò)展接口RegistryFactory對應(yīng)的擴(kuò)展接口實現(xiàn)為DubboRegistryFactory、DubboRegistryFactory、RedisRegistryFactory、ZookeeperRegistryFactory。另外，該層擴(kuò)展接口Directory實現(xiàn)類有RegistryDirectory、StaticDirectory，用來透明地把Invoker列表轉(zhuǎn)換為一個Invoker；用戶可以實現(xiàn)該層的一系列擴(kuò)展接口，自定義該層的服務(wù)實現(xiàn)。

· Cluster路由層：封裝多個服務(wù)提供者的路由規(guī)則、負(fù)載均衡、集群容錯的實現(xiàn)，并橋接服務(wù)注冊中心；擴(kuò)展接口Cluster對應(yīng)的實現(xiàn)類有FailoverCluster（失敗重試）、FailbackCluster（失敗自動恢復(fù)）、FailfastCluster（快速失敗）、FailsafeCluster（失敗安全）、ForkingCluster（并行調(diào)用）等；負(fù)載均衡擴(kuò)展接口LoadBalance對應(yīng)的實現(xiàn)類為RandomLoadBalance（隨機）、RoundRobinLoadBalance（輪詢）、LeastActiveLoadBalance（最小活躍數(shù)）、ConsistentHashLoadBalance（一致性Hash）等。用戶可以實現(xiàn)該層的一系列擴(kuò)展接口，自定義集群容錯和負(fù)載均衡策略。

· Monitor監(jiān)控層：用來統(tǒng)計RPC調(diào)用次數(shù)和調(diào)用耗時時間，擴(kuò)展接口為MonitorFactory，對應(yīng)的實現(xiàn)類為DubboMonitorFactroy。用戶可以實現(xiàn)該層的MonitorFactory擴(kuò)展接口，實現(xiàn)自定義監(jiān)控統(tǒng)計策略。

· Protocol遠(yuǎn)程調(diào)用層：封裝RPC調(diào)用邏輯，擴(kuò)展接口為Protocol，對應(yīng)實現(xiàn)有RegistryProtocol、DubboProtocol、InjvmProtocol等。

· Exchange信息交換層：封裝請求響應(yīng)模式，同步轉(zhuǎn)異步，擴(kuò)展接口為Exchanger，對應(yīng)的擴(kuò)展實現(xiàn)有HeaderExchanger等。

· Transport網(wǎng)絡(luò)傳輸層：Mina和Netty抽象為統(tǒng)一接口。擴(kuò)展接口為Channel，對應(yīng)的實現(xiàn)有NettyChannel（默認(rèn)）、MinaChannel等；擴(kuò)展接口Transporter對應(yīng)的實現(xiàn)類有GrizzlyTransporter、MinaTransporter、NettyTransporter（默認(rèn)實現(xiàn)）；擴(kuò)展接口Codec2對應(yīng)的實現(xiàn)類有DubboCodec、ThriftCodec等。

· Serialize數(shù)據(jù)序列化層：提供可以復(fù)用的一些工具，擴(kuò)展接口為Serialization，對應(yīng)的擴(kuò)展實現(xiàn)有DubboSerialization、FastJsonSerialization、Hessian2Serialization、JavaSerialization等，擴(kuò)展接口ThreadPool對應(yīng)的擴(kuò)展實現(xiàn)有FixedThreadPool、CachedThreadPool、LimitedThreadPool等。

綜上可知，Dubbo的分層架構(gòu)使得Dubbo每層的功能都是可被替換的，這使得Dubbo的擴(kuò)展性極強，上面說了那么多關(guān)于擴(kuò)展點的東西，那么什么是擴(kuò)展點呢？下面看看Dubbo擴(kuò)展點的一個簡單例子。以擴(kuò)展點Protocol為例：

擴(kuò)展點接口的類都含有@SPI注解，這里注解中的"dubbo"說明Protocol擴(kuò)展接口SPI的默認(rèn)實現(xiàn)是DubboProtocol。

如果我們想自己寫一個Protocol擴(kuò)展接口的實現(xiàn)類，那么我們需要在實現(xiàn)類所在的Jar包內(nèi)的META-INF/dubbo/目錄下創(chuàng)建一個名字為org.apache.dubbo.rpc.Protocol的文本文件，然后配置它的內(nèi)容為：

假設(shè)該實現(xiàn)類MyProtocol的內(nèi)容如下：

那么如何使用我們自定義的擴(kuò)展實現(xiàn)呢？在Dubbo配置模塊中，擴(kuò)展點均有對應(yīng)配置屬性或標(biāo)簽，如下代碼通過配置標(biāo)簽方式指定使用哪個擴(kuò)展實現(xiàn)：

注意這里的name必須與Jar包內(nèi)META-INF/dubbo/目錄下的org.apache.dubbo.rpc.Protocol文件中的等號左側(cè)的key的名字一致。