阿里巴巴SOA服務化治理方案的核心框架-Dubbo
阿新 • • 發佈：2019-01-21
一、簡述
Dubbo是阿里巴巴SOA服務化治理方案的核心框架，每天為2,000+個服務提供3,000,000,000+次訪問量支援，並被廣泛應用於阿里巴巴集團的各成員站點：
Dubbo的文件：http://alibaba.github.io/dubbo-doc-static/Home-zh.htm
http://alibaba.github.io/dubbo-doc-static/Download-zh.htm
參考部落格：http://zy116494718.iteye.com/blog/1830138
*擴充套件指導：http://alibaba.github.io/dubbo-doc-static/Developer+Guide-zh.htm#DeveloperGuide-zh-%E5%8D%8F%E8%AE%AE%E6%89%A9%E5%B1%95
二、如何更好地學習dubbo原始碼?
Dubbo的官方首頁在這裡：http://code.alibabatech.com/wiki/display/dubbo/Home
很榮幸，作為這樣一款業界使用率和好評率出眾的RPC框架的維護者，今天這個文章主要是想幫助那些熱愛開源的同學，更好的來研究dubbo的原始碼。
一、Dubbo整體架構
1、Dubbo與Spring的整合
Dubbo在使用上可以做到非常簡單，不管是Provider還是Consumer都可以通過Spring的配置檔案進行配置，配置完之後，就可以像使用springbean一樣進行服務暴露和呼叫了，完全看不到dubboapi的存在。這是因為dubbo使用了spring提供的可擴充套件Schema自定義配置支援。在spring配置檔案中，可以像、這樣進行配置。META-INF下的spring.handlers檔案中指定了dubbo的xml解析類：DubboNamespaceHandler。像前面的被解析成ServiceConfig，被解析成ReferenceConfig等等。
2、jdkspi擴充套件
由於Dubbo是開源框架，必須要提供很多的可擴充套件點。Dubbo是通過擴充套件jdkspi機制來實現可擴充套件的。具體來說，就是在META-INF目錄下，放置檔名為介面全稱，檔案中為key、value鍵值對，value為具體實現類的全類名，key為標誌值。由於dubbo使用了url匯流排的設計，即很多引數通過URL物件來傳遞，在實際中，具體要用到哪個值，可以通過url中的引數值來指定。
Dubbo對spi的擴充套件是通過ExtensionLoader來實現的，檢視ExtensionLoader的原始碼，可以看到Dubbo對jdkspi做了三個方面的擴充套件：
（1）jdkspi僅僅通過介面類名獲取所有實現，而ExtensionLoader則通過介面類名和key值獲取一個實現；
（2）Adaptive實現，就是生成一個代理類，這樣就可以根據實際呼叫時的一些引數動態決定要呼叫的類了。
（3）自動包裝實現，這種實現的類一般是自動啟用的，常用於包裝類，比如Protocol的兩個實現類：ProtocolFilterWrapper、ProtocolListenerWrapper。
3、url匯流排設計
Dubbo為了使得各層解耦，採用了url匯流排的設計。我們通常的設計會把層與層之間的互動引數做成Model，這樣層與層之間溝通成本比較大，擴充套件起來也比較麻煩。因此，Dubbo把各層之間的通訊都採用url的形式。比如，註冊中心啟動時，引數的url為：
registry://0.0.0.0:9090?codec=registry&transporter=netty
這就表示當前是註冊中心，繫結到所有ip，埠是9090，解析器型別是registry，使用的底層網路通訊框架是netty。
二、Dubbo啟動過程
Dubbo分為註冊中心、服務提供者(provider)、服務消費者(consumer)三個部分。
1、註冊中心啟動過程
註冊中心的啟動過程，主要看兩個類：RegistrySynchronizer、RegistryReceiver，兩個類的初始化方法都是start。
RegistrySynchronizer的start方法：
（1）把所有配置資訊load到記憶體；
（2）把當前註冊中心資訊儲存到資料庫；
（3）啟動5個定時器。
5個定時器的功能是：
（1）AutoRedirectTask，自動重定向定時器。預設1小時執行1次。如果當前註冊中心的連線數高於平均值的1.2倍，則將多出來的連線數重定向到其他註冊中心上，以達到註冊中心叢集的連線數均衡。
（2）DirtyCheckTask，髒資料檢查定時器。作用是：分別檢查快取provider、資料庫provider、快取consumer、資料庫consumer的資料，清除髒資料；清理不存活的provider和consumer資料；對於快取中的存在的provider或consumer而資料庫不存在，重新註冊和訂閱。
（3）ChangedClearTask，changes變更表的定時清理任務。作用是讀取changes表，清除過期資料。
（4）AlivedCheckTask，註冊中心存活狀態定時檢查，會定時更新registries表的expire欄位，用以判斷註冊中心的存活狀態。如果有新的註冊中心，傳送同步訊息，將當前所有註冊中心的地址通知到所有客戶端。
（5）ChangedCheckTask，變更檢查定時器。檢查changes表的變更，檢查型別包括：引數覆蓋變更、路由變更、服務消費者變更、權重變更、負載均衡變更。
RegistryReceiver的start方法：啟動註冊中心服務。預設使用netty框架，繫結本機的9090埠。最後啟動服務的過程是在NettyServer來完成的。接收訊息時，拋開dubbo協議的解碼器，呼叫類的順序是
檢視文字列印
NettyHandler-》NettyServer-》MultiMessageHandler-》HeartbeatHandler-》AllDispatcher-》
DecodeHandler-》HeaderExchangeHandler-》RegistryReceiver-》RegistryValidator-》RegistryFailover-》RegistryExecutor。
2、provider啟動過程
provider的啟動過程是從ServiceConfig的export方法開始進行的，具體步驟是：
（1）進行本地jvm的暴露，不開放任何埠，以提供injvm這種形式的呼叫，這種呼叫只是本地呼叫，不涉及程序間通訊。
（2）呼叫RegistryProtocol的export。
（3）呼叫DubboProtocol的export，預設開啟20880埠，用以提供接收consumer的遠端呼叫服務。
（4）通過新建RemoteRegistry來建立與註冊中心的連線。
（5）將服務地址註冊到註冊中心。
（6）去註冊中心訂閱自己的服務。
3、consumer啟動過程
consumer的啟動過程是通過ReferenceConfig的get方法進行的，具體步驟是：
（1）通過新建RemoteRegistry來建立與註冊中心的連線。
（2）新建RegistryDirectory並向註冊中心訂閱服務，RegistryDirectory用以維護註冊中心獲取的服務相關資訊。
（3）建立代理類，發起consumer遠端呼叫時，實際呼叫的是InvokerInvocationHandler。
三、實際呼叫過程
consumer端發起呼叫時，實際呼叫經過的類是：
1、consumer:
檢視文字列印
InvokerInvocationHandler-》MockClusterInvoker(如果配置了Mock，則直接呼叫本地Mock類)-》FailoverClusterInvoker(負載均衡，容錯機制，預設在發生錯誤的情況下，進行兩次重試)-》RegistryDirectory$InvokerDelegete-》ConsumerContextFilter-》FutureFilter->DubboInvoker
2、provider:
檢視文字列印
NettyServer-》MultiMessageHandler-》HeartbeatHandler-》AllDispatcher-》DecodeHandler-》HeaderExchangeHandler-》DubboProtocol.requestHandler-》EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》TimeoutFilter-》MonitorFilter-》TraceFilter-》實際service。
四、Dubbo使用的設計模式
1、工廠模式
ServiceConfig中有個欄位，程式碼是這樣的：
檢視文字列印
private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
Dubbo裡有很多這種程式碼。這也是一種工廠模式，只是實現類的獲取採用了jdkspi的機制。這麼實現的優點是可擴充套件性強，想要擴充套件實現，只需要在classpath下增加個檔案就可以了，程式碼零侵入。另外，像上面的Adaptive實現，可以做到呼叫時動態決定呼叫哪個實現，但是由於這種實現採用了動態代理，會造成程式碼除錯比較麻煩，需要分析出實際呼叫的實現類。
2、裝飾器模式
Dubbo在啟動和呼叫階段都大量使用了裝飾器模式。以Provider提供的呼叫鏈為例，具體的呼叫鏈程式碼是在ProtocolFilterWrapper的buildInvokerChain完成的，具體是將註解中含有group=provider的Filter實現，按照order排序，最後的呼叫順序是
檢視文字列印
EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》
TimeoutFilter-》MonitorFilter-》TraceFilter。
更確切地說，這裡是裝飾器和責任鏈模式的混合使用。例如，EchoFilter的作用是判斷是否是回聲測試請求，是的話直接返回內容，這是一種責任鏈的體現。而像ClassLoaderFilter則只是在主功能上添加了功能，更改當前執行緒的ClassLoader，這是典型的裝飾器模式。
3、觀察者模式
Dubbo的provider啟動時，需要與註冊中心互動，先註冊自己的服務，再訂閱自己的服務，訂閱時，採用了觀察者模式，開啟一個listener。註冊中心會每5秒定時檢查是否有服務更新，如果有更新，向該服務的提供者傳送一個notify訊息，provider接受到notify訊息後，即執行NotifyListener的notify方法，執行監聽器方法。
4、動態代理模式
Dubbo擴充套件jdkspi的類ExtensionLoader的Adaptive實現是典型的動態代理實現。Dubbo需要靈活地控制實現類，即在呼叫階段動態地根據引數決定呼叫哪個實現類，所以採用先生成代理類的方法，能夠做到靈活的呼叫。生成代理類的程式碼是ExtensionLoader的createAdaptiveExtensionClassCode方法。代理類的主要邏輯是，獲取URL引數中指定引數的值作為獲取實現類的key。
三、配置方式積累
Zookeeper單機配置:
<dubbo:registry address="zookeeper://10.20.153.10:2181" />
Or:
<dubbo:registry protocol="zookeeper" address="10.20.153.10:2181" />
Zookeeper叢集配置:
<dubbo:registry address="zookeeper://10.20.153.10:2181?backup=10.20.153.11:2181,10.20.153.12:2181" />
Or:
<dubbo:registry protocol="zookeeper" address="10.20.153.10:2181,10.20.153.11:2181,10.20.153.12:2181" />
同一Zookeeper，分成多組註冊中心:
<dubbo:registry id="chinaRegistry" protocol="zookeeper" address="10.20.153.10:2181" group="china" />
<dubbo:registry id="intlRegistry" protocol="zookeeper" address="10.20.153.10:2181" group="intl" />
四、管理控制檯
1、下載war包（dubbo-admin-2.4.1.war）
2、修改配置檔案：
webapps/ROOT/WEB-INF/dubbo.properties
配置資訊如下：
dubbo.registry.address=zookeeper://127.0.0.1:2181
dubbo.admin.root.password=root
dubbo.admin.guest.password=guest
這邊使用的是zookeeper的註冊中心。
登入密碼為root/root
五、dubbo分散式部署
因dubbo是基於IP計算的 故，同一份程式部署到不同的機器沒問題的，但有個問題是同一臺機器上面安裝了2個Tomcat 分別部署一份相同的程式，這樣就會有問題，解決方案如下：
<dubbo:protocol name="dubbo" port="20880" />
修改成不同的埠即可，若怕部署繁瑣，埠可以指定為-1，dubbo會自動分配埠，從20880開始累加，每次加1，如：20880、20881、20882 這樣，有個缺點就是，若需要直連時，埠不固定 就是一個麻煩的事情了，所以不考慮直連的話就用-1方式解決，有可能直連的話 就用配置檔案方式，每份程式單獨配置自己的埠。
Dubbo是阿里巴巴SOA服務化治理方案的核心框架，每天為2,000+個服務提供3,000,000,000+次訪問量支援，並被廣泛應用於阿里巴巴集團的各成員站點：
Dubbo的文件：http://alibaba.github.io/dubbo-doc-static/Home-zh.htm
http://alibaba.github.io/dubbo-doc-static/Download-zh.htm
參考部落格：http://zy116494718.iteye.com/blog/1830138
*擴充套件指導：http://alibaba.github.io/dubbo-doc-static/Developer+Guide-zh.htm#DeveloperGuide-zh-%E5%8D%8F%E8%AE%AE%E6%89%A9%E5%B1%95
二、如何更好地學習dubbo原始碼?
Dubbo的官方首頁在這裡：http://code.alibabatech.com/wiki/display/dubbo/Home
很榮幸，作為這樣一款業界使用率和好評率出眾的RPC框架的維護者，今天這個文章主要是想幫助那些熱愛開源的同學，更好的來研究dubbo的原始碼。
一、Dubbo整體架構
1、Dubbo與Spring的整合
Dubbo在使用上可以做到非常簡單，不管是Provider還是Consumer都可以通過Spring的配置檔案進行配置，配置完之後，就可以像使用springbean一樣進行服務暴露和呼叫了，完全看不到dubboapi的存在。這是因為dubbo使用了spring提供的可擴充套件Schema自定義配置支援。在spring配置檔案中，可以像、這樣進行配置。META-INF下的spring.handlers檔案中指定了dubbo的xml解析類：DubboNamespaceHandler。像前面的被解析成ServiceConfig，被解析成ReferenceConfig等等。
2、jdkspi擴充套件
由於Dubbo是開源框架，必須要提供很多的可擴充套件點。Dubbo是通過擴充套件jdkspi機制來實現可擴充套件的。具體來說，就是在META-INF目錄下，放置檔名為介面全稱，檔案中為key、value鍵值對，value為具體實現類的全類名，key為標誌值。由於dubbo使用了url匯流排的設計，即很多引數通過URL物件來傳遞，在實際中，具體要用到哪個值，可以通過url中的引數值來指定。
Dubbo對spi的擴充套件是通過ExtensionLoader來實現的，檢視ExtensionLoader的原始碼，可以看到Dubbo對jdkspi做了三個方面的擴充套件：
（1）jdkspi僅僅通過介面類名獲取所有實現，而ExtensionLoader則通過介面類名和key值獲取一個實現；
（2）Adaptive實現，就是生成一個代理類，這樣就可以根據實際呼叫時的一些引數動態決定要呼叫的類了。
（3）自動包裝實現，這種實現的類一般是自動啟用的，常用於包裝類，比如Protocol的兩個實現類：ProtocolFilterWrapper、ProtocolListenerWrapper。
3、url匯流排設計
Dubbo為了使得各層解耦，採用了url匯流排的設計。我們通常的設計會把層與層之間的互動引數做成Model，這樣層與層之間溝通成本比較大，擴充套件起來也比較麻煩。因此，Dubbo把各層之間的通訊都採用url的形式。比如，註冊中心啟動時，引數的url為：
registry://0.0.0.0:9090?codec=registry&transporter=netty
這就表示當前是註冊中心，繫結到所有ip，埠是9090，解析器型別是registry，使用的底層網路通訊框架是netty。
二、Dubbo啟動過程
Dubbo分為註冊中心、服務提供者(provider)、服務消費者(consumer)三個部分。
1、註冊中心啟動過程
註冊中心的啟動過程，主要看兩個類：RegistrySynchronizer、RegistryReceiver，兩個類的初始化方法都是start。
RegistrySynchronizer的start方法：
（1）把所有配置資訊load到記憶體；
（2）把當前註冊中心資訊儲存到資料庫；
（3）啟動5個定時器。
5個定時器的功能是：
（1）AutoRedirectTask，自動重定向定時器。預設1小時執行1次。如果當前註冊中心的連線數高於平均值的1.2倍，則將多出來的連線數重定向到其他註冊中心上，以達到註冊中心叢集的連線數均衡。
（2）DirtyCheckTask，髒資料檢查定時器。作用是：分別檢查快取provider、資料庫provider、快取consumer、資料庫consumer的資料，清除髒資料；清理不存活的provider和consumer資料；對於快取中的存在的provider或consumer而資料庫不存在，重新註冊和訂閱。
（3）ChangedClearTask，changes變更表的定時清理任務。作用是讀取changes表，清除過期資料。
（4）AlivedCheckTask，註冊中心存活狀態定時檢查，會定時更新registries表的expire欄位，用以判斷註冊中心的存活狀態。如果有新的註冊中心，傳送同步訊息，將當前所有註冊中心的地址通知到所有客戶端。
（5）ChangedCheckTask，變更檢查定時器。檢查changes表的變更，檢查型別包括：引數覆蓋變更、路由變更、服務消費者變更、權重變更、負載均衡變更。
RegistryReceiver的start方法：啟動註冊中心服務。預設使用netty框架，繫結本機的9090埠。最後啟動服務的過程是在NettyServer來完成的。接收訊息時，拋開dubbo協議的解碼器，呼叫類的順序是
檢視文字列印
NettyHandler-》NettyServer-》MultiMessageHandler-》HeartbeatHandler-》AllDispatcher-》
DecodeHandler-》HeaderExchangeHandler-》RegistryReceiver-》RegistryValidator-》RegistryFailover-》RegistryExecutor。
2、provider啟動過程
provider的啟動過程是從ServiceConfig的export方法開始進行的，具體步驟是：
（1）進行本地jvm的暴露，不開放任何埠，以提供injvm這種形式的呼叫，這種呼叫只是本地呼叫，不涉及程序間通訊。
（2）呼叫RegistryProtocol的export。
（3）呼叫DubboProtocol的export，預設開啟20880埠，用以提供接收consumer的遠端呼叫服務。
（4）通過新建RemoteRegistry來建立與註冊中心的連線。
（5）將服務地址註冊到註冊中心。
（6）去註冊中心訂閱自己的服務。
3、consumer啟動過程
consumer的啟動過程是通過ReferenceConfig的get方法進行的，具體步驟是：
（1）通過新建RemoteRegistry來建立與註冊中心的連線。
（2）新建RegistryDirectory並向註冊中心訂閱服務，RegistryDirectory用以維護註冊中心獲取的服務相關資訊。
（3）建立代理類，發起consumer遠端呼叫時，實際呼叫的是InvokerInvocationHandler。
三、實際呼叫過程
consumer端發起呼叫時，實際呼叫經過的類是：
1、consumer:
檢視文字列印
InvokerInvocationHandler-》MockClusterInvoker(如果配置了Mock，則直接呼叫本地Mock類)-》FailoverClusterInvoker(負載均衡，容錯機制，預設在發生錯誤的情況下，進行兩次重試)-》RegistryDirectory$InvokerDelegete-》ConsumerContextFilter-》FutureFilter->DubboInvoker
2、provider:
檢視文字列印
NettyServer-》MultiMessageHandler-》HeartbeatHandler-》AllDispatcher-》DecodeHandler-》HeaderExchangeHandler-》DubboProtocol.requestHandler-》EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》TimeoutFilter-》MonitorFilter-》TraceFilter-》實際service。
四、Dubbo使用的設計模式
1、工廠模式
ServiceConfig中有個欄位，程式碼是這樣的：
檢視文字列印
private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
Dubbo裡有很多這種程式碼。這也是一種工廠模式，只是實現類的獲取採用了jdkspi的機制。這麼實現的優點是可擴充套件性強，想要擴充套件實現，只需要在classpath下增加個檔案就可以了，程式碼零侵入。另外，像上面的Adaptive實現，可以做到呼叫時動態決定呼叫哪個實現，但是由於這種實現採用了動態代理，會造成程式碼除錯比較麻煩，需要分析出實際呼叫的實現類。
2、裝飾器模式
Dubbo在啟動和呼叫階段都大量使用了裝飾器模式。以Provider提供的呼叫鏈為例，具體的呼叫鏈程式碼是在ProtocolFilterWrapper的buildInvokerChain完成的，具體是將註解中含有group=provider的Filter實現，按照order排序，最後的呼叫順序是
檢視文字列印
EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》
TimeoutFilter-》MonitorFilter-》TraceFilter。
更確切地說，這裡是裝飾器和責任鏈模式的混合使用。例如，EchoFilter的作用是判斷是否是回聲測試請求，是的話直接返回內容，這是一種責任鏈的體現。而像ClassLoaderFilter則只是在主功能上添加了功能，更改當前執行緒的ClassLoader，這是典型的裝飾器模式。
3、觀察者模式
Dubbo的provider啟動時，需要與註冊中心互動，先註冊自己的服務，再訂閱自己的服務，訂閱時，採用了觀察者模式，開啟一個listener。註冊中心會每5秒定時檢查是否有服務更新，如果有更新，向該服務的提供者傳送一個notify訊息，provider接受到notify訊息後，即執行NotifyListener的notify方法，執行監聽器方法。
4、動態代理模式
Dubbo擴充套件jdkspi的類ExtensionLoader的Adaptive實現是典型的動態代理實現。Dubbo需要靈活地控制實現類，即在呼叫階段動態地根據引數決定呼叫哪個實現類，所以採用先生成代理類的方法，能夠做到靈活的呼叫。生成代理類的程式碼是ExtensionLoader的createAdaptiveExtensionClassCode方法。代理類的主要邏輯是，獲取URL引數中指定引數的值作為獲取實現類的key。
三、配置方式積累
Zookeeper單機配置:
<dubbo:registry address="zookeeper://10.20.153.10:2181" />
Or:
<dubbo:registry protocol="zookeeper" address="10.20.153.10:2181" />
Zookeeper叢集配置:
<dubbo:registry address="zookeeper://10.20.153.10:2181?backup=10.20.153.11:2181,10.20.153.12:2181" />
Or:
<dubbo:registry protocol="zookeeper" address="10.20.153.10:2181,10.20.153.11:2181,10.20.153.12:2181" />
同一Zookeeper，分成多組註冊中心:
<dubbo:registry id="chinaRegistry" protocol="zookeeper" address="10.20.153.10:2181" group="china" />
<dubbo:registry id="intlRegistry" protocol="zookeeper" address="10.20.153.10:2181" group="intl" />
四、管理控制檯
1、下載war包（dubbo-admin-2.4.1.war）
2、修改配置檔案：
webapps/ROOT/WEB-INF/dubbo.properties
配置資訊如下：
dubbo.registry.address=zookeeper://127.0.0.1:2181
dubbo.admin.root.password=root
dubbo.admin.guest.password=guest
這邊使用的是zookeeper的註冊中心。
登入密碼為root/root
五、dubbo分散式部署
因dubbo是基於IP計算的 故，同一份程式部署到不同的機器沒問題的，但有個問題是同一臺機器上面安裝了2個Tomcat 分別部署一份相同的程式，這樣就會有問題，解決方案如下：
<dubbo:protocol name="dubbo" port="20880" />
修改成不同的埠即可，若怕部署繁瑣，埠可以指定為-1，dubbo會自動分配埠，從20880開始累加，每次加1，如：20880、20881、20882 這樣，有個缺點就是，若需要直連時，埠不固定 就是一個麻煩的事情了，所以不考慮直連的話就用-1方式解決，有可能直連的話 就用配置檔案方式，每份程式單獨配置自己的埠。