dubbo泛化呼叫就是服務消費端不需要引入介面jar包，通過genericservice介面就能處理完成所有服務的呼叫，引數及返回值中的所有pojo均用map表示。
public class dubboservicefactory
public static dubboservicefactory getinstance()
private dubboservicefactory()
public object genericinvoke(string inte***ceclass, string methodname, string parametertype, object param)
if (parametertype == null) , new object {});
} return genericservice.$invoke(methodname, new string , new object );
}}
object result = dubboservicefactory.getinstance().genericinvoke(inte***ceclass, methodname, parametertype, object);1、問題：若泛化呼叫服務消費端先啟動，在服務提供端未啟動之前，泛化呼叫服務消費端某介面(a)進行了一次呼叫，在後續即使服務提供端成功啟動，泛化呼叫服務消費端依然不能正常訪問某介面(a)
2、原因：因為referenceconfig例項很重，封裝了與註冊中心的連線以及與提供者的連線，需要快取，否則重複生成referenceconfig可能造成效能問題並且會有記憶體和連線洩漏。所以在呼叫服務時，不論服務提供端介面服務是否存在，referenceconfigcache都會快取referenceconfig例項(若呼叫服務提供端不存在，referenceconfig例項的ref引數為空，即不能生成genericservice物件)，再下次請求時，即使服務提供端正常提供服務，但因為referenceconfigcache已經快取了referenceconfig例項，所以不會再重新建立鏈結，直接從referenceconfigcach快取中獲取genericservice物件，導致genericservice例項一直報空指標(因為ref引數為空)，最終導致一直呼叫不到真正的服務
3、處理方法：在genericservice物件呼叫方法($invoke)之前,先判斷genericservice是否為空，若為空，則呼叫referenceconfigcache物件的destroy方法，下次呼叫時即會重新生成referenceconfig例項，不會再從快取中取。
b、1、問題：在正常呼叫過程中，若服務提供端中斷，再重啟，即使服務提供端已經重新正常提供服務，但泛化呼叫服務消費端仍會有一斷時間無法成功消費服務
2、原因：
3、處理方法：
dubbo的泛化呼叫研究
結論 泛化呼叫需要繼承乙個類，在配置檔案裡需要明確指出generic true 泛化呼叫在書寫provider 時，變化不大 泛化呼叫和普通呼叫的區別主要在consumer，從 呼叫 的表面意思也能看到端倪 泛化呼叫書寫客戶端時，不需要明確繼承和服務端相同的介面 使用泛化呼叫結合jmeter打壓，也...
dubbo的泛化呼叫研究
結論 泛化呼叫需要繼承乙個類，在配置檔案裡需要明確指出generic true 泛化呼叫在書寫provider 時，變化不大 泛化呼叫和普通呼叫的區別主要在consumer，從 呼叫 的表面意思也能看到端倪 泛化呼叫書寫客戶端時，不需要明確繼承和服務端相同的介面 使用泛化呼叫結合jmeter打壓，也...
Dubbo泛化呼叫閘道器初試
由於之前閘道器採用的是dubbo的rest協議，但使用一段時間發現速度有些慢，而且總感覺不如直接使用泛化呼叫來的爽，所以打算研究一下dubbo的泛化呼叫，在此記錄一下，參照了很多大神的思路，水平有限，歡迎指正。dubbo泛化呼叫的原理就不細講了，網上有很多文章，底層基於netty做資料傳輸，進行rp...