在之前的文章我們分析了 dubbo 的服務(wù)治理，也就是在 consumer 端在進(jìn)行服務(wù)引用的時候。consumer 首先會根據(jù)配置 Protocol(協(xié)議) 創(chuàng)建 Invoke 調(diào)用對象，它代表一個可執(zhí)行體，可向它發(fā)起 invoke 調(diào)用，它有可能是一個本地的實現(xiàn)，也可能是一個遠(yuǎn)程的實現(xiàn)，也可能一個集群實現(xiàn)。然后再使用 ProxyFactory 接口創(chuàng)建代理對象，進(jìn)行遠(yuǎn)程調(diào)用。

invoke.png

創(chuàng)建的代理對象為 InvokeInvocationHandler，然后它組合了一個 MockClusterInvoker 對象。 dubbo 里面的服務(wù)治理就是通過它來完成的。這個里面就涉及到服務(wù)治理也就是集群容錯。

cluster.jpg

• 首先通過 MockClusterInvoke 將多個 Invoker 偽裝成一個Invoker，這樣其它人只要關(guān)注Protocol 層 Invoker 即可，加上 Cluster 或者去掉 Cluster 對其它層都不會造成影響，因為只有一個提供者時，是不需要Cluster的。
• 接著 Directory 服務(wù)的主要作用是通過注冊中心推送變更。當(dāng) Provider 暴露新的接口服務(wù)，或者失效掉接口服務(wù)的時候就會動態(tài)的更新 Invoke。
• 然后 Router 服務(wù)配置可以過濾 Directory 服務(wù)里面注冊的接口服務(wù)，可以通過路由規(guī)則從多個 Invoke 里面選擇出子集。
• 最后 LoadBalance 負(fù)責(zé)從過濾后的 Invoke 列表中通過負(fù)載均衡算法選擇一個具體的 Invoke 來用于本次服務(wù)調(diào)用。

這就是之前分析集群容錯源碼的整個過程。其實就是通過服務(wù)治理從多個服務(wù)中選擇中一個具體的 Invoke 來進(jìn)行調(diào)用。最終選擇出來的 Invoke 如下把示：

invoke.png

它是 RegistryDirectory 的內(nèi)部類 InvokerDelegete，而這個類又是繼承于 InvokerWrapper 類，所以最終是通過 InvokerWrapper 來進(jìn)行遠(yuǎn)程調(diào)用的。

dubbo 調(diào)用流程圖：

dubbo-extension.jpg

我們已經(jīng)獲取到了一個具體的 Invoke，所以我們下面就是需要來分析一下以下幾個問題：

• consumer 的發(fā)送與接收原理
• provider 的接收與發(fā)送原理
• dubbo 的通信方式

因為 dubbo 的遠(yuǎn)程網(wǎng)絡(luò)傳輸默認(rèn) netty NIO的非阻塞并行調(diào)用通信的。所以將會再下一個章節(jié)來簡單的介紹一下 netty 的使用。