dubbo源碼解析-集羣容錯架構設計

前言

原本是想把整個dubbo源碼解析一次性弄完，再作成一個系列來發布的，可是正巧最近有位好朋友要去杭州面試，就和我交流了一下。本着對dubbo源碼略有心得的心態，在交流過程當中也發表了我的的一些粗劣的拙見。可是很是不幸的是，交流過程當中我這位朋友問到了幾個問題，我卻沒能回答得上，讓我感到十分慚愧。故而將原計劃提早，而且按期整理，作到按期更新一篇dubbo源碼解析，好讓本身的知識盲點儘早暴露出來。本篇講的就是dubbo的一個重要概念，集羣容錯。既然你已經在看源碼解析了，那麼我就假設你對dubbo的使用上有必定的經驗,對集羣容錯的簡單介紹。

前期鋪墊

 

 

 

 

 

官網介紹圖

這張是官網的對於集羣容錯的架構設計圖，即便你有必定的使用經驗，第一眼看到這個圖可能仍是有些懵逼。由於這個圖是從設計的角度畫出來的，而不是使用的角度。可是即便這個圖你看不懂也不影響你對本文的閱讀，可是你必需要記住三個關鍵詞，由於這三個關鍵詞接下來會貫穿全文，他們就是Directory、Router、LoadBalance。

再接下來給你們一張"地圖"，"地圖"上我已經標記了序號，再下面的源碼分析中，我也會實時提醒咱們所在的位置，以致於不會迷失方向。

 

 

 

 

 

執行時序圖

 

環境準備

既然是集羣，那麼首先要啓動兩個Provider，我這裏是一個虛擬機，一個本地的方式，由於環境準備不是本文重點，所以略過。本文所用到的源碼是2.5.4版本，能夠在guihub上找到。

正式發車

此次示例選用的源碼用dubbo-demo的dubbo-demo-consumer，若是對dubbo原理有些簡單的瞭解就知道，他給接口注入的不是接口的實現類，而是一個代理類，以下圖：

 

 

 

 

接着天然是到了代理類的invoke方法裏，從圖中咱們也能夠看出，他用的是jdk的動態代理。

 

 

 

 

下面要開始緊盯着地圖了，他如今就要開始執行地圖中的序號1，此時咱們抵達MockClusterInvoker這個類。

 

 

 

 

執行invoke就要開始進入到集羣，也就是Cluster，如今第一個關鍵詞Directory已經浮出水面了。

 

 

 

 

 

 

 

 

如今到了AbstractDirectory，也就是序號3。

 

 

 

 

這個methodInvokerMap也比較重要，後面的文章會講一下這個，可是咱們這部分代碼就能夠從出，他是要從methodInvokerMap中取出invokers如圖所示：

 

 

 

 

 

 

 

 

將invokers返回後(序號5)，下面來到了第二個關鍵詞，Router，開始進入路由，如今咱們到了序號6，此時到了MockInvokersSelector類，不要看類名和Router沒有關係，其實他是Router接口的實現類，從官網的介紹圖中咱們也能夠看到Router分爲Script和Condition兩種，翻譯過來也就是腳本路由和條件路由這個後面再詳細介紹，本篇主要介紹總體架構。

 

 

 

 

源碼的命名是很規範的，從getNormalInvokers就能夠得知，他是要拿到能正常執行的invokers，並將其返回，也就是序號7。

 

 

 

 

 

 

 

 

這個時候咱們再次回到了AbstractClusterInvoker這個類，咱們先不急着往下走，先適時作個總結。由於三個關鍵詞，如今都已經出現了兩個，那這個時候要回憶一下上面這些步驟，作一個總結。上面出現的這兩個關鍵詞，其實無非就是作兩件事：

• 在Directory中找出本次集羣中的所有invokers
• 在Router中,將上一步的所有invokers挑選出能正常執行的invokers

 

對應到"地圖"，也就是序號5和序號7。(再次提醒，必定要緊跟地圖的序號，否則很容易迷失方向)。

從上面步驟咱們也知道，已經挑選出能正常執行的invokers了，可是假如2個作集羣，可是這兩個都是正常的，我到底要執行哪個呢？帶着這個問題，咱們繼續往下看。

 

 

 

 

 

 

 

 

根據官網的描述：

在集羣調用失敗時，Dubbo 提供了多種容錯方案，缺省爲 failover 重試。

 

因此這個時候是到了FailoverClusterInvoker類，可是若是你配置的是Failover Cluster（快速失敗），Failsafe Cluster（失敗安全），Failback Cluster（失敗自動恢復），Forking Cluster（並行調用多個服務器，只要一個成功即返回），Broadcast Cluster（廣播調用全部提供者，逐個調用，任意一臺報錯則報錯）他也會到達相應的類。

 

 

 

 

 

 

 

 

下面就要開始第三個關鍵詞浮出水面，也就是LoadBalance(負載均衡)，此時的位置是序號11，仔細留心源碼的註釋，其實這裏能夠出一個面試題，好比：

dubbo的負載均衡策略是怎麼樣的?

 

爲何這能夠做爲一道面試題，由於他能夠區分三個層次的人。

• 若是是沒有使用過，或者一直停留在使用層次的人，確定不會留級到這個負載均衡策略；
• 根據官網介紹在集羣負載均衡時，Dubbo 提供了多種均衡策略，缺省爲 random 隨機調用。若是能回答出，缺省爲隨機調用的，說明仍是有必定的使用經驗，留意到官網的介紹；
• 若是能回答出，缺省爲隨機調用，可是若是集羣的數量爲2，那麼將退化成輪詢。若是能回答到這個，那這我的就是有必定追求，不只留心文檔介紹，並且是看過源碼，注意細節的人(好比本文做者肥朝 ^_^ )。

 

根據前面咱們知道，如今已經有兩個備選的invokers，可是究竟哪個能執行，這個須要LoadBalance來決定。這裏涉及到了必定的算法，後面我也會有一篇文章加以介紹。劇透一下，這個在2.5.4的版本中，這個算法仍是存在一些小的bug，此時咱們的位置是序號13。

 

 

 

 

 

 

 

 

到達終點站，咱們回憶總結一下，文初提到的三個關鍵詞，在這個集羣容錯的總體架構過程當中，dubbo究竟作了什麼？其實也就是三件事：

• 在Directory中找出本次集羣中的所有invokers
• 在Router中，將上一步的所有invokers挑選出能正常執行的invokers
• 在LoadBalance中，將上一步的能正常的執行invokers中，根據配置的負載均衡策略,挑選出須要執行的invoker