dubbo3 遇坑小结

 最近给一个dubbo3的应用改名字，发现消费者还是会请求以前的地址。

问题现象

 应用部署是k8s容器环境，dubbo版本是3.1.1，应用appA名字改成appB。改完名发现消费者应用appC请求还是会往以前的地址请求(当然是请求不通的)

问题分析

分析日志

 dubbo3的服务发现是应用级的，影响消费者的调用关系就两点：接口应用映射(zk节点：/dubbo/mapping)以及应用实例(zk节点：/services)。所以主要就是看这两个地方的日志，分析zk有没有正确下发信息。
首先，新应用appB启动后，消费者appC收到如下日志：

appC收到了mapping的变更消息。
 mapping变更主动拉取新应用的实例，触发实例变更信息：

上述两块日志均符合预期。接口有新的应用提供，下发MappingChangedEvent事件。mapping事件处理过程中将拉取新应用实例触发ServiceInstancesChangedEvent事件。

疑点显现

除了上述日志，还有以下日志：

顺着这个日志走查代码，原来dubbo3再收到新的mapping事件时创建新的ServiceInstancesChangedListener。老的ServiceInstancesChangedListener就会destroy。理论上也合理，挺正常。
不过，继续看代码发现销毁监听器时执行org.apache.dubbo.registry.client.ServiceDiscovery#removeServiceInstancesChangedListener，dubbo3.1.1版本实现如下：

public void removeServiceInstancesChangedListener(ServiceInstancesChangedListener listener) throws IllegalArgumentException {
        listener.getServiceNames().forEach(serviceName -> {
            ZookeeperServiceDiscoveryChangeWatcher watcher = watcherCaches.remove(buildServicePath(serviceName));
            if (watcher != null) {
                watcher.stopWatching();
            }
        });
    }

这里停止监听应用对应的路径/services/appA。虽然新的mapping包括appA,appB，会重新监听/services/appA，但是这里有可能出现谁先执行谁后执行的情况。可能导致后续appA下线时消费者无法感知。这样也就出现老的引用(invokers)始终还在。一旦机器重新被其他应用拉起，dubbo端口重新建立链接，就可能发请求过去。

如何解决

实际上就是删除zk节点监听路径时没有判断该节点是不是还有其他的ServiceInstanceChangedListener在监听。我们看到dubbo3.2.5已经做了这样的处理

public void removeServiceInstancesChangedListener(ServiceInstancesChangedListener listener) throws IllegalArgumentException {
        if (!instanceListeners.remove(listener)) {
            return;
        }
        listener.getServiceNames().forEach(serviceName -> {
            ZookeeperServiceDiscoveryChangeWatcher watcher = watcherCaches.get(serviceName);
            if (watcher != null) {
                watcher.getListeners().remove(listener);
                //笔者注：判断是否有其他监听器还在监听
                if (watcher.getListeners().isEmpty()) {
                    watcherCaches.remove(serviceName);
                    try {
                        watcher.getCacheInstance().close();
                    } catch (IOException e) {
                        logger.error(REGISTRY_ZOOKEEPER_EXCEPTION, "curator stop watch failed", "",
                                "Curator Stop service discovery watch failed. Service Name: " + serviceName);
                    }
                }
            }
        });
    }