dubbo自定義負載均衡策略及相關原始碼解析

最近在研究即時訊息推送系統（im系統）的架構，自己用netty開發了基礎網路通訊部分，用來維護tcp連線，在客戶端上線時將使用者標識userid和路由資訊存在redis中，通過dubbo向上層模組提供訊息推送介面。

在上層訊息**路由模組設計時，遇到了乙個問題，dubbo介面呼叫時要根據路由資訊中的ip指定對應的provider伺服器。研究了下資料發現可以通過dubbo spi自定義負載均衡策略或者路由規則來實現，由於自定義路由規則沒找到相關試例，自己試了下自定義負載均衡策略。

實現dubbo提供的com.alibaba.dubbo.rpc.cluster.loadbalance介面

public
class
iploadbalance
implements
loadbalance
}return null;
}}

新建spi擴充套件檔案

內容為

ip=com.tpc.im.loadbalance.iploadbalance

其中ip為策略名

com.tpc.im dubbo-spi 1.0-snapshot

之後將該模組新增到consumer專案的依賴中即可。

public inte***ce messageservice

@service public class messageserviceimpl implements messageservice

}

@service public class messageserviceconsumer

}

在consumer端簡單編寫乙個controller用於除錯

@restcontroller public class messagecontroller

}

用postman傳送請求，指定ip為不存在的位址

由於指定了使用loadbalance = "ip"的自定義負載均衡，理論上dubbo呼叫應該失敗，但是provider端卻顯示呼叫成功

debug上述除錯流程，首先到達業務**斷點處

之後到達如下**處

這裡先根據method和引數構建invocation物件，之後執行invoke方法

在invoke中先判斷是否mock，之後呼叫實際邏輯

這裡先獲取所有可用的invoker列表，如果列表不為空，則在圖示斷點處，根據method配置的loadbalance欄位獲取對應的負載均衡類，之後進入doinvoke中。這裡根據紅框中loadbalance的引用可知，自定義的負載均衡載入成功。

doinvoke中重點關注圖示斷點處，這裡才到達根據負載均衡選取invoker的地方

進入select方法到達到達doselect處，這裡才是實際選擇invoker的地方

在doselect中，才能發現配置的自定義負載均衡不起作用的原因。

圖中1處會先判斷invokers是否只有1個，是的話直接返回該invoker，我在除錯中只啟動了一台provider，所以到這裡時只有乙個invoker，從而導致後續3處自定義負載均衡邏輯未執行。

從圖中1、2、3處可以得知，當只有乙個可用的invoker時直接呼叫，當有兩個時使用輪詢策略，當三個及以上時才會用到負載均衡策略。

以上即為自定義dubbo負載均衡時遇到的問題，主要是當provider數量不足三個時不會執行負載均衡。

查閱更多資料後發現也可以通過dubbo的標籤路由規則或者自定義路由拓展來實現根據ip呼叫。