在之前的文章我們分析了 dubbo 的服務治理，也就是在 consumer 端在進行服務引用的時候。consumer 首先會根據配置 protocol(協議) 建立 invoke 呼叫物件，它代表乙個可執行體，可向它發起 invoke 呼叫，它有可能是乙個本地的實現，也可能是乙個遠端的實現，也可能乙個集群實現。然後再使用 proxyfactory 介面建立**物件，進行遠端呼叫。
建立的**物件為 invokeinvocationhandler，然後它組合了乙個 mockclusterinvoker 物件。 dubbo 裡面的服務治理就是通過它來完成的。這個裡面就涉及到服務治理也就是集群容錯。
這就是之前分析集群容錯原始碼的整個過程。其實就是通過服務治理從多個服務中選擇中乙個具體的 invoke 來進行呼叫。最終選擇出來的 invoke 如下把示：
dubbo 呼叫流程圖：
我們已經獲取到了乙個具體的 invoke，所以我們下面就是需要來分析一下以下幾個問題：
因為 dubbo 的遠端網路傳輸預設 netty nio的非阻塞並行呼叫通訊的。所以將會再下乙個章節來簡單的介紹一下 netty 的使用。
Dubbo原始碼分析
dubbo原始碼分析 其實已經有很多比較好的原始碼分析部落格，結合部落格和開發經驗再去分析原始碼，就能對dubbo的實現有個整體全面的理解，也能深入去深究其中的具體實現細節。dubbo裡主要用到的spi service provider inte ce netty nio 同步非阻塞多路復用框架，d...
Dubbo原始碼分析 多版本
在開發的時候，可能多個專案會修改同乙個服務，那麼不能直接暴露出來，否則會被其他人給呼叫到，導致資料不正常，那麼這種情況下可以使用dubbo的多版本來解決這個問題，配置如下 穩定環境下的provider和consumer com.foo.barservice version 1.0.0 barserv...
Dubbo服務註冊原始碼分析
服務在本地發布完成，那麼接下去要進入服務的註冊階段 final registry registry getregistry origininvoker final url registeredproviderurl geturltoregistry providerurl,registryurl d...