分析完spi,開始分析服務發(fā)布,先看一張官網的服務發(fā)布時序圖:
下面開始分析服務發(fā)布邏輯,我們的入口是我們的使用方式-----配置文件:
<dubbo:application name="kai-nina-server"/>
<dubbo:registry id="nina-register" address="N/A" port="2181" protocol="zookeeper" file="/Users/kai.yang/Documents/學習/dubbo"/>
<dubbo:registry id="nina-register2" address="127.0.0.1" port="2181" protocol="zookeeper" file="/Users/kai.yang/Documents/學習/dubbo"/>
<dubbo:protocol id="dubbo" port="20880" name="dubbo" server="netty4"/>
<dubbo:service interface="com.alibaba.dubbo.kai.api.HelloApi" ref="helloApi" version="0.0" />
<bean id="helloApi" class="com.alibaba.dubbo.kai.api.imp.HelloApiImpl"/>
很熟悉吧,dubbo的常用配置文件啟動方式,當然dubbo有api的方式,如下:
// 連接注冊中心配置
RegistryConfig registry = new RegistryConfig();
registry.setAddress("10.20.130.230:9090");
registry.setUsername("aaa");
registry.setPassword("bbb");
// 服務提供者協議配置
ProtocolConfig protocol = new ProtocolConfig();
protocol.setName("dubbo");
protocol.setPort(12345);
protocol.setThreads(200);
ServiceConfig<XxxService> service = new ServiceConfig<XxxService>(); // 此實例很重,封裝了與注冊中心的連接,請自行緩存,否則可能造成內存和連接泄漏
service.setApplication(application);
service.setRegistry(registry); // 多個注冊中心可以用setRegistries()
service.setProtocol(protocol); // 多個協議可以用setProtocols()
service.setInterface(XxxService.class);
service.setRef(xxxService);
service.setVersion("1.0.0");
service.export();
當然實際邏輯大同小異,一個用spring,一個不用spring而已,那我們就看spring中的,發(fā)布服務的入口就是 <dubbo:service >標簽。
熟悉spring自定義標簽的同學,對這個一定不陌生,其實現關鍵點為:
- 1、handler--對應一個NamseSpaceHandler類
- 2、parser---對應一個spring的bean解析類
- 3、 schemas--對應兩個指定xsd和handler的配置文件
? ?分析入口自然在handler中,dubbo的handler為
public class DubboNamespaceHandler extends NamespaceHandlerSupport {
static {
Version.checkDuplicate(DubboNamespaceHandler.class);
}
public void init() {
registerBeanDefinitionParser("application", new DubboBeanDefinitionParser(ApplicationConfig.class, true));
registerBeanDefinitionParser("module", new DubboBeanDefinitionParser(ModuleConfig.class, true));
registerBeanDefinitionParser("registry", new DubboBeanDefinitionParser(RegistryConfig.class, true));
registerBeanDefinitionParser("monitor", new DubboBeanDefinitionParser(MonitorConfig.class, true));
registerBeanDefinitionParser("provider", new DubboBeanDefinitionParser(ProviderConfig.class, true));
registerBeanDefinitionParser("consumer", new DubboBeanDefinitionParser(ConsumerConfig.class, true));
registerBeanDefinitionParser("protocol", new DubboBeanDefinitionParser(ProtocolConfig.class, true));
registerBeanDefinitionParser("service", new DubboBeanDefinitionParser(ServiceBean.class, true));
registerBeanDefinitionParser("reference", new DubboBeanDefinitionParser(ReferenceBean.class, false));
registerBeanDefinitionParser("annotation", new DubboBeanDefinitionParser(AnnotationBean.class, true));
}
}
? ?很明顯入口到了DubboBeanDefinitionParser解析類,服務發(fā)布明細是service入口,看到此解析會生成一個ServiceBean的beand定義,因此我們的方向被帶到了ServiceBean類(spring自定義注解我們就不做過多解釋了,都是spring生成bean的老一套,解析標簽,依賴注入,生成bean定義)。
? ?下面開始重點看ServiceBean類
public class ServiceBean<T> extends ServiceConfig<T> implements InitializingBean, DisposableBean, ApplicationContextAware, ApplicationListener, BeanNameAware {
他實現了InitializingBean, DisposableBean, ApplicationContextAware, ApplicationListener, BeanNameAware 幾個spring的接口,根據Spring的執(zhí)行流程會做相應注入,最后到afterPropertiesSet及onApplicationEvent中,按例先看大圖說話:
? ?我們可以看出圖中已經包含了所有發(fā)布過程,讓我一起了解下。
首先我們介紹下服務發(fā)布的對象模型
dubbo的發(fā)布服務層層包裝后最終得到exporter對象,看起來很牛的樣子,層層包裝,調用有20來層(加filter)。下面讓我們看看他們形成的過程。
大圖中顯示serviceBean通過afterPropertiesSet開始賦值,然后判斷是否配置delay:
if (!isDelay()) {
export();
}
看下isDelay這個方法
private boolean isDelay() {
Integer delay = getDelay();
ProviderConfig provider = getProvider();
if (delay == null && provider != null) {
delay = provider.getDelay();
}
return supportedApplicationListener && (delay == null || delay == -1);
}
delay如果你配置了>0的值,將會進入export()方法,在export()方法中將會通過
開啟異步延時線程發(fā)布服務
if (delay != null && delay > 0) {
delayExportExecutor.schedule(new Runnable() {
public void run() {
doExport();
}
}, delay, TimeUnit.MILLISECONDS);
} else {
doExport();
}
否則將會不執(zhí)行export()方法,那將會什么是否發(fā)布呢?
對了,大圖中展示了這個流程,將會在ApplicationListener接口的事件通知方法執(zhí)行
public void onApplicationEvent(ApplicationEvent event) {
if (ContextRefreshedEvent.class.getName().equals(event.getClass().getName())) {
if (isDelay() && !isExported() && !isUnexported()) {
if (logger.isInfoEnabled()) {
logger.info("The service ready on spring started. service: " + getInterface());
}
export();
}
}
}
方法中監(jiān)聽ContextRefreshedEvent(spring的context加載完畢)事件,進行發(fā)布export方法
好了,終于開始發(fā)布了,export方法慢慢進入doExport(),首先一些基本參數的校驗,圖中顯示會new出個provider,其中會有一段判斷是否為GenericService的邏輯,此處如果泛化類,后面地址中methods會為*、generic為true,否則就是找出實際接口的方方法名字,generic為false。泛化類大家可能有使用過,其特點入參和反參都可用map,調用只需指定方法名,不需要依賴實際接口,寫個插曲看下使用:
//1.server端配置
<dubbo:service interface="com.alibaba.dubbo.kai.api.HelloApi" ref="helloApi" version="0.0" generic="true"/>
........
//2.client配置
<dubbo:reference interface="com.alibaba.dubbo.kai.api.HelloApi" id="helloApi2" protocol="dubbo" check="true" version="0.0" timeout="10000" generic="true"/>
.......
//3.客戶端調用,不需要依賴接口,直接使用
public static void main(String[] args) throws IOException {
ClassPathXmlApplicationContext classPathXmlApplicationContext=new ClassPathXmlApplicationContext("dubbo-client.xml");
classPathXmlApplicationContext.start();
GenericService bean = classPathXmlApplicationContext.getBean(GenericService.class);
Object sayHello = bean.$invoke("sayHello", null, null);
System.out.println(sayHello);
System.in.read();
}
回到正題,此處判斷泛化賦值,為的都是生成最終的dubbo url。
protected synchronized void doExport() {
.....//參數檢查整理,沒有配置provier時new出一個
checkApplication();
checkRegistry();
checkProtocol();
appendProperties(this);
//檢查mock相關注入
checkStubAndMock(interfaceClass);
if (path == null || path.length() == 0) {
path = interfaceName;
}
//進行發(fā)布方法
doExportUrls();
}
繼續(xù)看代碼,此時略過一系列檢查,最終進入了ServiceConfig的doExportUrls中,開始做發(fā)布服務前的準備。首先loadRegistries方法會根據registry的配置生成對應需要注冊的url:
//進行發(fā)布
private void doExportUrls() {
List<URL> registryURLs = loadRegistries(true);
for (ProtocolConfig protocolConfig : protocols) {
doExportUrlsFor1Protocol(protocolConfig, registryURLs);
}
}
此時的loadRegistries生成的地址(我們只配置了一個注冊中心,所以只有一個):
registry://127.0.0.1:2181/com.alibaba.dubbo.registry.RegistryService?application=kai-nina-server&dubbo=2.0.0&file=/Users/kai.yang/Documents/學習/dubbo&pid=50109®istry=zookeeper×tamp=1540349411225
注意,此處協議頭是registry,并不是我們配置zookeeper,
protected List<URL> loadRegistries(boolean provider) {
.......
//此處為zookeeper協議頭
List<URL> urls = UrlUtils.parseURLs(address, map);
for (URL url : urls) {
url = url.addParameter(Constants.REGISTRY_KEY, url.getProtocol());
//最終的url都是registry協議頭
url = url.setProtocol(Constants.REGISTRY_PROTOCOL);
if ((provider && url.getParameter(Constants.REGISTER_KEY, true))
|| (!provider && url.getParameter(Constants.SUBSCRIBE_KEY, true))) {
registryList.add(url);
}
}
}
}
}
return registryList;
}
大家可以記下,原有地址是
zookeeper://127.0.0.1:2181/com.alibaba.dubbo.registry.RegistryService?application=kai-nina-server&dubbo=2.0.0&file=/Users/kai.yang/Documents/學習/dubbo&pid=52976×tamp=1540349933667
此方法返回所有需要注冊的注冊中心地址。繼續(xù),進入 doExportUrlsFor1Protocol(protocolConfig, registryURLs)方法,顯而易見,此方法會循環(huán)發(fā)布每個protocol,并注冊到所有注冊中心。
doExportUrlsFor1Protocol方法第一步會判斷上面賦值到generic,當不是generic時,dubbo會給你生成一個wapper,類似泛化類當包裝類,
private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) {
.....
//判斷是否為返泛化類,泛化類則生成wrapper,泛化所有方法名,否則methods為*
if (ProtocolUtils.isGeneric(generic)) {
map.put("generic", generic);
map.put("methods", Constants.ANY_VALUE);
} else {
String revision = Version.getVersion(interfaceClass, version);
if (revision != null && revision.length() > 0) {
map.put("revision", revision);
}
String[] methods = Wrapper.getWrapper(interfaceClass).getMethodNames();
if (methods.length == 0) {
logger.warn("NO method found in service interface " + interfaceClass.getName());
map.put("methods", Constants.ANY_VALUE);
} else {
map.put("methods", StringUtils.join(new HashSet<String>(Arrays.asList(methods)), ","));
}
......
//獲取ip,port
String host = this.findConfigedHosts(protocolConfig, registryURLs, map);
Integer port = this.findConfigedPorts(protocolConfig, name, map);
//生成服務的url,dubbo://172.18.166.201:20880/com.alibaba.dubbo.kai.api.HelloApi?anyhost=true&application=kai-nina-server&bind.ip=172.18.166.201&bind.port=20880&dubbo=2.0.0&generic=false&interface=com.alibaba.dubbo.kai.api.HelloApi&methods=sayHello,sayNihao&pid=63104&revision=0.0&server=netty4&side=provider×tamp=1540352013631&version=0.0
URL url = new URL(name, host, port, (contextPath == null || contextPath.length() == 0 ? "" : contextPath + "/") + path, map);
if (ExtensionLoader.getExtensionLoader(ConfiguratorFactory.class)
.hasExtension(url.getProtocol())) {
url = ExtensionLoader.getExtensionLoader(ConfiguratorFactory.class)
.getExtension(url.getProtocol()).getConfigurator(url).configure(url);
}
//最終發(fā)布,下面介紹
.....
}
請看生成wrapper泛化類示例:
public class Wrapper0 extends Wrapper{
public static String[] pns;
public static java.util.Map pts;
public static String[] mns = new String[]{"sayHello"};
public static String[] dmns = new String[]{"sayHello"};
public static Class[] mts0;
public String[] getPropertyNames() {
return pns;
}
public String[] getDeclaredMethodNames() {
return dmns;
}
public String[] getMethodNames() {
return mns;
}
public Class getPropertyType(String n) {
return (Class) pts.get(n);
}
public boolean hasProperty(String n) {
return pts.containsKey(n);
}
public void setPropertyValue(Object o, String n, Object v) {
com.alibaba.dubbo.kai.api.HelloApi w;
try {
w = ((com.alibaba.dubbo.kai.api.HelloApi) o);
} catch (Throwable e) {
throw new IllegalArgumentException(e);
}
throw new com.alibaba.dubbo.common.bytecode.NoSuchPropertyException("Not found property \"" + n + "\" filed or setter method in class com.alibaba.dubbo.kai.api.HelloApi.");
}
public Object getPropertyValue(Object o, String n) {
com.alibaba.dubbo.kai.api.HelloApi w;
try {
w = ((com.alibaba.dubbo.kai.api.HelloApi) o);
} catch (Throwable e) {
throw new IllegalArgumentException(e);
}
throw new com.alibaba.dubbo.common.bytecode.NoSuchPropertyException("Not found property \"" + n + "\" filed or setter method in class com.alibaba.dubbo.kai.api.HelloApi.");
}
public Object invokeMethod(Object o, String n, Class[] p, Object[] v) throws java.lang.reflect.InvocationTargetException {
com.alibaba.dubbo.kai.api.HelloApi w;
try {
w = ((com.alibaba.dubbo.kai.api.HelloApi) o);
} catch (Throwable e) {
throw new IllegalArgumentException(e);
}
try {
//和cglib寫法類似,不通過反射調用,效率更高
if ("sayHello".equals(n) && p.length == 0) {
return w.sayHello();
}
} catch (Throwable e) {
throw new java.lang.reflect.InvocationTargetException(e);
}
throw new com.alibaba.dubbo.common.bytecode.NoSuchMethodException("Not found method \"" + n + "\" in class com.alibaba.dubbo.kai.api.HelloApi.");
}
}
我們回頭看下服務發(fā)布對象圖,此wrapper為底層實現類,直接引用實際類進行調用,這中包裝方式是不是有點像cglib代理當實現。
下一步dubbo調用findConfigedHosts方法獲取本機服務器ip(非127.0.0.1的,可以學習下),findConfigedPorts獲取要發(fā)布的port,然后根據這一些列參數最終生成了服務地址:
dubbo://172.18.166.201:20880/com.alibaba.dubbo.kai.api.HelloApi?anyhost=true&application=kai-nina-server&bind.ip=172.18.166.201&bind.port=20880&dubbo=2.0.0&generic=false&interface=com.alibaba.dubbo.kai.api.HelloApi&methods=sayHello,sayNihao&pid=63104&revision=0.0&server=netty4&side=provider×tamp=1540352013631&version=0.0
有地址了,是不是該發(fā)布了,繼續(xù):
String scope = url.getParameter(Constants.SCOPE_KEY);
//配置為none不暴露
if (!Constants.SCOPE_NONE.toString().equalsIgnoreCase(scope)) {
//配置不是remote的情況下做本地暴露 (配置為remote,則表示只暴露遠程服務)
if (!Constants.SCOPE_REMOTE.toString().equalsIgnoreCase(scope)) {
exportLocal(url);
}
//如果配置不是local則暴露為遠程服務.(配置為local,則表示只暴露本地服務)
if (!Constants.SCOPE_LOCAL.toString().equalsIgnoreCase(scope)) {
if (logger.isInfoEnabled()) {
logger.info("Export dubbo service " + interfaceClass.getName() + " to url " + url);
}
if (registryURLs != null && registryURLs.size() > 0
&& url.getParameter("register", true)) {
for (URL registryURL : registryURLs) {
//發(fā)布遠程服務
Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString()));
Exporter<?> exporter = protocol.export(invoker);
exporters.add(exporter);
}
} else {
//沒有配置注冊中心時,只發(fā)布不注冊
Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, url);
Exporter<?> exporter = protocol.export(invoker);
exporters.add(exporter);
}
}
}
scope參數就不再解釋了,dubbo會先發(fā)布本地服務,表示在一個jvm中,可以引用不通過遠程服務(現在版本默認都會開啟,大圖有中詳細流程),然后開始發(fā)布遠程服務,我們直接調到遠程發(fā)布都核心代碼(本地發(fā)布可以參考大圖,邏輯類似,只是本地會經過dubbo的層層filer生成最終的invoker,此時invoker將是通過dubbo包裝過的):
Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString()));
Exporter<?> exporter = protocol.export(invoker);
exporters.add(exporter);
重點來了!看方法名意思是dubbo通過代理工廠生成一個invoker,我們先看入參
- ref --- 依賴注入的引用
- interfaceClass --- 引用接口類型
- url ---服務發(fā)布url
前兩個就不贅述,主要看第三個url,此時生成傳入的url又是什么呢?
registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString())方法我們看到是在registryUrl中添加了個map參數,key是export(上面記錄的dubbo服務地址),所以此時傳入的是registry協議頭的注冊地址:
registry://127.0.0.1:2181/com.alibaba.dubbo.registry.RegistryService?application=kai-nina-server&dubbo=2.0.0&export=dubbo%3A%2F%2F10.254.1.113%3A20880%2Fcom.alibaba.dubbo.kai.api.HelloApi%3Fanyhost%3Dtrue%26application%3Dkai-nina-server%26bind.ip%3D10.254.1.113%26bind.port%3D20880%26dubbo%3D2.0.0%26generic%3Dfalse%26interface%3Dcom.alibaba.dubbo.kai.api.HelloApi%26methods%3DsayHello%2CsayNihao%26pid%3D79497%26revision%3D0.0%26server%3Dnetty4%26side%3Dprovider%26timestamp%3D1540364859493%26version%3D0.0&file=/Users/kai.yang/Documents/學習/dubbo&pid=79497®istry=zookeeper×tamp=1540364857840
入參解決了,再來看下此時的proxyFactory是什么?
//根據擴展點添加的適配工廠
private static final ProxyFactory proxyFactory = ExtensionLoader.getExtensionLoader(ProxyFactory.class).getAdaptiveExtension();
那么我們要怎么找到這個類呢?記得dubbo的spi原理的,一定知道此時先看配置文件,找其是否又適配器類,沒有的話,看接口是否又適配器方法,此時有,dubbo一定會動態(tài)生成一個適配器工廠類來使用(具體內容,可以看上一篇文章),閑言少敘,我們最終會找到此類為:
public class ProxyFactory$Adaptive implements com.alibaba.dubbo.rpc.ProxyFactory {
public com.alibaba.dubbo.rpc.Invoker getInvoker(java.lang.Object arg0, java.lang.Class arg1, com.alibaba.dubbo.common.URL arg2) throws com.alibaba.dubbo.rpc.RpcException {
if (arg2 == null) throw new IllegalArgumentException("url == null");
com.alibaba.dubbo.common.URL url = arg2;
String extName = url.getParameter("proxy", "javassist");
if (extName == null)
throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.ProxyFactory) name from url(" + url.toString() + ") use keys([proxy])");
com.alibaba.dubbo.rpc.ProxyFactory extension = (com.alibaba.dubbo.rpc.ProxyFactory) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.ProxyFactory.class).getExtension(extName);
return extension.getInvoker(arg0, arg1, arg2);
}
public java.lang.Object getProxy(com.alibaba.dubbo.rpc.Invoker arg0) throws com.alibaba.dubbo.rpc.RpcException {
if (arg0 == null) throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument == null");
if (arg0.getUrl() == null)
throw new IllegalArgumentException("com.alibaba.dubbo.rpc.Invoker argument getUrl() == null");
com.alibaba.dubbo.common.URL url = arg0.getUrl();
//默認采用javassist工廠
String extName = url.getParameter("proxy", "javassist");
if (extName == null)
throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.ProxyFactory) name from url(" + url.toString() + ") use keys([proxy])");
com.alibaba.dubbo.rpc.ProxyFactory extension = (com.alibaba.dubbo.rpc.ProxyFactory) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.ProxyFactory.class).getExtension(extName);
return extension.getProxy(arg0);
}
}
我們發(fā)現此時工廠適配器會在你不指定默認proxy的情況下,默認采用javassistFactory(name=javassist的工廠類,配置文件中可以找到),那么我們看看javassistFactory里面做了什么
public <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) {
//生成對應的泛化wapper,此時class為實現類
final Wrapper wrapper = Wrapper.getWrapper(proxy.getClass().getName().indexOf('$') < 0 ? proxy.getClass() : type);
//每次返回一個新的代理invoker,實際調用上面的wrapper
return new AbstractProxyInvoker<T>(proxy, type, url) {
@Override
protected Object doInvoke(T proxy, String methodName,
Class<?>[] parameterTypes,
Object[] arguments) throws Throwable {
return wrapper.invokeMethod(proxy, methodName, parameterTypes, arguments);
}
};
}
到此,模型圖中最下面三個已出世
當然如果你仔細看了我的大圖的話,會發(fā)現此時少了一個步驟:
那這個StubProxyFactoryWrapper是哪來的呢?對了,還是靠dubbo的擴展機制,記得上篇介紹了createExtension(String name)方法,此時會找到配置文件中的所有的wrapper類進行層層包裝,不過此類在發(fā)布過程中沒有實際作用,所以此地忽略。
獲取到invoker了,下面進入最最最核心的發(fā)布了!
Exporter<?> exporter = protocol.export(invoker);
先思考下,protocol現在是哪個類?熟悉套路的朋友們一定猜到了,此處為Protocol$Adaptive類。上篇中我們專門解釋過此類的由來,這下用到了。還記得其中關鍵代碼:
String extName = (url.getProtocol() == null ? "dubbo" : url.getProtocol());
if (extName == null)
throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.rpc.Protocol) name from url(" + url.toString() + ") use keys([protocol])");
com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class).getExtension(extName);
那此時適配到的extension應該是哪個類呢?哈哈,可能有人說是DubboProtocol,或者RegistryProtocol,其實此時獲取到的是個層層wrapper包裝后的RegistryProtocol,再看眼配置文件
registry=com.alibaba.dubbo.registry.integration.RegistryProtocol
dubbo=com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol
filter=com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper
listener=com.alibaba.dubbo.rpc.protocol.ProtocolListenerWrapper
mock=com.alibaba.dubbo.rpc.support.MockProtocol
injvm=com.alibaba.dubbo.rpc.protocol.injvm.InjvmProtocol
rmi=com.alibaba.dubbo.rpc.protocol.rmi.RmiProtocol
hessian=com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol
com.alibaba.dubbo.rpc.protocol.http.HttpProtocol
com.alibaba.dubbo.rpc.protocol.webservice.WebServiceProtocol
thrift=com.alibaba.dubbo.rpc.protocol.thrift.ThriftProtocol
memcached=com.alibaba.dubbo.rpc.protocol.memcached.MemcachedProtocol
redis=com.alibaba.dubbo.rpc.protocol.redis.RedisProtocol
其中有兩個wrapper,所以此處會先進過ProtocolFilterWrapper和ProtocolListenerWrapper最后才會到RegistryProtocol中,當然兩個wrapper的export方法都屏蔽了REGISTRY_PROTOCOL的協議,所以暫且跳過這兩類,
直接進入RegistryProtocol中。
if (Constants.REGISTRY_PROTOCOL.equals(invoker.getUrl().getProtocol())) {
//registry策略直接進行調用
return protocol.export(invoker);
}
看下RegistryProtocol:
//重點一、生成最終的exporter
final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker);
//重點二、注冊provider
final Registry registry = getRegistry(originInvoker);
final URL registedProviderUrl = getRegistedProviderUrl(originInvoker);
registry.register(registedProviderUrl);
// 重點三、訂閱數據
final URL overrideSubscribeUrl = getSubscribedOverrideUrl(registedProviderUrl);
final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker);
overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);
registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);
- 重點一 生成最終的exporter
請看大圖,進入doLocalExport()方法后會先創(chuàng)建個invoker的委托類
new InvokerDelegete<T>(originInvoker, getProviderUrl(originInvoker))
此時出入的url我們解析出是:
dubbo://10.254.1.113:20880/com.alibaba.dubbo.kai.api.HelloApi?anyhost=true&application=kai-nina-server&bind.ip=10.254.1.113&bind.port=20880&dubbo=2.0.0&generic=false&interface=com.alibaba.dubbo.kai.api.HelloApi&methods=sayHello,sayNihao&pid=88182&revision=0.0&server=netty4&side=provider×tamp=1540366683633&version=0.0
下面創(chuàng)建了個new ExporterChangeableWrapper()類用來做為緩存的可變動重新發(fā)布包裝類,而其入參有兩個:
- originInvoker --->我們上一步就生成好的invoker,原始invoker
- protocol.export(invokerDelegete)-->目標協議發(fā)布的invoker
此時的protocol肯定還是Protocol$Adaptive,按照上面的分析,此時得到的最終類肯定是DubboProtocol了。當然結果是這個,過程一樣很崎嶇,還有兩個wrapper等這個呢,先看ProtocolFilterWrapper:
Invoker<T> last = invoker;
//獲取所有配置Activate的此group=provider下的filter類,形成filer鏈
List<Filter> filters = ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl(), key, group);
if (filters.size() > 0) {
for (int i = filters.size() - 1; i >= 0; i--) {
final Filter filter = filters.get(i);
final Invoker<T> next = last;
last = new Invoker<T>() {
.....
public Result invoke(Invocation invocation) throws RpcException {
return filter.invoke(next, invocation);
}
.....
}
}
這就是dubbo的過濾器調用鏈的形成,在后面的調用過程中都會用到。下面ProtocolListenerWrapper類的export()方法:
public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
....
//ListenerExporterWrapper包裝了監(jiān)聽器進去
return new ListenerExporterWrapper<T>(protocol.export(invoker),
Collections.unmodifiableList(ExtensionLoader.getExtensionLoader(ExporterListener.class)
.getActivateExtension(invoker.getUrl(), Constants.EXPORTER_LISTENER_KEY)));
}
再看一下ListenerExporterWrapper:
public ListenerExporterWrapper(Exporter<T> exporter, List<ExporterListener> listeners) {
if (exporter == null) {
throw new IllegalArgumentException("exporter == null");
}
this.exporter = exporter;
this.listeners = listeners;
if (listeners != null && listeners.size() > 0) {
RuntimeException exception = null;
for (ExporterListener listener : listeners) {
if (listener != null) {
try {
//監(jiān)聽者模式,進行發(fā)布完后的事件處理
listener.exported(this);
} catch (RuntimeException t) {
logger.error(t.getMessage(), t);
exception = t;
}
}
}
if (exception != null) {
throw exception;
}
}
}
顯然這是一個后置的監(jiān)聽者插入口,那就和我們的發(fā)布過程關系不大,先跳過,繼續(xù)向下走,終于該到我們的DubboProtocol發(fā)布了:
public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
URL url = invoker.getUrl();
// export service. 緩存key
String key = serviceKey(url);
//重點 一 dubbo 的expoter
DubboExporter<T> exporter = new DubboExporter<T>(invoker, key, exporterMap);
exporterMap.put(key, exporter);
//export an stub service for dispaching event,
Boolean isStubSupportEvent = url.getParameter(Constants.STUB_EVENT_KEY, Constants.DEFAULT_STUB_EVENT);
Boolean isCallbackservice = url.getParameter(Constants.IS_CALLBACK_SERVICE, false);
if (isStubSupportEvent && !isCallbackservice) {
String stubServiceMethods = url.getParameter(Constants.STUB_EVENT_METHODS_KEY);
if (stubServiceMethods == null || stubServiceMethods.length() == 0) {
if (logger.isWarnEnabled()) {
logger.warn(new IllegalStateException("consumer [" + url.getParameter(Constants.INTERFACE_KEY) +
"], has set stubproxy support event ,but no stub methods founded."));
}
} else {
stubServiceMethodsMap.put(url.getServiceKey(), stubServiceMethods);
}
}
// 重點二 開啟服務
openServer(url);
return exporter;
}
看重點(stub存根不影響主流程,此處略過),
new DubboExporter<T>(invoker, key, exporterMap)-->生成了一個對應dubbo的Exporter
openServer(url) -->開啟socket服務
這里邊DubboExporter對象為最終返回對象,它緩存了我們的invoker,下面重點就是openServer去發(fā)布服務了。
private void openServer(URL url) {
// find server.
String key = url.getAddress();
//client 也可以暴露一個只有server可以調用的服務。
boolean isServer = url.getParameter(Constants.IS_SERVER_KEY, true);
if (isServer) {
ExchangeServer server = serverMap.get(key);
if (server == null) {
//開啟新服務
serverMap.put(key, createServer(url));
} else {
//server支持reset,配合override功能使用
server.reset(url);
}
}
}
開啟服務,進到了createServer(url)方法內
private ExchangeServer createServer(URL url) {
....
//開通服務方法
server = Exchangers.bind(url, requestHandler);
....
}
此處重點落到了Exchangers.bind(url, requestHandler)中,首先分析入參
- url--》dubbo協議頭服務地址,前面透出過來
- requestHandle--》服務通信調用的最終處理類,讓我看下此類
private ExchangeHandler requestHandler = new ExchangeHandlerAdapter() {
public Object reply(ExchangeChannel channel, Object message) throws RemotingException {
if (message instanceof Invocation) {
Invocation inv = (Invocation) message;
Invoker<?> invoker = getInvoker(channel, inv);
//如果是callback 需要處理高版本調用低版本的問題
if (Boolean.TRUE.toString().equals(inv.getAttachments().get(IS_CALLBACK_SERVICE_INVOKE))) {
String methodsStr = invoker.getUrl().getParameters().get("methods");
boolean hasMethod = false;
if (methodsStr == null || methodsStr.indexOf(",") == -1) {
hasMethod = inv.getMethodName().equals(methodsStr);
} else {
String[] methods = methodsStr.split(",");
for (String method : methods) {
if (inv.getMethodName().equals(method)) {
hasMethod = true;
break;
}
}
}
if (!hasMethod) {
logger.warn(new IllegalStateException("The methodName " + inv.getMethodName() + " not found in callback service interface ,invoke will be ignored. please update the api interface. url is:" + invoker.getUrl()) + " ,invocation is :" + inv);
return null;
}
}
RpcContext.getContext().setRemoteAddress(channel.getRemoteAddress());
return invoker.invoke(inv);
}
throw new RemotingException(channel, "Unsupported request: " + message == null ? null : (message.getClass().getName() + ": " + message) + ", channel: consumer: " + channel.getRemoteAddress() + " --> provider: " + channel.getLocalAddress());
}
@Override
public void received(Channel channel, Object message) throws RemotingException {
if (message instanceof Invocation) {
reply((ExchangeChannel) channel, message);
} else {
super.received(channel, message);
}
}
@Override
public void connected(Channel channel) throws RemotingException {
invoke(channel, Constants.ON_CONNECT_KEY);
}
@Override
public void disconnected(Channel channel) throws RemotingException {
if (logger.isInfoEnabled()) {
logger.info("disconected from " + channel.getRemoteAddress() + ",url:" + channel.getUrl());
}
invoke(channel, Constants.ON_DISCONNECT_KEY);
}
private void invoke(Channel channel, String methodKey) {
Invocation invocation = createInvocation(channel, channel.getUrl(), methodKey);
if (invocation != null) {
try {
received(channel, invocation);
} catch (Throwable t) {
logger.warn("Failed to invoke event method " + invocation.getMethodName() + "(), cause: " + t.getMessage(), t);
}
}
}
private Invocation createInvocation(Channel channel, URL url, String methodKey) {
String method = url.getParameter(methodKey);
if (method == null || method.length() == 0) {
return null;
}
RpcInvocation invocation = new RpcInvocation(method, new Class<?>[0], new Object[0]);
invocation.setAttachment(Constants.PATH_KEY, url.getPath());
invocation.setAttachment(Constants.GROUP_KEY, url.getParameter(Constants.GROUP_KEY));
invocation.setAttachment(Constants.INTERFACE_KEY, url.getParameter(Constants.INTERFACE_KEY));
invocation.setAttachment(Constants.VERSION_KEY, url.getParameter(Constants.VERSION_KEY));
if (url.getParameter(Constants.STUB_EVENT_KEY, false)) {
invocation.setAttachment(Constants.STUB_EVENT_KEY, Boolean.TRUE.toString());
}
return invocation;
}
};
熟悉netty編程的同學應該會感動眼熟,這個handler和netty中處理message的channelHandler很相似。沒錯,這個handler最終就是會被包在netty的channelHandler中的實際消息處理類。
我們此處不分析處理類,調用過程會分析。我們進入bind方法:
public static ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
....
url = url.addParameterIfAbsent(Constants.CODEC_KEY, "exchange");
return getExchanger(url).bind(url, handler);
}
dubbo在這里去getExchander(url),用來方便用戶可以自己擴展通信框架,繼續(xù)
public static Exchanger getExchanger(URL url) {
String type = url.getParameter(Constants.EXCHANGER_KEY, Constants.DEFAULT_EXCHANGER);
return getExchanger(type);
}
public static Exchanger getExchanger(String type) {
return ExtensionLoader.getExtensionLoader(Exchanger.class).getExtension(type);
}
在沒有指定exchanger時,dubbo默認實現
DEFAULT_EXCHANGER = "header"
所以此處的exchanger從配置文件中我們可以找到HeaderExchanger
public ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
return new HeaderExchangeServer(Transporters.bind(url, new DecodeHandler(new HeaderExchangeHandler(handler))));
}
此處又new出了個new HeaderExchangeServer(),入參通過Transporters的靜態(tài)方法生成了一個server
Transporters.bind(url, new DecodeHandler(new HeaderExchangeHandler(handler)))
繼續(xù)
public static Server bind(URL url, ChannelHandler... handlers) throws RemotingException {
if (url == null) {
throw new IllegalArgumentException("url == null");
}
if (handlers == null || handlers.length == 0) {
throw new IllegalArgumentException("handlers == null");
}
ChannelHandler handler;
if (handlers.length == 1) {
handler = handlers[0];
} else {
handler = new ChannelHandlerDispatcher(handlers);
}
//一樣的套路,將會獲取ExtensionLoader.getExtensionLoader(Transporter.class).getAdaptiveExtension()類,此處獲取到Transporter$Adaptive
return getTransporter().bind(url, handler);
}
讓我們看下獲取的Transporter$Adaptive類:
public class Transporter$Adaptive implements com.alibaba.dubbo.remoting.Transporter {
public com.alibaba.dubbo.remoting.Client connect(com.alibaba.dubbo.common.URL arg0, com.alibaba.dubbo.remoting.ChannelHandler arg1) throws com.alibaba.dubbo.remoting.RemotingException {
if (arg0 == null) throw new IllegalArgumentException("url == null");
com.alibaba.dubbo.common.URL url = arg0;
String extName = url.getParameter("client", url.getParameter("transporter", "netty"));
if (extName == null)
throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.remoting.Transporter) name from url(" + url.toString() + ") use keys([client, transporter])");
com.alibaba.dubbo.remoting.Transporter extension = (com.alibaba.dubbo.remoting.Transporter) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.remoting.Transporter.class).getExtension(extName);
return extension.connect(arg0, arg1);
}
public com.alibaba.dubbo.remoting.Server bind(com.alibaba.dubbo.common.URL arg0, com.alibaba.dubbo.remoting.ChannelHandler arg1) throws com.alibaba.dubbo.remoting.RemotingException {
if (arg0 == null) throw new IllegalArgumentException("url == null");
com.alibaba.dubbo.common.URL url = arg0;
// 不指定默認為netty
String extName = url.getParameter("server", url.getParameter("transporter", "netty"));
if (extName == null)
throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.remoting.Transporter) name from url(" + url.toString() + ") use keys([server, transporter])");
com.alibaba.dubbo.remoting.Transporter extension = (com.alibaba.dubbo.remoting.Transporter) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.remoting.Transporter.class).getExtension(extName);
return extension.bind(arg0, arg1);
}
}
顯然在不指定任務通訊協議時,采用netty協議,讓我們進入NettyTransporter
public class NettyTransporter implements Transporter {
public static final String NAME = "netty4";
public Server bind(URL url, ChannelHandler listener) throws RemotingException {
return new NettyServer(url, listener);
}
public Client connect(URL url, ChannelHandler listener) throws RemotingException {
return new NettyClient(url, listener);
}
}
明顯此處調用new了一個NettyServer(url,listener),進入NettyServer,構造方法中調用父類的構造方法,抽象類處理完基本參數后,調用子類實現的模版方法的doOpen(),此處熟悉的netty操作映入眼簾(終于發(fā)布服務了?。?。
public AbstractServer(URL url, ChannelHandler handler) throws RemotingException {
super(url, handler);
localAddress = getUrl().toInetSocketAddress();
String bindIp = getUrl().getParameter(Constants.BIND_IP_KEY, getUrl().getHost());
int bindPort = getUrl().getParameter(Constants.BIND_PORT_KEY, getUrl().getPort());
if (url.getParameter(Constants.ANYHOST_KEY, false) || NetUtils.isInvalidLocalHost(bindIp)) {
bindIp = NetUtils.ANYHOST;
}
bindAddress = new InetSocketAddress(bindIp, bindPort);
this.accepts = url.getParameter(Constants.ACCEPTS_KEY, Constants.DEFAULT_ACCEPTS);
this.idleTimeout = url.getParameter(Constants.IDLE_TIMEOUT_KEY, Constants.DEFAULT_IDLE_TIMEOUT);
try {
//子類實現模版方法,開啟服務
doOpen();
if (logger.isInfoEnabled()) {
logger.info("Start " + getClass().getSimpleName() + " bind " + getBindAddress() + ", export " + getLocalAddress());
}
} catch (Throwable t) {
throw new RemotingException(url.toInetSocketAddress(), null, "Failed to bind " + getClass().getSimpleName()
+ " on " + getLocalAddress() + ", cause: " + t.getMessage(), t);
}
//fixme replace this with better method
DataStore dataStore = ExtensionLoader.getExtensionLoader(DataStore.class).getDefaultExtension();
executor = (ExecutorService) dataStore.get(Constants.EXECUTOR_SERVICE_COMPONENT_KEY, Integer.toString(url.getPort()));
}
public NettyServer(URL url, ChannelHandler handler) throws RemotingException {
//調用父類的抽象方法
super(url, ChannelHandlers.wrap(handler, ExecutorUtil.setThreadName(url, SERVER_THREAD_POOL_NAME)));
}
//模版方法
@Override
protected void doOpen() throws Throwable {
NettyHelper.setNettyLoggerFactory();
bootstrap = new ServerBootstrap();
bossGroup = new NioEventLoopGroup(1, new DefaultThreadFactory("NettyServerBoss", true));
workerGroup = new NioEventLoopGroup(getUrl().getPositiveParameter(Constants.IO_THREADS_KEY, Constants.DEFAULT_IO_THREADS),
new DefaultThreadFactory("NettyServerWorker", true));
final NettyServerHandler nettyServerHandler = new NettyServerHandler(getUrl(), this);
channels = nettyServerHandler.getChannels();
bootstrap.group(bossGroup, workerGroup)
.channel(NioServerSocketChannel.class)
//該參數的作用就是禁止使用Nagle算法,使用于小數據即時傳輸
.childOption(ChannelOption.TCP_NODELAY, Boolean.TRUE)
//對應于套接字選項中的SO_REUSEADDR,這個參數表示允許重復使用本地地址和端口
.childOption(ChannelOption.SO_REUSEADDR, Boolean.TRUE)
//分配Buf,管理類指定
.childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT)
.childHandler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec(), getUrl(), NettyServer.this);
ch.pipeline()//.addLast("logging",new LoggingHandler(LogLevel.INFO))//for debug
.addLast("decoder", adapter.getDecoder())
.addLast("encoder", adapter.getEncoder())
.addLast("handler", nettyServerHandler);
}
});
// bind
ChannelFuture channelFuture = bootstrap.bind(getBindAddress());
channelFuture.syncUninterruptibly();
channel = channelFuture.channel();
}
而其消息處理的channelHander為,此處注意傳入實際消息處理類為this!說明NetterServer一定實現了ChannelHander,讓我們找找
final NettyServerHandler nettyServerHandler = new NettyServerHandler(getUrl(), this);
果然:
在其AbstractPeer父抽象類中,我們看到
public abstract class AbstractPeer implements Endpoint, ChannelHandler {
//實際處理消息handler
private final ChannelHandler handler;
private volatile URL url;
// closing closed分別表示關閉流程中、完成關閉
private volatile boolean closing;
private volatile boolean closed;
那此刻的這個ChannelHandler又是誰呢?讓我們回到NettyServer的構造
super(url, ChannelHandlers.wrap(handler, ExecutorUtil.setThreadName(url, SERVER_THREAD_POOL_NAME)));
注意這個ChannelHandlers.wrap()方法,這就是我們最終生成的handler!
那他又是什么東西呢?
public class ChannelHandlers {
private static ChannelHandlers INSTANCE = new ChannelHandlers();
protected ChannelHandlers() {
}
public static ChannelHandler wrap(ChannelHandler handler, URL url) {
return ChannelHandlers.getInstance().wrapInternal(handler, url);
}
protected static ChannelHandlers getInstance() {
return INSTANCE;
}
static void setTestingChannelHandlers(ChannelHandlers instance) {
INSTANCE = instance;
}
protected ChannelHandler wrapInternal(ChannelHandler handler, URL url) {
return new MultiMessageHandler(new HeartbeatHandler(ExtensionLoader.getExtensionLoader(Dispatcher.class)
.getAdaptiveExtension().dispatch(handler, url)));
}
}
發(fā)現他又又是層層包裝,每一層只處理一部分任務
- MultiMessageHandler 處理Multi類型,一般如文件流
- HeartbeatHandler包裝了心跳請求消息
- ExtensionLoader.getExtensionLoader(Dispatcher.class)
.getAdaptiveExtension().dispatch()最終得到類
public class Dispatcher$Adaptive implements com.alibaba.dubbo.remoting.Dispatcher {
public com.alibaba.dubbo.remoting.ChannelHandler dispatch(com.alibaba.dubbo.remoting.ChannelHandler arg0, com.alibaba.dubbo.common.URL arg1) {
if (arg1 == null) throw new IllegalArgumentException("url == null");
com.alibaba.dubbo.common.URL url = arg1;
String extName = url.getParameter("dispatcher", url.getParameter("dispather", url.getParameter("channel.handler", "all")));
if (extName == null)
throw new IllegalStateException("Fail to get extension(com.alibaba.dubbo.remoting.Dispatcher) name from url(" + url.toString() + ") use keys([dispatcher, dispather, channel.handler])");
com.alibaba.dubbo.remoting.Dispatcher extension = (com.alibaba.dubbo.remoting.Dispatcher) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.remoting.Dispatcher.class).getExtension(extName);
return extension.dispatch(arg0, arg1);
}
}
所以默認會生成AllDispatcher,然后
public class AllDispatcher implements Dispatcher {
public static final String NAME = "all";
public ChannelHandler dispatch(ChannelHandler handler, URL url) {
return new AllChannelHandler(handler, url);
}
}
AllDispatcher委派了AllChannelHandler處理消息任務。
我去,終于找到最終處理消息任務的handler。。。下面讓我們整體看下dubbo中exporter服務發(fā)布的相關實體:
圖中大致畫出了ChannelHander從屬于Server,invoker從屬于Exporter,中線通過protocol進行管理,最終回歸到ServiceConfig中。到此,服務終于發(fā)布出來了。
但你先別停,還有個注冊訂閱呢。。。。。。
繼續(xù)看大圖,注冊邏輯也在RegistryProtocol中
public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {
//export invoker
final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker);
//registry provider
final Registry registry = getRegistry(originInvoker);
final URL registedProviderUrl = getRegistedProviderUrl(originInvoker);
//注冊zookeeper
registry.register(registedProviderUrl);
// 訂閱override數據
// FIXME 提供者訂閱時,會影響同一JVM即暴露服務,又引用同一服務的的場景,因為subscribed以服務名為緩存的key,導致訂閱信息覆蓋。
final URL overrideSubscribeUrl = getSubscribedOverrideUrl(registedProviderUrl);
final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker);
overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);
registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);
首先 getRegistry(originInvoker)獲取了Registry實體,又是老套路
private Registry getRegistry(final Invoker<?> originInvoker) {
URL registryUrl = originInvoker.getUrl();
if (Constants.REGISTRY_PROTOCOL.equals(registryUrl.getProtocol())) {
String protocol = registryUrl.getParameter(Constants.REGISTRY_KEY, Constants.DEFAULT_DIRECTORY);
//重新賦值協議頭,將REGISTRY_KEY=registry的參數取出,此處為zookeeper
registryUrl = registryUrl.setProtocol(protocol).removeParameter(Constants.REGISTRY_KEY);
}
return registryFactory.getRegistry(registryUrl);
}
從registryFactory獲取實體,這工廠有是誰?
public class RegistryProtocol implements Protocol {
....
private RegistryFactory registryFactory;
private ProxyFactory proxyFactory;
我們發(fā)現registryFactory是成員變量,根據上節(jié)spi知識,此處會通過 injectExtension(T instance) 方法自動注入,結果為RegistryFactory$Adaptive,url已被改成zookeeper。你懂得,想必獲得的一定是個ZookeeperRegistry類(因為此時協議頭已被改為zookeeper,根據擴展規(guī)則,會找到ZookeeperRegistry)。
沒錯,就是他。
明白了ZookeeperRegistry是誰,就簡單了,直接看代碼,先回調父類FailbackRegistry的 register(URL url):
public void register(URL url) {
if (destroyed.get()){
return;
}
super.register(url);
failedRegistered.remove(url);
failedUnregistered.remove(url);
try {
// 模版方法,向服務器端發(fā)送注冊請求
doRegister(url);
} catch (Exception e) {
Throwable t = e;
// 如果開啟了啟動時檢測,則直接拋出異常,對應標簽check
boolean check = getUrl().getParameter(Constants.CHECK_KEY, true)
&& url.getParameter(Constants.CHECK_KEY, true)
&& !Constants.CONSUMER_PROTOCOL.equals(url.getProtocol());
boolean skipFailback = t instanceof SkipFailbackWrapperException;
if (check || skipFailback) {
if (skipFailback) {
t = t.getCause();
}
throw new IllegalStateException("Failed to register " + url + " to registry " + getUrl().getAddress() + ", cause: " + t.getMessage(), t);
} else {
logger.error("Failed to register " + url + ", waiting for retry, cause: " + t.getMessage(), t);
}
// 將失敗的注冊請求記錄到失敗列表,定時重試
failedRegistered.add(url);
}
}
方法中做了錯誤重試的容錯機制,還有對配置文件中服務端check參數對使用(是否啟動檢查),然后還是一個模版方法,調用具體類對實現,當然調用的是zookeeperRegister的doRegister方法:
protected void doRegister(URL url) {
try {
zkClient.create(toUrlPath(url), url.getParameter(Constants.DYNAMIC_KEY, true));
} catch (Throwable e) {
throw new RpcException("Failed to register " + url + " to zookeeper " + getUrl() + ", cause: " + e.getMessage(), e);
}
}
代碼又都熟悉了吧,zkClient直接添加地址,地址為/dubbo/接口名/服務url,如:
/dubbo/com.alibaba.dubbo.kai.api.HelloApi/providers/dubbo%3A%2F%2F192.168.199.130%3A20880%2Fcom.alibaba.dubbo.kai.api.HelloApi%3Fanyhost%3Dtrue%26application%3Dkai-nina-server%26dubbo%3D2.0.0%26generic%3Dfalse%26interface%3Dcom.alibaba.dubbo.kai.api.HelloApi%26methods%3DsayHello%2CsayNihao%26pid%3D61946%26revision%3D0.0%26server%3Dnetty4%26side%3Dprovider%26timestamp%3D1540390897149%26version%3D0.0
到這里,注冊結束。按照我們使用zookeeper的習慣,是不是該開始添加監(jiān)聽了?
對,dubbo也是一樣的邏輯。
final URL overrideSubscribeUrl = getSubscribedOverrideUrl(registedProviderUrl);
final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker);
overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);
registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);
首先獲得了個overrideSubscribeUrl,用來做為緩存監(jiān)聽器key使用,url為
provider://192.168.199.130:20880/com.alibaba.dubbo.kai.api.HelloApi?anyhost=true&application=kai-nina-server&category=configurators&check=false&dubbo=2.0.0&generic=false&interface=com.alibaba.dubbo.kai.api.HelloApi&methods=sayHello,sayNihao&pid=70508&revision=0.0&server=netty4&side=provider×tamp=1540416661404&version=0.0
發(fā)現上邊又一個FIXME的注釋,說明當前版本有此問題,還并沒有解決(因為都改為了provider協議,所以同一jvm引用統一服務時,監(jiān)聽器會發(fā)生覆蓋),但我們暫時沒有重復服務,還沒有此問題。
最后到了registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener)方法。
和 register(URL url)方法寫法類似,一個失敗重試模版方法,最后調用zookeeperRegistry到 doSubscribe(url, listener)方法:
protected void doSubscribe(final URL url, final NotifyListener listener) {
try {
if (Constants.ANY_VALUE.equals(url.getServiceInterface())) {
...
//略過此邏輯,泛化支持
} else {
List<URL> urls = new ArrayList<URL>();
for (String path : toCategoriesPath(url)) {
ConcurrentMap<NotifyListener, ChildListener> listeners = zkListeners.get(url);
if (listeners == null) {
zkListeners.putIfAbsent(url, new ConcurrentHashMap<NotifyListener, ChildListener>());
listeners = zkListeners.get(url);
}
ChildListener zkListener = listeners.get(listener);
if (zkListener == null) {
listeners.putIfAbsent(listener, new ChildListener() {
public void childChanged(String parentPath, List<String> currentChilds) {
ZookeeperRegistry.this.notify(url, listener, toUrlsWithEmpty(url, parentPath, currentChilds));
}
});
zkListener = listeners.get(listener);
}
zkClient.create(path, false);
//添加節(jié)點監(jiān)聽
List<String> children = zkClient.addChildListener(path, zkListener);
if (children != null) {
urls.addAll(toUrlsWithEmpty(url, path, children));
}
}
notify(url, listener, urls);
}
} catch (Throwable e) {
throw new RpcException("Failed to subscribe " + url + " to zookeeper " + getUrl() + ", cause: " + e.getMessage(), e);
}
}
添加訂閱監(jiān)聽方法就不贅述(不熟悉都朋友可以學習下zk操作),但注意服務端監(jiān)聽的地址為/dubbo/com.alibaba.dubbo.kai.api.HelloApi/configurators,表示你如果在admin后臺更新相關配置時,會監(jiān)聽到,同步服務端。
最后dubbo調用了 notify(url, listener, urls)方法,使用監(jiān)聽者模式來通知更新操作。
protected void notify(URL url, NotifyListener listener, List<URL> urls) {
if (url == null) {
throw new IllegalArgumentException("notify url == null");
}
if (listener == null) {
throw new IllegalArgumentException("notify listener == null");
}
try {
doNotify(url, listener, urls);
} catch (Exception t) {
// 將失敗的通知請求記錄到失敗列表,定時重試
Map<NotifyListener, List<URL>> listeners = failedNotified.get(url);
if (listeners == null) {
failedNotified.putIfAbsent(url, new ConcurrentHashMap<NotifyListener, List<URL>>());
listeners = failedNotified.get(url);
}
listeners.put(listener, urls);
logger.error("Failed to notify for subscribe " + url + ", waiting for retry, cause: " + t.getMessage(), t);
}
}
一樣都套路,模版模式,調用doNotify(url, listener, urls)方法:
protected void notify(URL url, NotifyListener listener, List<URL> urls) {
......
//調用監(jiān)聽者的通知方法
for (Map.Entry<String, List<URL>> entry : result.entrySet()) {
String category = entry.getKey();
List<URL> categoryList = entry.getValue();
categoryNotified.put(category, categoryList);
saveProperties(url);
listener.notify(categoryList);
}
}
看,最終又通知會了一開始創(chuàng)建的監(jiān)聽者OverrideListener,其為RegistryProtocol的內部類:
private class OverrideListener implements NotifyListener {
private final URL subscribeUrl;
private final Invoker originInvoker;
public OverrideListener(URL subscribeUrl, Invoker originalInvoker) {
this.subscribeUrl = subscribeUrl;
this.originInvoker = originalInvoker;
}
/**
* @param urls 已注冊信息列表,總不為空,含義同{@link com.alibaba.dubbo.registry.RegistryService#lookup(URL)}的返回值。
*/
public synchronized void notify(List<URL> urls) {
logger.debug("original override urls: " + urls);
List<URL> matchedUrls = getMatchedUrls(urls, subscribeUrl);
logger.debug("subscribe url: " + subscribeUrl + ", override urls: " + matchedUrls);
//沒有匹配的
if (matchedUrls.isEmpty()) {
return;
}
List<Configurator> configurators = RegistryDirectory.toConfigurators(matchedUrls);
final Invoker<?> invoker;
if (originInvoker instanceof InvokerDelegete) {
invoker = ((InvokerDelegete<?>) originInvoker).getInvoker();
} else {
invoker = originInvoker;
}
//最原始的invoker
URL originUrl = RegistryProtocol.this.getProviderUrl(invoker);
String key = getCacheKey(originInvoker);
ExporterChangeableWrapper<?> exporter = bounds.get(key);
if (exporter == null) {
logger.warn(new IllegalStateException("error state, exporter should not be null"));
return;
}
//當前的,可能經過了多次merge
URL currentUrl = exporter.getInvoker().getUrl();
//與本次配置merge的
URL newUrl = getConfigedInvokerUrl(configurators, originUrl);
if (!currentUrl.equals(newUrl)) {
RegistryProtocol.this.doChangeLocalExport(originInvoker, newUrl);
logger.info("exported provider url changed, origin url: " + originUrl + ", old export url: " + currentUrl + ", new export url: " + newUrl);
}
}
private List<URL> getMatchedUrls(List<URL> configuratorUrls, URL currentSubscribe) {
List<URL> result = new ArrayList<URL>();
for (URL url : configuratorUrls) {
URL overrideUrl = url;
// 兼容舊版本
if (url.getParameter(Constants.CATEGORY_KEY) == null
&& Constants.OVERRIDE_PROTOCOL.equals(url.getProtocol())) {
overrideUrl = url.addParameter(Constants.CATEGORY_KEY, Constants.CONFIGURATORS_CATEGORY);
}
//檢查是不是要應用到當前服務上
if (UrlUtils.isMatch(currentSubscribe, overrideUrl)) {
result.add(url);
}
}
return result;
}
//合并配置的url
private URL getConfigedInvokerUrl(List<Configurator> configurators, URL url) {
for (Configurator configurator : configurators) {
url = configurator.configure(url);
}
return url;
}
}
最主要的notify方法,邏輯合情合理了,判斷了從zookeeper變動中獲取到當前的變動生成新的url,判斷和以前的exporter的url是否一致,不一致,則調用RegistryProtocol.this.doChangeLocalExport(originInvoker, newUrl);方法改變服務:
private <T> void doChangeLocalExport(final Invoker<T> originInvoker, URL newInvokerUrl) {
String key = getCacheKey(originInvoker);
final ExporterChangeableWrapper<T> exporter = (ExporterChangeableWrapper<T>) bounds.get(key);
if (exporter == null) {
logger.warn(new IllegalStateException("error state, exporter should not be null"));
} else {
final Invoker<T> invokerDelegete = new InvokerDelegete<T>(originInvoker, newInvokerUrl);
exporter.setExporter(protocol.export(invokerDelegete));
}
}
看,這也就對上了ExporterChangeableWrapper這層包裝的作用,用來當服務配置發(fā)生改變時,更新服務端exporter。
到這里,dubbo的服務發(fā)布過程我們終于分析完了。。。。。。。。
回顧下,我們印象最深的設計
- 擴展spi的靈活使用,似的dubbo的可擴展行更強
- 大量的模版模式的使用,抽象思想
- 領域模型設計,所有發(fā)布對象都在Protocol中進行管理
- 層層包裝,每一層都又自己的指責,互不影響,使用可靈活的進行添加新的擴展層。
等等等等,你還有什么喜歡的地方,可以留言一起討論學習下,稍后一起看dubbo源碼分析服務引用端
下一篇 ??? dubbo源碼分析服務引用
首頁 ??? dubbo源碼欣賞簡介