本來是想把整個dubbo原始碼解析一次性弄完,再做成乙個系列來發布的,但是正巧最近有位好朋友要去杭州面試,就和我交流了一下.本著對dubbo原始碼略有心得的心態,在交流過程中也發表了個人的一些粗劣的拙見.但是非常不幸的是,交流過程中我這位朋友問到了幾個問題,我卻沒能回答得上,讓我感到十分慚愧.故而將原計畫提前,並且定期整理,做到定期更新一篇dubbo原始碼解析.好讓自己的知識盲點盡早暴露出來.本篇講的就是dubbo的乙個重要概念,集群容錯.既然你已經在看原始碼解析了,那麼我就假設你對dubbo的使用上有一定的經驗,並且看過了dubbo的官網的對集群容錯的簡單介紹
所以本篇嘗試改變之前的風格,總結起來就是先總體,後區域性.也就是先把需要注意的概念先丟擲來,把整體架構圖先畫出來.讓讀者拿著"地圖"跟著我的腳步,並且每一步我都提醒,現在我們在哪,我們下一步要做什麼,這樣才不會迷失方向.
既然是集群,那麼首先要啟動兩個provider,我這裡是乙個虛擬機器,乙個本地的方式,因為環境準備不是本文重點,因此略過.本文所用到的原始碼是2.5.4版本,可以在guihub上找到.
正式發車
這次示例選用的原始碼用dubbo-demo的dubbo-demo-consumer,如果對dubbo原理有些簡單的了解就知道,他給介面注入的不是介面的實現類,而是乙個**類,如下圖
接著自然是到了**類的invoke方法裡,從圖中我們也可以看出,他用的是jdk的動態**
下面要開始緊盯著地圖了,他現在就要開始執行地圖中的序號1,此時我們抵達mockclusterinvoker這個類
現在到了abstractdirectory,也就是序號3
這個methodinvokermap也比較重要,後面的文章會講一下這個,但是我們這部分**就可以從出,他是要從methodinvokermap中取出invokers如圖所示
原始碼的命名是很規範的,從getnormalinvokers就可以得知,他是要拿到能正常執行的invokers,並將其返回.也就是序號7
對應到"地圖",也就是序號5和序號7.(再次提醒,一定要緊跟地圖的序號,不然很容易迷失方向)
從上面步驟我們也知道,已經挑選出能正常執行的invokers了,但是假如2個做集群,但是這兩個都是正常的,我到底要執行哪乙個呢?帶著這個問題,我們繼續往下看
根據官網的描述
在集群呼叫失敗時，dubbo 提供了多種容錯方案，預設為 failover 重試。所以這個時候是到了
failoverclusterinvoker類,但是如果你配置的是failover cluster(快速失敗),failsafe cluster(失敗安全),failback cluster(失敗自動恢復),forking cluster(並行呼叫多個伺服器，只要乙個成功即返回),broadcast cluster(廣播呼叫所有提供者，逐個呼叫，任意一台報錯則報錯)他也會到達相應的類
根據前面我們知道,現在已經有兩個備選的invokers,但是究竟哪乙個能執行,這個需要loadbalance來決定.這裡涉及到了一定的演算法,後面我也會有一篇文章加以介紹.劇透一下,這個在2.5.4的版本中,這個演算法還是存在一些小的bug,此時我們的位置是序號13
dubbo原始碼分析之集群容錯failover 13
在集中式環境中服務的機器臺只有一台，這樣對於服務不僅存在服務單點故障問題而且還存在流量問題。為了解決這個問題，就引入的分布式與集群概念。分布式 乙個業務分拆多個子業務，部署在不同的伺服器上 集群 同乙個業務，部署在多個伺服器上 當請求來臨時，如何從多個伺服器中，選擇乙個有效 合適的伺服器，這個集群所...
dubbo原始碼分析13 之 集群容錯 Invoke
在集中式環境中服務的機器臺只有一台，這樣對於服務不僅存在服務單點故障問題而且還存在流量問題。為了解決這個問題，就引入的分布式與集群概念。分布式 乙個業務分拆多個子業務，部署在不同的伺服器上 集群 同乙個業務，部署在多個伺服器上 當請求來臨時，如何從多個伺服器中，選擇乙個有效 合適的伺服器，這個集群所...
Dubbo 集群容錯
在進行系統設計時候，不僅要考慮正常邏輯該如何走，還要考慮異常邏輯。dubbo中當服務消費方呼叫服務提供方的服務出現錯誤時候，提供了多種容錯方案，預設為 failover 重試。重試。當服務消費方呼叫服務提供者失敗後自動切換，重試其它服務提供者。這通常用於讀操作或者具有冪等的寫操作，需要注意的是重試會...