前言
本來是想把整個dubbo源碼解析一次性弄完，再做成一個系列來發布的，但是正巧最近有位好朋友要去杭州面試，就和我交流了一下。本着對dubbo源碼略有心得的心態，在交流過程中也發表了個人的一些粗劣的拙見。但是非常不幸的是，交流過程中我這位朋友問到了幾個問題，我卻沒能回答得上，讓我感到十分慚愧。故而將原計劃提前，並且定期整理，做到定期更新一篇dubbo源碼解析，好讓自己的知識盲點儘早暴露出來。本篇講的就是dubbo的一個重要概念，集羣容錯。既然你已經在看源碼解析了，那麼我就假設你對dubbo的使用上有一定的經驗,對集羣容錯的簡單介紹。
前期鋪墊
圖片描述(最多50字)
官網介紹圖
這張是官網的對於集羣容錯的架構設計圖，即使你有一定的使用經驗，第一眼看到這個圖可能還是有些懵逼。因爲這個圖是從設計的角度畫出來的，而不是使用的角度。但是即使這個圖你看不懂也不影響你對本文的閱讀，但是你必須要記住三個關鍵詞，因爲這三個關鍵詞接下來會貫穿全文，他們就是Directory、Router、LoadBalance。
再接下來給大家一張"地圖"，"地圖"上我已經標記了序號，再下面的源碼分析中，我也會實時提醒我們所在的位置，以至於不會迷失方向。
圖片描述(最多50字)
執行時序圖
環境準備
既然是集羣，那麼首先要啓動兩個Provider，我這裏是一個虛擬機，一個本地的方式，因爲環境準備不是本文重點，因此略過。本文所用到的源碼是2.5.4版本，可以在guihub上找到。
正式發車
這次示例選用的源碼用dubbo-demo的dubbo-demo-consumer，如果對dubbo原理有些簡單的瞭解就知道，他給接口注入的不是接口的實現類，而是一個代理類，如下圖：
圖片描述(最多50字)
接着自然是到了代理類的invoke方法裏，從圖中我們也可以看出，他用的是jdk的動態代理。
圖片描述(最多50字)
下面要開始緊盯着地圖了，他現在就要開始執行地圖中的序號1，此時我們抵達MockClusterInvoker這個類。
圖片描述(最多50字)
執行invoke就要開始進入到集羣，也就是Cluster，現在第一個關鍵詞Directory已經浮出水面了。
圖片描述(最多50字)
圖片描述(最多50字)
現在到了AbstractDirectory，也就是序號3。
圖片描述(最多50字)
這個methodInvokerMap也比較重要，後面的文章會講一下這個，但是我們這部分代碼就可以從出，他是要從methodInvokerMap中取出invokers如圖所示：
圖片描述(最多50字)
圖片描述(最多50字)
將invokers返回後(序號5)，下面來到了第二個關鍵詞，Router，開始進入路由，現在我們到了序號6，此時到了MockInvokersSelector類，不要看類名和Router沒有關係，其實他是Router接口的實現類，從官網的介紹圖中我們也可以看到Router分爲Script和Condition兩種，翻譯過來也就是腳本路由和條件路由這個後面再詳細介紹，本篇主要介紹整體架構。
圖片描述(最多50字)
源碼的命名是很規範的，從getNormalInvokers就可以得知，他是要拿到能正常執行的invokers，並將其返回，也就是序號7。
圖片描述(最多50字)
圖片描述(最多50字)
這個時候我們再次回到了AbstractClusterInvoker這個類，我們先不急着往下走，先適時做個總結。因爲三個關鍵詞，現在都已經出現了兩個，那這個時候要回憶一下上面這些步驟，做一個總結。上面出現的這兩個關鍵詞，其實無非就是做兩件事：
在Directory中找出本次集羣中的全部invokers
在Router中,將上一步的全部invokers挑選出能正常執行的invokers
對應到"地圖"，也就是序號5和序號7。(再次提醒，一定要緊跟地圖的序號，不然很容易迷失方向)。
從上面步驟我們也知道，已經挑選出能正常執行的invokers了，但是假如2個做集羣，但是這兩個都是正常的，我到底要執行哪一個呢？帶着這個問題，我們繼續往下看。
圖片描述(最多50字)
圖片描述(最多50字)
根據官網的描述：
在集羣調用失敗時，Dubbo 提供了多種容錯方案，缺省爲 failover 重試。
所以這個時候是到了FailoverClusterInvoker類，但是如果你配置的是Failover Cluster（快速失敗），Failsafe Cluster（失敗安全），Failback Cluster（失敗自動恢復），Forking Cluster（並行調用多個服務器，只要一個成功即返回），Broadcast Cluster（廣播調用所有提供者，逐個調用，任意一臺報錯則報錯）他也會到達相應的類。
圖片描述(最多50字)
圖片描述(最多50字)
下面就要開始第三個關鍵詞浮出水面，也就是LoadBalance(負載均衡)，此時的位置是序號11，仔細留心源碼的註釋，其實這裏可以出一個面試題，比如：
dubbo的負載均衡策略是怎麼樣的?
爲什麼這可以作爲一道面試題，因爲他可以區分三個層次的人。
如果是沒有使用過，或者一直停留在使用層次的人，肯定不會留級到這個負載均衡策略；
根據官網介紹在集羣負載均衡時，Dubbo 提供了多種均衡策略，缺省爲 random 隨機調用。如果能回答出，缺省爲隨機調用的，說明還是有一定的使用經驗，留意到官網的介紹；
如果能回答出，缺省爲隨機調用，但是如果集羣的數量爲2，那麼將退化成輪詢。如果能回答到這個，那這個人就是有一定追求，不僅留心文檔介紹，而且是看過源碼，注意細節的人(比如本文作者肥朝 ^_^ )。
根據前面我們知道，現在已經有兩個備選的invokers，但是究竟哪一個能執行，這個需要LoadBalance來決定。這裏涉及到了一定的算法，後面我也會有一篇文章加以介紹。劇透一下，這個在2.5.4的版本中，這個算法還是存在一些小的bug，此時我們的位置是序號13。
圖片描述(最多50字)
圖片描述(最多50字)
到達終點站，我們回憶總結一下，文初提到的三個關鍵詞，在這個集羣容錯的整體架構過程中，dubbo究竟做了什麼？其實也就是三件事：
在Directory中找出本次集羣中的全部invokers
在Router中，將上一步的全部invokers挑選出能正常執行的invokers
在LoadBalance中，將上一步的能正常的執行invokers中，根據配置的負載均衡策略,挑選出需要執行的invoker