dubbo泛化引发的生产故障之dubbo隐藏的坑#
作者：互联网
上个月公司zk集群发生了一次故障，然后要求所有项目组自检有无使用Dubbo编程式/泛化调用，强制使用@Reference生成Consumer。具体原因是线上某服务访问量在短时间大量访问zk并创建了240万+的节点，导致zk所有节点陆续崩溃导致，多个应用因无法连接到zk报错。原因是听说泛化调用时候，provider没启动，导致每次请求都在zk创建消费节点。
由于是和自己关联性不大的项目组，了解的并不是很清楚，但是想搞明白这个事情，因此就进行了如下实验：
试验1：泛化不使用缓存
dubbo泛化写法
public Result<Map> getProductGenericCache(ProductDTO dto) {
ReferenceConfig<GenericService> reference = new ReferenceConfig<GenericService>();
ApplicationConfig application = new ApplicationConfig();
application.setName("pangu-client-consumer-generic");
// 连接注册中心配置
RegistryConfig registry = new RegistryConfig();
registry.setAddress("zookeeper://127.0.0.1:2181");
// 服务消费者缺省值配置
ConsumerConfig consumer = new ConsumerConfig();
consumer.setTimeout(5000);
consumer.setRetries(0);
reference.setApplication(application);
reference.setRegistry(registry);
reference.setConsumer(consumer);
reference.setInterface(org.pangu.api.ProductService.class); // 弱类型接口名
// reference.setVersion("");
// reference.setGroup("");
reference.setGeneric(true); // 声明为泛化接口
GenericService svc = reference.get();
Object target = svc.$invoke("findProduct", new String[]{ProductDTO.class.getName()}, new Object[]{dto});//实际网关中，方法名、参数类型、参数是作为参数传入
return Result.success((Map)target);
}
这个写法，就没有缓存reference，因此每次请求这个方法，就会在zk创建个消费节点(无论provider是否启动)，请求量大的时候，就会导致zk所有节点陆续崩溃。使用泛化不缓存，这个估计稍微看了官方文档都不会出现这个错误。引发这次故障的这个应用功能，又不是初次上线，运行了一段时间了，生产有zk节点数监控，不然初次就发现这个问题了。因此基本可以排除对方是没有使用缓存的问题。
试验2：泛化使用缓存
@Override
public Result<Map> getProductGenericCache(ProductDTO dto) {
ReferenceConfigCache referenceCache = ReferenceConfigCache.getCache();
ReferenceConfig<GenericService> reference = new ReferenceConfig<GenericService>();//缓存，否则每次请求都会创建一个ReferenceConfig，并在zk注册节点，最终可能导致zk节点过多影响性能
ApplicationConfig application = new ApplicationConfig();
application.setName("pangu-client-consumer-generic");
// 连接注册中心配置
RegistryConfig registry = new RegistryConfig();
registry.setAddress("zookeeper://127.0.0.1:2181");
// 服务消费者缺省值配置
ConsumerConfig consumer = new ConsumerConfig();
consumer.setTimeout(5000);
consumer.setRetries(0);
reference.setApplication(application);
reference.setRegistry(registry);
reference.setConsumer(consumer);
reference.setInterface(org.pangu.api.ProductService.class); // 弱类型接口名
// reference.setVersion("");
// reference.setGroup("");
reference.setGeneric(true); // 声明为泛化接口
GenericService svc = referenceCache.get(reference);//cache.get方法中会缓存 Reference对象，并且调用ReferenceConfig.get方法启动ReferenceConfig
Object target = svc.$invoke("findProduct", new String[]{ProductDTO.class.getName()}, new Object[]{dto});//实际网关中，方法名、参数类型、参数是作为参数传入
return Result.success((Map)target);
}
在provider端无论是否启动，都只会在zk创建一个消费节点
试验3：设置服务检查为true，reference.setCheck(true);
排除了前面两个试验，又查看了下dubbo源码，泛化使用ReferenceConfig，那么无论如何都会执行ReferenceConfig.get()，代码如下
public synchronized T get() {
if (destroyed) {
throw new IllegalStateException("Already destroyed!");
}
if (ref == null) {
init();
}
return ref;
}
ref为null，则执行初始化init，那么ref是怎么来的呢？是在init操作内由createProxy生成，createProxy代码如下：
//com.alibaba.dubbo.config.ReferenceConfig.createProxy(Map<String, String>)
private T createProxy(Map<String, String> map) {
//前面代码忽略
//使用Protocol创建Invoker,在zk创建consumer节点
Boolean c = check;
if (c == null && consumer != null) {
c = consumer.isCheck();
}
if (c == null) {
c = true; // default true
}
if (c && !invoker.isAvailable()) {
// make it possible for consumer to retry later if provider is temporarily unavailable
initialized = false;
throw new IllegalStateException("Failed to check the status of the service " + interfaceName + ". No provider available for the service " + (group == null ? "" : group + "/") + interfaceName + (version == null ? "" : ":" + version) + " from the url " + invoker.getUrl() + " to the consumer " + NetUtils.getLocalHost() + " use dubbo version " + Version.getVersion());
}
if (logger.isInfoEnabled()) {
logger.info("Refer dubbo service " + interfaceClass.getName() + " from url " + invoker.getUrl());
}
// create service proxy
return (T) proxyFactory.getProxy(invoker);
}
具体逻辑：
1.使用Protocol创建Invoker
2.检测服务端check=false，使用proxyFactory创建Invoker代理对象，即ref。
3.检测服务端check=true，如果provider未启动，则抛出IllegalStateException异常，自然ref就还是null了，那么下次访问，由于ref为null，则继续执行init->createProxy，在zk创建consumer节点。
那么是如何检测服务是否存活呢，即执行RegistryDirectory.isAvailable()，判断RegistryDirectory.urlInvokerMap是否为空，为空，肯定说明provider不存在。
PS：RegistryDirectory.urlInvokerMap缓存的是Invoker集合
问题大体明白了，因此试验下，设置check=true
@Override
public Result<Map> getProductGenericCache(ProductDTO dto) {
ReferenceConfigCache referenceCache = ReferenceConfigCache.getCache();
ReferenceConfig<GenericService> reference = new ReferenceConfig<GenericService>();//缓存，否则每次请求都会创建一个ReferenceConfig，并在zk注册节点，最终可能导致zk节点过多影响性能
ApplicationConfig application = new ApplicationConfig();
application.setName("pangu-client-consumer-generic");
// 连接注册中心配置
RegistryConfig registry = new RegistryConfig();
registry.setAddress("zookeeper://127.0.0.1:2181");
// 服务消费者缺省值配置
ConsumerConfig consumer = new ConsumerConfig();
consumer.setTimeout(5000);
consumer.setRetries(0);
reference.setApplication(application);
reference.setRegistry(registry);
reference.setConsumer(consumer);
reference.setCheck(true);//试验3，设置检测服务存活
reference.setInterface(org.pangu.api.ProductService.class); // 弱类型接口名
// reference.setVersion("");
// reference.setGroup("");
reference.setGeneric(true); // 声明为泛化接口
GenericService svc = referenceCache.get(reference);//cache.get方法中会缓存 Reference对象，并且调用ReferenceConfig.get方法启动ReferenceConfig
Object target = svc.$invoke("findProduct", new String[]{ProductDTO.class.getName()}, new Object[]{dto});//实际网关中，方法名、参数类型、参数是作为参数传入
return Result.success((Map)target);
}
验证1：先启动provider服务，然后启动消费端泛化，请求此泛化方法，在zk只注册了一个consumer节点；停止provider，再请求此泛化方法，发现zk上此节点数量不变化。为什么呢？provider停止后，请求不再创建zk节点的原因是RegistryConfig的ref已经在启动时候生成了代理（由于启动时候provider服务存在，check=true校验过通过），因此不再创建。
验证2：不启动provider服务，直接启动消费端泛化，请求此泛化方法，发现每请求一次，在zk就会创建一个消费节点。至此验证到故障。
那么这种情况，为什么会每次请求都在zk创建消费节点呢？根本原因是什么？
private T createProxy(Map<String, String> map) {
//忽略其它代码
if (isJvmRefer) {
//忽略其它代码
} else {
if (url != null && url.length() > 0) {
//忽略其它代码
} else { // assemble URL from register center's configuration
List<URL> us = loadRegistries(false);//代码@1
if (us != null && !us.isEmpty()) {
for (URL u : us) {
URL monitorUrl = loadMonitor(u);
if (monitorUrl != null) {
map.put(Constants.MONITOR_KEY, URL.encode(monitorUrl.toFullString()));
}
urls.add(u.addParameterAndEncoded(Constants.REFER_KEY, StringUtils.toQueryString(map)));//代码@2
}
}
if (urls.isEmpty()) {
throw new IllegalStateException("No such any registry to reference " + interfaceName + " on the consumer " + NetUtils.getLocalHost() + " use dubbo version " + Version.getVersion() + ", please config <dubbo:registry address=\"...\" /> to your spring config.");
}
}
if (urls.size() == 1) {
invoker = refprotocol.refer(interfaceClass, urls.get(0));//代码@3
} else {
List<Invoker<?>> invokers = new ArrayList<Invoker<?>>();
URL registryURL = null;
for (URL url : urls) {//代码@4
invokers.add(refprotocol.refer(interfaceClass, url));
if (Constants.REGISTRY_PROTOCOL.equals(url.getProtocol())) {
registryURL = url; // use last registry url
}
}
if (registryURL != null) { // registry url is available
// use AvailableCluster only when register's cluster is available
URL u = registryURL.addParameterIfAbsent(Constants.CLUSTER_KEY, AvailableCluster.NAME);
invoker = cluster.join(new StaticDirectory(u, invokers));
} else { // not a registry url
invoker = cluster.join(new StaticDirectory(invokers));
}
}
}
Boolean c = check;
if (c == null && consumer != null) {
c = consumer.isCheck();
}
if (c == null) {
c = true; // default true
}
if (c && !invoker.isAvailable()) {//check=true，provider服务不存在，抛出异常
// make it possible for consumer to retry later if provider is temporarily unavailable
initialized = false;
throw new IllegalStateException("Failed to check the status of the service " + interfaceName + ". No provider available for the service " + (group == null ? "" : group + "/") + interfaceName + (version == null ? "" : ":" + version) + " from the url " + invoker.getUrl() + " to the consumer " + NetUtils.getLocalHost() + " use dubbo version " + Version.getVersion());
}
if (logger.isInfoEnabled()) {
logger.info("Refer dubbo service " + interfaceClass.getName() + " from url " + invoker.getUrl());
}
// create service proxy
return (T) proxyFactory.getProxy(invoker);
}
1.首次请求泛化方法，由于ReferenceConfig的ref为null，因此执行createProxy，执行的是代码@1、@2、@3，在zk创建消费节点，但是由于check=true，因此抛出IllegalStateException异常，最终ReferenceConfig的ref依然为null。
2.第二次请求泛化方法，由于ReferenceConfig已经被缓存，这次的ReferenceConfig对象就是首次的ReferenceConfig对象，获取ReferenceConfig的代理对象ref，由于ReferenceConfig的ref为null，因此执行createProxy，执行的是代码@1、@2、@4，在zk创建消费节点，但是由于check=true，因此抛出IllegalStateException异常，最终ReferenceConfig的ref依然为null。
3.第三次，以及后续的请求，都和第二次请求是一样效果。
为什么每次在zk都创建消费节点，只能说明订阅url不同导致的，如果url相同，在zk是不会创建的。那么订阅url的组成对一个服务来说有哪些不同呢？查看ReferenceConfig.init()，发现订阅url上有timestamp，是当前时间戳，这也说明了为什么每次都去注册，因为订阅url不同，如下图
那么订阅url上加上这个timestamp是否有些不合理呢？经过查看官方，在2.7.5版本中已经将订阅的URL中的timestamp去掉了，只会对一个URL订阅一次。
下图是故障时刻，对zk的dump解析，发现当时的ZK 目录节点数为170W，实际平时也就10w。
dubbo consumer泛化check=true对应用端的影响
private T createProxy(Map<String, String> map) {
//忽略其它代码
if (isJvmRefer) {
//忽略其它代码
} else {
if (url != null && url.length() > 0) {
//忽略其它代码
} else { // assemble URL from register center's configuration
List<URL> us = loadRegistries(false);//代码@1
if (us != null && !us.isEmpty()) {
for (URL u : us) {
URL monitorUrl = loadMonitor(u);
if (monitorUrl != null) {
map.put(Constants.MONITOR_KEY, URL.encode(monitorUrl.toFullString()));
}
urls.add(u.addParameterAndEncoded(Constants.REFER_KEY, StringUtils.toQueryString(map)));//代码@2
}
}
if (urls.isEmpty()) {
throw new IllegalStateException("No such any registry to reference " + interfaceName + " on the consumer " + NetUtils.getLocalHost() + " use dubbo version " + Version.getVersion() + ", please config <dubbo:registry address=\"...\" /> to your spring config.");
}
}
if (urls.size() == 1) {
invoker = refprotocol.refer(interfaceClass, urls.get(0));//代码@3
} else {
List<Invoker<?>> invokers = new ArrayList<Invoker<?>>();
URL registryURL = null;
for (URL url : urls) {//代码@4
invokers.add(refprotocol.refer(interfaceClass, url));
if (Constants.REGISTRY_PROTOCOL.equals(url.getProtocol())) {
registryURL = url; // use last registry url
}
}
if (registryURL != null) { // registry url is available
// use AvailableCluster only when register's cluster is available
URL u = registryURL.addParameterIfAbsent(Constants.CLUSTER_KEY, AvailableCluster.NAME);
invoker = cluster.join(new StaticDirectory(u, invokers));
} else { // not a registry url
invoker = cluster.join(new StaticDirectory(invokers));
}
}
}
Boolean c = check;
if (c == null && consumer != null) {
c = consumer.isCheck();
}
if (c == null) {
c = true; // default true
}
if (c && !invoker.isAvailable()) {//check=true，provider服务不存在，抛出异常
// make it possible for consumer to retry later if provider is temporarily unavailable
initialized = false;
throw new IllegalStateException("Failed to check the status of the service " + interfaceName + ". No provider available for the service " + (group == null ? "" : group + "/") + interfaceName + (version == null ? "" : ":" + version) + " from the url " + invoker.getUrl() + " to the consumer " + NetUtils.getLocalHost() + " use dubbo version " + Version.getVersion());
}
if (logger.isInfoEnabled()) {
logger.info("Refer dubbo service " + interfaceClass.getName() + " from url " + invoker.getUrl());
}
// create service proxy
return (T) proxyFactory.getProxy(invoker);
}
1.首次请求泛化方法，由于ReferenceConfig的ref为null，因此执行createProxy，执行的是代码@1、@2、@3，在zk创建消费节点，但是由于check=true，因此抛出IllegalStateException异常，最终ReferenceConfig的ref依然为null。把带时间戳的url加入到ReferenceConfig.urls集合。创建1个RegistryDirectory。
2.第二次请求泛化方法，由于ReferenceConfig已经被缓存，这次的ReferenceConfig对象就是首次的ReferenceConfig对象，获取ReferenceConfig的代理对象ref，由于ReferenceConfig的ref为null，因此执行createProxy，执行的是代码@1、@2、@4，在zk创建消费节点，但是由于check=true，因此抛出IllegalStateException异常，最终ReferenceConfig的ref依然为null。此时ReferenceConfig.urls集合是两个url，那么遍历urls，执行refprotocol.refer(interfaceClass, url)，就创建了2个RegistryDirectory。
3.第三此请求泛化方法，基本同2，但是此时ReferenceConfig.urls集合是3个url，那么遍历urls，执行refprotocol.refer(interfaceClass, url)，就创建了3个RegistryDirectory。
依次类推，第n次请求后，总计创建的RegistryDirectory对象1+2+3+....+n，因此dubbo泛化在设置check=true的情况下，不仅最终会导致zk故障，本地应用也会出现oom。
用这个测试下oom问题，学会分析下dump
jmeter配置
具体在pangu-client-parent工程内
效果图如下
标签：dubbo,泛化,reference,url,故障,new,ReferenceConfig,null,consumer 来源： https://blog.csdn.net/JavaMBa/article/details/122560614