dubbo泛化引發的生產故障之dubbo隱藏的坑
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工程內
效果圖如下
參考 //cloud.tencent.com/developer/article/1760931