dubbo源码阅读之服务引入
服务引入
服务引入使用reference标签来对要引入的服务进行配置,包括服务的接口 ,名称,init,check等等配置属性。
在dubbonamespacehandler中,我们可以看到reference标签是通过引入一个referencebean类型的bean实现的,那么我们就以这个bean为入口,一探dubbo服务引入的究竟。
referencebean概述
首先看一下referencebean的继承结构:
- 继承了referenceconfig,用于存放通过配置文件或api设置的一些配置,
- 实现了若干接口,全部都与spring框架相关,关系到bean的生命周期以及对一些spring基础设施类的感知,
- 实现factorybean。说明是一个工厂bean, 我们将接口作为依赖引入到其他bean中,或者直接调用applicationcontext.getbean方法时,会通过这个工厂bean获取一个实际类型的bean
容易想到,这个被引入的服务的引用非获取应该与factorybean相关。 - applicationcontextaware。aware接口,目的是为了持有spring容器的引用,以便能够获取其他的依赖的bean
- initializingbean。 在spring的bean被实例化后,会一次调用beanpostprocessor.postprocessbeforeinitialization, initializingbean.afterpropertiesset, 自定义的初始化方法(通过init属性配置),beanpostprocessor.postprocessafterinitialization,所以实现了initializingbean接口的bean在实例化时,spring框架会自动调用afterpropertiesset方法
- disposablebean。 bean是一个有声明周期的实体,在spring容器关闭时会自动销毁这个bean
afterpropertiesset
这个方法主要是做一些配置,比如初始化配置中心bean,消费者配置类consumerconfig,全局配置类applicationconfig,等等,还有一些其他的配置,大致与服务导出的过程差不多。
factorybean.getobject
很显然服务引入的入口就在这个方法中。
兜兜转转,期间经过几个方法调用,忽略中间涉及到的配置部分,我们来到核心方法init
referenceconfig.init
public synchronized void destroy() { if (ref == null) { return; } if (destroyed) { return; } destroyed = true; try { invoker.destroy(); } catch (throwable t) { logger.warn("unexpected error occured when destroy invoker of referenceconfig(" + url + ").", t); } invoker = null; ref = null; } private void init() { // 用一个volatile变量标记是否已经初始化过 if (initialized) { return; } // 这里还是有可能多个线程同时初始化,不如学spring, 直接加锁 initialized = true; // 检查stub和local合法性 checkstubandlocal(interfaceclass); // 检查mock合法性 checkmock(interfaceclass); // 存放参数 map<string, string> map = new hashmap<string, string>(); // size属性设为consumer,即消费端 map.put(constants.side_key, constants.consumer_side); // 添加运行时的几个参数,之前在分析服务导出 的时候已经讲过 // 1. dubbo协议的版本号 // 2. dubbo框架的发行版本号,可以通过package-info或者jar包名称获取 // 3. 时间戳 // 4. 当前jvm进程号 appendruntimeparameters(map); // 对于非泛化服务,添加如下配置 if (!isgeneric()) { // 修订版本号 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)), ",")); } } // 添加接口名参数 map.put(constants.interface_key, interfacename); // 接下来的几个方法与服务导出中的处理过程类似,都是按照优先级覆盖配置 appendparameters(map, application); appendparameters(map, module); appendparameters(map, consumer, constants.default_key); // 最后添加自身的参数配置,即reference标签配置的参数, // 显然这些配置应该是优先级最高的,所以最后添加以覆盖之前的配置 appendparameters(map, this); map<string, object> attributes = null; if (collectionutils.isnotempty(methods)) { attributes = new hashmap<string, object>(); for (methodconfig methodconfig : methods) { appendparameters(map, methodconfig, methodconfig.getname()); string retrykey = methodconfig.getname() + ".retry"; if (map.containskey(retrykey)) { string retryvalue = map.remove(retrykey); // 如果该方法被设置为不重试,那么添加一个参数:方法名.retries=0 if ("false".equals(retryvalue)) { map.put(methodconfig.getname() + ".retries", "0"); } } attributes.put(methodconfig.getname(), convertmethodconfig2ayncinfo(methodconfig)); } } // 通过环境变量或jvm系统变量获取属性dubbo_ip_to_registry,即要发送给注册中心的主机ip地址 string hosttoregistry = configutils.getsystemproperty(constants.dubbo_ip_to_registry); if (stringutils.isempty(hosttoregistry)) { // 如果从环境变量或jvm系统变量没获取到,那么直接获取本地ip // 如果获取不到本地ip,最后只有用环回地址 hosttoregistry = netutils.getlocalhost(); } // 添加参数 map.put(constants.register_ip_key, hosttoregistry); // 关键一步,创建代理 ref = createproxy(map); string servicekey = url.buildkey(interfacename, group, version); applicationmodel.initconsumermodel(servicekey, buildconsumermodel(servicekey, attributes)); }
这个方法大致分为两块,前半部分都是在构建参数的map,最后用这些参数创建一个代理,
添加的参数包括运行时参数,版本号,方法名,按优先级分别添加全局配置,分组配置,消费端配置,以及reference标签的配置,用于注册的ip
referenceconfig.createproxy
private t createproxy(map<string, string> map) { // 首先判断是不是本地引用, if (shouldjvmrefer(map)) { url url = new url(constants.local_protocol, constants.localhost_value, 0, interfaceclass.getname()).addparameters(map); // 创建一个本地服务引用,通过指定的injvm协议创建 invoker = refprotocol.refer(interfaceclass, url); if (logger.isinfoenabled()) { logger.info("using injvm service " + interfaceclass.getname()); } } else { // 用户指定的url,可以是点对点调用,也可以指定注册中心的url if (url != null && url.length() > 0) { // user specified url, could be peer-to-peer address, or register center's address. // 可以是多个url,以分号(;)号分隔 string[] us = constants.semicolon_split_pattern.split(url); if (us != null && us.length > 0) { for (string u : us) { url url = url.valueof(u); if (stringutils.isempty(url.getpath())) { url = url.setpath(interfacename); } if (constants.registry_protocol.equals(url.getprotocol())) { // refer是注册中心url的参数key名称 urls.add(url.addparameterandencoded(constants.refer_key, stringutils.toquerystring(map))); } else { // urls.add(clusterutils.mergeurl(url, map)); } } } } else { // assemble url from register center's configuration checkregistry(); // 用户指定的url,优先用指定的url // 可以是点对点调用,也可以指定注册中心的url list<url> us = loadregistries(false); if (collectionutils.isnotempty(us)) { 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))); } } 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 invoker = refprotocol.refer(interfaceclass, urls.get(0)); } else { list<invoker<?>> invokers = new arraylist<invoker<?>>(); url registryurl = null; for (url url : urls) { 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 registryawarecluster only when register's cluster is available url u = registryurl.addparameter(constants.cluster_key, registryawarecluster.name); // the invoker wrap relation would be: registryawareclusterinvoker(staticdirectory) -> failoverclusterinvoker(registrydirectory, will execute route) -> invoker invoker = cluster.join(new staticdirectory(u, invokers)); } else { // not a registry url, must be direct invoke. invoker = cluster.join(new staticdirectory(invokers)); } } } if (shouldcheck() && !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()); } /** * @since 2.7.0 * servicedata store */ metadatareportservice metadatareportservice = null; if ((metadatareportservice = getmetadatareportservice()) != null) { url consumerurl = new url(constants.consumer_protocol, map.remove(constants.register_ip_key), 0, map.get(constants.interface_key), map); metadatareportservice.publishconsumer(consumerurl); } // create service proxy // 重要的一步,创建代理 return (t) proxyfactory.getproxy(invoker); }
大致分为三种情况:
- 如果参数中指明了是本地引用,那么使用injvmprotocol创建一个本地的invoker
- 如果用户在指定了url,那么优先用用户显式指定的url
- 如果没有显式配置的url,那么就加载所有的注册中心的url
加载完url之后,调用protocol.refer方法创建一个服务引用,即一个invoker,
我们分析最普通的情况,即通注册中心引用服务的情况,这种情况是调用registryprotocol.refer方法创建invoker
registryprotocol.refer
public <t> invoker<t> refer(class<t> type, url url) throws rpcexception { url = urlbuilder.from(url) // registry属性默认是dubbo .setprotocol(url.getparameter(registry_key, default_registry)) // 前面protocol属性被设为registry, // 而原本的protocol属性被保存在registry属性中 // 到这里将protocol设为registry已经完成了他的使命,即将protocol类型路由到registryprotocol中 // 所以这是自然要将protocol属性设回原本的值,而将registry属性丢弃 .removeparameter(registry_key) .build(); // 这里根据协议决定具体使用哪种registry // registryfactory成员属性是通过extensionloader的ioc机制自动注入的,也就是通过extensionfactory获取到的 // 对于带有spi注解的接口,通过ioc方式注入的是自适应的扩展类 // 以常用的zookeeper注册中心为例,这里通过zookeeperregistryfactory获取到了一个zookeeperregistry registry registry = registryfactory.getregistry(url); if (registryservice.class.equals(type)) { return proxyfactory.getinvoker((t) registry, type, url); } // group="a,b" or group="*" map<string, string> qs = stringutils.parsequerystring(url.getparameteranddecoded(refer_key)); string group = qs.get(constants.group_key); if (group != null && group.length() > 0) { if ((comma_split_pattern.split(group)).length > 1 || "*".equals(group)) { return dorefer(getmergeablecluster(), registry, type, url); } } // 创建invoker // 这里的cluster成员属性同样也是通过extensionloader的ioc自动注入的, // 同样注入的是一个自适应的cluster return dorefer(cluster, registry, type, url); }
对url进行一些处理,然后获取一个注册服务registry对象,一般常用的有zookeeperregistry。
接下来是对分组信息的处理,这里由于不是很常用,我们暂时跳过。
registryprotocol.dorefer
private <t> invoker<t> dorefer(cluster cluster, registry registry, class<t> type, url url) { // 创建一个服务目录 registrydirectory<t> directory = new registrydirectory<t>(type, url); directory.setregistry(registry); directory.setprotocol(protocol); // all attributes of refer_key map<string, string> parameters = new hashmap<string, string>(directory.geturl().getparameters()); // 订阅url url subscribeurl = new url(consumer_protocol, parameters.remove(register_ip_key), 0, type.getname(), parameters); if (!any_value.equals(url.getserviceinterface()) && url.getparameter(register_key, true)) { directory.setregisteredconsumerurl(getregisteredconsumerurl(subscribeurl, url)); // 注册一个消费者 registry.register(directory.getregisteredconsumerurl()); } // 创建路由链 directory.buildrouterchain(subscribeurl); // 向注册中心订阅,订阅providers,configurators,routers三个目录的服务 // 接收注册中心的变化信息 directory.subscribe(subscribeurl.addparameter(category_key, providers_category + "," + configurators_category + "," + routers_category)); // 将目录封装成一个invoker invoker invoker = cluster.join(directory); providerconsumerregtable.registerconsumer(invoker, url, subscribeurl, directory); return invoker; }
这里首先创建了一个服务目录,然后向注册中心注册一个消费者,创建路由链,向注册中心订阅以接收服务变化的通知,
最关键的一步是cluster.join,这一步将服务目录封装成一个invoker,我们知道从注册中心是可以获取多个服务提供者的。
- directory,服务目录,封装了从注册中心发现服务,并感知服务变化的逻辑
- cluster,这个类实际上只起到过渡的作用,通过它的join方法返回failoverclusterinvoker等对象,这些类封装了服务调用过程中的故障转移,重试,负载均衡等逻辑
这两个接口会单独在写文章来分析,本文我们主要是为了理清服务引用的主干逻辑。
proxyfactory.getproxy
我们回到referenceconfig中,通过以上的一些步骤获取到invoker之后,创建服务引用的过程并没有结束。
试想,服务引入后,用户是需要在代码中直接调用服务接口中的方法的,而invoker只有一个invoke方法,显然,我们还需要一个代理,来使的方法调用对用户是透明的,即用户不需要感知到还有invoker这个东西的存在。所以接下来就分析一下创建代理的过程。
proxyfactory这个类在服务导出的部分已经接触过。服务导出时,调用proxyfactory.getinvoker方法获取一个invoker类,用于将发送过来的调用信息路由到接口的不同方法上。
而在服务引入的过程中,我们需要创建一个代理,将接口中的不同的方法调用转换成invoker的invoke调用,并进一步转化为网络报文发送给服务提供者,并将返回的结果信息返回给服务调用者。
默认的proxyfactory是javassistproxyfactory,继承自abstractproxyfactory,我们先从abstractproxyfactory看起
abstractproxyfactory.getproxy
public <t> t getproxy(invoker<t> invoker, class<?>[] interfaces) { return (t) proxy.getproxy(interfaces).newinstance(new invokerinvocationhandler(invoker)); }
这个方法通过proxy.getproxy生成一个proxy类示例,然后调用proxy实例的newinstance方法返回代理对象,我们重点分析一下proxy.getproxy方法
proxy.getproxy
这个方法就不贴代码了,太长,大概的逻辑是生成两个类的代码,然后调用javassist库编译加载获取class对象,生成的这两个类一个实现了用户的服务接口的代理类,另一个继承了proxy,用于生成代理类的实例,对于这部分代码,我认为逐字逐句第分析代码生成部分的逻辑意义不大,不如直接看一下生成后的代码长什么样子,这样能够更加直观地理解代码生成的逻辑。
示例接口:
public interface i2 { void setname(string name); void hello(string name); int showint(int v); float getfloat(); void setfloat(float f); }
生成的代理类代码:
public class proxy0 implements org.apache.dubbo.common.bytecode.i2 { public static java.lang.reflect.method[] methods; private java.lang.reflect.invocationhandler handler; public proxy0(java.lang.reflect.invocationhandler arg0) { handler = $1; } public float getfloat() { object[] args = new object[0]; object ret = handler.invoke(this, methods[0], args); return ret == null ? (float) 0 : ((float) ret).floatvalue(); } public void setname(java.lang.string arg0) { object[] args = new object[1]; args[0] = ($w) $1; object ret = handler.invoke(this, methods[1], args); } public void setfloat(float arg0) { object[] args = new object[1]; args[0] = ($w) $1; object ret = handler.invoke(this, methods[2], args); } public void hello(java.lang.string arg0) { object[] args = new object[1]; args[0] = ($w) $1; object ret = handler.invoke(this, methods[3], args); } public int showint(int arg0) { object[] args = new object[1]; args[0] = ($w) $1; object ret = handler.invoke(this, methods[4], args); return ret == null ? (int) 0 : ((integer) ret).intvalue(); } }
生成的proxy类代码:
public class proxy0 extends org.apache.dubbo.common.bytecode.proxy { public object newinstance(java.lang.reflect.invocationhandler h) { return new org.apache.dubbo.common.bytecode.proxy0($1); } }
当然了,上面的代码只是初步的代码,后面肯定要经过一定的处理才能编译,不过这都是javassist库的事情,通过上面生成的代码我们很容易就知道dubbo生成动态代理的逻辑。
从生成的代理类代码可以看出来,代理类缓存了接口的所有方法的method对象,放到一个数组中,数组下标和方法是严格对应的,这样做的好处是不需要每次调用方法的时候都通过反射去获取method对象,那样效率太低。代理类调用每个方法的逻辑其实都是一样的,都是调用了invocationhandler.invoke方法,生成的这个代理类感觉就像是一个门面,唯一的作用就是把所有的方法调用导向invoke调用,并传递参数。
invokerinvocationhandler.invoke
public object invoke(object proxy, method method, object[] args) throws throwable { string methodname = method.getname(); class<?>[] parametertypes = method.getparametertypes(); if (method.getdeclaringclass() == object.class) { return method.invoke(invoker, args); } if ("tostring".equals(methodname) && parametertypes.length == 0) { return invoker.tostring(); } if ("hashcode".equals(methodname) && parametertypes.length == 0) { return invoker.hashcode(); } if ("equals".equals(methodname) && parametertypes.length == 1) { return invoker.equals(args[0]); } return invoker.invoke(createinvocation(method, args)).recreate(); }
这个方法的逻辑也很简单,直接调用的invoker.invoke方法,而invoker对象是通过构造方法传进来的。所以核心的处理逻辑还是在invoker对象中,其他的基本都是传参,方法调用的作用。
至于createinvocation方法的逻辑就更简单了,就是把方法名,参数类型列表,调用参数等取出来,然后封装成一个rpcinvocation对象,然后用这个rpcinvocation对象作为参数调用invoker.invoke方法。
那么invoker对象又是怎么来的呢?是通过服务目录也就是directory对象内部生成的,服务目录会监听注册中心,并获取服务提供者的信息,然后生成代表这些服务提供者的invoker对象,并通过cluster对象将多个invoker对象封装在一起,内部实现故障转移,服务路由,负载均衡等逻辑。服务目录,集群,以及负载均衡的内容都比较多,而且模块独立性较强,所以可以分开来看这些模块的代码。
总结
这一节的主要内容是服务引用。服务引用的入口是spring配置文件中的reference标签,这个标签由referencebean处理,referencebean是一个factorybean,通过它的getobject方法获取引用,经过一些调用链,最终生成服务接口引用的核心逻辑在referenceconfig.init方法中。这个方法的逻辑大致分为三个部分:
- 参数处理。init方法的大部分代码都是在进行参数的处理,包括一些缓存的逻辑,状态判断,合法性检查等等。
- 列出所有的url,包括显示指定的url, 注册中心url,通过protocol接口的refer方法创建invoker对象,创建出来的invoker对象已经是经过cluster对象封装了故障转移,服务路由,负载均衡逻辑的了。
invoker对象最主要的功能实际上是封装了通信细节,包括调用参数和返回结果的序列化反序列化,创建tcp连接,发送报文等逻辑。 -
使用上面生成的invoker对象生成一个服务接口的代理类,生成的这个代理类负责将对接口方法的调用转化为调用内部的invoker对象的invoke方法的调用。
而生成代理类的逻辑封装在proxyfactory接口中,默认使用javassist生成动态代理,但是代理类代码生成的逻辑仍然是dubbo自己实现,只是用javassist库进行代码编译加载。dubbo在生成动态代理是做了一些比较重要的优化:
- 将被代理的接口的所有方法的method对象缓存起来,存放到一个数组中,并将方法与数组下标对应起来,这样在方法调用时可以很快获取到method对象,而不用通过反射再获取一遍method对象,方法调用的效率大大提升。(ps: 这里我最初的理解错了,实际上jdk动态代理也是差不多的套路,将各个方法的method对象在类加载是就缓存起来,每次方法调用时不需要再次通过反射获取methodd对象。)
所以问题是:dubbo实现的动态代理和jdk实现的动态代理有什么区别?dubbo为啥要自己实现??