最近给一个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);
}
}
}
});
}