Dubbo 配置 Loadbalance 不生效？擼一把源碼
文末本文轉(zhuǎn)載自微信公眾號(hào)「捉蟲(chóng)大師」，作者捉蟲(chóng)大師 。轉(zhuǎn)載本文請(qǐng)聯(lián)系捉蟲(chóng)大師公眾號(hào)。
背景
很久之前我給業(yè)務(wù)方寫(xiě)了一個(gè) dubbo loadbalance 的擴(kuò)展(為了敘述方便，這個(gè) loadbalance 擴(kuò)展就叫它 XLB 吧)，這兩天業(yè)務(wù)方反饋說(shuō) XLB 不生效了
我心想，不可能啊，都用了大半年了~
排查
于是我登上不生效的 consumer 機(jī)器進(jìn)行排查，還好我留了一手，當(dāng) XLB 加載時(shí)，會(huì)打印一行日志
看了下這個(gè)服務(wù)，并沒(méi)有打印日志，說(shuō)明 XLB 并沒(méi)有加載成功
于是，我就去問(wèn)對(duì)應(yīng)的開(kāi)發(fā)，有按照我的文檔配置 loadbalance 嗎?答復(fù)：完全按照文檔配置
這下我就有點(diǎn)不相信了，但轉(zhuǎn)念一想，配置 loadbalance 如此簡(jiǎn)單，不應(yīng)該出錯(cuò)啊，我的文檔和他的應(yīng)用都在 xml 文件中配置了 consumer 的 loadbalance
- <dubbo:consumer loadbalance="xlb"/>
抱著試一試的態(tài)度，拉取了他們項(xiàng)目的代碼，發(fā)現(xiàn)配置確實(shí)如上，但我發(fā)現(xiàn)他們的 application.properties 配置文件也配了一個(gè) consumer 的屬性
- dubbo.consumer.check=false
以多年和 dubbo 打交道的經(jīng)驗(yàn)來(lái)說(shuō)，這里有問(wèn)題，又確認(rèn)了代碼，確實(shí) xml 和 application.properties 都加載了
那這里可能就有問(wèn)題了，dubbo 從 xml 加載生成了一個(gè) consumer 配置，dubbo-springboot-starter 又從 application.properties 加載配置生成了一個(gè) consumer 配置，這不就沖突了?
別看只配置了 dubbo.consumer.check，它實(shí)際上會(huì)生成一個(gè)完整的 consumer 配置，只不過(guò) loadbalance 為默認(rèn)值
業(yè)務(wù)方為什么會(huì)這樣配置?大概率是因?yàn)槲业奈臋n里只給出了 xml 形式的配置，沒(méi)有給 spring-boot 配置，他們?cè)仁褂玫氖?spring-boot 的配置方式，然后看到我的文檔是 xml，結(jié)果就不會(huì)配置了，也寫(xiě)了個(gè) xml，和原先的配置沖突
驗(yàn)證
為了驗(yàn)證是這個(gè)問(wèn)題導(dǎo)致，我把他的 application.properties 的 dubbo.consumer.check 配置挪到了 xml 文件中，果然重啟后就加載到了 XLB
隨后我又在本地的測(cè)試應(yīng)用上做了這樣一個(gè)驗(yàn)證：
- <!-- case 1 -->
- <dubbo:consumer />
- <dubbo:consumer loadbalance="xlb"/>
- <!-- case 2 -->
- <dubbo:consumer loadbalance="xlb"/>
- <dubbo:consumer />
兩組配置相同，但順序不同，測(cè)試結(jié)果為 case 1 可以加載到 XLB，case 2 不行
于是猜測(cè)，dubbo consumer 配置以后加載的為準(zhǔn)
擼源碼
顯然猜測(cè)不符合我的風(fēng)格，下面開(kāi)擼源碼，不感興趣可以劃過(guò)，最下面有總結(jié)
首先搞清楚，何時(shí)會(huì)加載 loadbalance，在 AbstractClusterInvoker 的 invoke 方法中，加載了 loadbalance
- @Override
- public Result invoke(final Invocation invocation) throws RpcException {
- ...
- List<Invoker<T>> invokers = list(invocation);
- LoadBalance loadbalance = initLoadBalance(invokers, invocation);
- RpcUtils.attachInvocationIdIfAsync(getUrl(), invocation);
- return doInvoke(invocation, invokers, loadbalance);
- }
加載代碼如下
- protected LoadBalance initLoadBalance(List<Invoker<T>> invokers, Invocation invocation) {
- if (CollectionUtils.isNotEmpty(invokers)) {
- return ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(invokers.get(0).getUrl()
- .getMethodParameter(RpcUtils.getMethodName(invocation), LOADBALANCE_KEY, DEFAULT_LOADBALANCE));
- } else {
- return ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(DEFAULT_LOADBALANCE);
- }
- }
帶緩存的加載擴(kuò)展
- public T getExtension(String name) {
- if (StringUtils.isEmpty(name)) {
- throw new IllegalArgumentException("Extension name == null");
- }
- if ("true".equals(name)) {
- return getDefaultExtension();
- }
- final Holder<Object> holder = getOrCreateHolder(name);
- Object instance = holder.get();
- if (instance == null) {
- synchronized (holder) {
- instance = holder.get();
- if (instance == null) {
- instance = createExtension(name);
- holder.set(instance);
- }
- }
- }
- return (T) instance;
- }
可以看出
- loadbalance 是發(fā)起 dubbo 調(diào)用時(shí)，且當(dāng) invokers 非空時(shí)(即 providers 非空)會(huì)被初始化，后續(xù)都從緩存中取
- loadbalance 是根據(jù)第一個(gè) invoker 的 loadbalance 參數(shù)決定使用哪個(gè) loadbalance 的
于是問(wèn)題轉(zhuǎn)移到 invoker 的 loadbalance 從哪來(lái)?provider 不會(huì)配置 loadbalance，所以這個(gè)參數(shù)一定是從 consumer 的配置上得到的
順藤摸瓜，在 RegistryDirectory 的 toInvokers 方法中調(diào)用了 mergeUrl，它是在注冊(cè)中心通知時(shí)被調(diào)用，也就是從注冊(cè)中心上拿到 provider url 時(shí)，還得 merge 一下才能用，merge 了些什么內(nèi)容?
- private URL mergeUrl(URL providerUrl) {
- // 1. merge consumer 參數(shù)
- providerUrl = ClusterUtils.mergeUrl(providerUrl, queryMap);
- // 2. merge configurator 參數(shù)
- providerUrl = overrideWithConfigurator(providerUrl);
- ...
- return providerUrl;
- }
1中 merge 了queryMap 里的參數(shù)，這個(gè)queryMap 其實(shí)就是 consumer 的參數(shù)，它來(lái)自配置的 reference
再看 reference 配置，當(dāng) ReferenceConfig 初始化時(shí)
- public synchronized void init() {
- ...
- checkAndUpdateSubConfigs();
- ...
- AbstractConfig.appendParameters(map, consumer);
- ...
- }
- // 2
- public void checkAndUpdateSubConfigs() {
- ...
- checkDefault();
- ...
- }
- // 3
- public void checkDefault() throws IllegalStateException {
- if (consumer == null) {
- consumer = ApplicationModel.getConfigManager()
- .getDefaultConsumer()
- .orElse(new ConsumerConfig());
- }
- }
- // 4
- public Optional<ConsumerConfig> getDefaultConsumer() {
- List<ConsumerConfig> consumerConfigs = getDefaultConfigs(getConfigsMap(getTagName(ConsumerConfig.class)));
- if (CollectionUtils.isNotEmpty(consumerConfigs)) {
- return Optional.of(consumerConfigs.get(0));
- }
- return Optional.empty();
- }
上面調(diào)用鏈從 1 到 4，4 中獲取了第1個(gè) consumer，這就是我們要找的根源
總結(jié)
每配置一個(gè) consumer ，無(wú)論是從 xml 文件，或是 spring-boot 配置，或是 api 直接創(chuàng)建，都會(huì)生成一個(gè) consumerConfig 對(duì)象
當(dāng)消費(fèi)接口，即配置 reference 時(shí)，會(huì)將 consumer 的參數(shù) merge 過(guò)來(lái)，如果存在多個(gè) consumer，會(huì)挑第一個(gè)，當(dāng)然我們并不知道誰(shuí)先加載
當(dāng) reference 存在 consumer 的配置時(shí)，注冊(cè)中心通知的 provider urls 會(huì)和 reference 的參數(shù)進(jìn)行合并，合并后生成可調(diào)用的 invoker
對(duì)于 loadbalance 來(lái)說(shuō)，調(diào)用時(shí)，如果 invokers 非空，則會(huì)嘗試通過(guò)第一個(gè) invoker 的 loadbalance 參數(shù)加載負(fù)載均衡算法，第一次調(diào)用進(jìn)行加載，后續(xù)調(diào)用則使用緩存
