服务引入使用reference标签来对要引入的服务进行配置，包括服务的接口 ，名称，init,check等等配置属性。
在dubbonamespacehandler中，我们可以看到reference标签是通过引入一个referencebean类型的bean实现的，那么我们就以这个bean为入口，一探dubbo服务引入的究竟。
首先看一下referencebean的继承结构:
这个方法主要是做一些配置，比如初始化配置中心bean，消费者配置类consumerconfig，全局配置类applicationconfig，等等，还有一些其他的配置，大致与服务导出的过程差不多。
很显然服务引入的入口就在这个方法中。
兜兜转转，期间经过几个方法调用，忽略中间涉及到的配置部分，我们来到核心方法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
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);
}
大致分为三种情况：
加载完url之后，调用protocol.refer方法创建一个服务引用，即一个invoker，
我们分析最普通的情况，即通注册中心引用服务的情况，这种情况是调用registryprotocol.refer方法创建invoker
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。
接下来是对分组信息的处理，这里由于不是很常用，我们暂时跳过。
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，我们知道从注册中心是可以获取多个服务提供者的。
这两个接口会单独在写文章来分析，本文我们主要是为了理清服务引用的主干逻辑。
我们回到referenceconfig中，通过以上的一些步骤获取到invoker之后，创建服务引用的过程并没有结束。
试想，服务引入后，用户是需要在代码中直接调用服务接口中的方法的，而invoker只有一个invoke方法，显然，我们还需要一个代理，来使的方法调用对用户是透明的，即用户不需要感知到还有invoker这个东西的存在。所以接下来就分析一下创建代理的过程。
proxyfactory这个类在服务导出的部分已经接触过。服务导出时，调用proxyfactory.getinvoker方法获取一个invoker类，用于将发送过来的调用信息路由到接口的不同方法上。
而在服务引入的过程中，我们需要创建一个代理，将接口中的不同的方法调用转换成invoker的invoke调用，并进一步转化为网络报文发送给服务提供者，并将返回的结果信息返回给服务调用者。
默认的proxyfactory是javassistproxyfactory，继承自abstractproxyfactory，我们先从abstractproxyfactory看起
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方法
这个方法就不贴代码了，太长，大概的逻辑是生成两个类的代码，然后调用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调用，并传递参数。
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方法中。这个方法的逻辑大致分为三个部分：
使用上面生成的invoker对象生成一个服务接口的代理类，生成的这个代理类负责将对接口方法的调用转化为调用内部的invoker对象的invoke方法的调用。
而生成代理类的逻辑封装在proxyfactory接口中，默认使用javassist生成动态代理，但是代理类代码生成的逻辑仍然是dubbo自己实现，只是用javassist库进行代码编译加载。
dubbo在生成动态代理是做了一些比较重要的优化：
所以问题是：dubbo实现的动态代理和jdk实现的动态代理有什么区别？dubbo为啥要自己实现？？
如对本文有疑问， 点击进行留言回复！！
网友评论