-
Dubbo(五):深入理解Dubbo核心模型Invoke
一、Dubbo中Invoker介绍
为什么说Invoker是Dubbo核心模型呢?
Invoker是Dubbo中的实体域,也就是真实存在的。其他模型都向它靠拢或转换成它,它也就代表一个可执行体,可向它发起invoke调用。在服务提供方,Invoker用于调用服务提供类。在服务消费方,Invoker用于执行远程调用。
二、服务提供方的Invoker
在服务提供方中的Invoker是由ProxyFactory创建而来的,Dubbo默认的ProxyFactory实现类为JavassistProxyFactory。
创建Invoker的入口方法getInvoker:
1 public <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) { 2 // 为目标类创建 Wrapper 3 final Wrapper wrapper = Wrapper.getWrapper(proxy.getClass().getName().indexOf(36) < 0 ? proxy.getClass() : type); 4 // 创建匿名 Invoker 类对象,并实现 doInvoke 方法。 5 return new AbstractProxyInvoker<T>(proxy, type, url) { 6 @Override 7 protected Object doInvoke(T proxy, String methodName, 8 Class<?>[] parameterTypes, 9 Object[] arguments) throws Throwable { 10 // 调用 Wrapper 的 invokeMethod 方法,invokeMethod 最终会调用目标方法 11 return wrapper.invokeMethod(proxy, methodName, parameterTypes, arguments); 12 } 13 }; 14 }
JavassistProxyFactory创建了一个继承自AbstractProxyInvoker类的匿名对象,并覆写了抽象方法doInvoke。覆写后的doInvoke 逻辑比较简单,仅是将调用请求转发给了Wrapper类的invokeMethod 方法。以及生成 invokeMethod 方法代码和其他一些方法代码。代码生成完毕后,通过 Javassist 生成 Class 对象,最后再通过反射创建 Wrapper 实例。
注:Wapper是一个包装类。主要用于“包裹”目标类,仅可以通过getWapper(Class)方法创建子类。在创建子类过程中,子类代码会对传进来的Class对象进行解析,拿到类方法,类成员变量等信息。而这个包装类持有实际的扩展点实现类。也可以把扩展点的公共逻辑全部移到包装类中,功能上就是作为AOP实现。
创建包装类的构造方法:
1 public static Wrapper getWrapper(Class<?> c) { 2 while (ClassGenerator.isDynamicClass(c)) 3 c = c.getSuperclass(); 4 5 if (c == Object.class) 6 return OBJECT_WRAPPER; 7 8 // 从缓存中获取 Wrapper 实例 9 Wrapper ret = WRAPPER_MAP.get(c); 10 if (ret == null) { 11 // 缓存未命中,创建 Wrapper 12 ret = makeWrapper(c); 13 // 写入缓存 14 WRAPPER_MAP.put(c, ret); 15 } 16 return ret; 17 }
在缓存中获取不到Wapper就会进入下面的方法makeWapper:
代码较长,同样注释也很多。大致说一下里面逻辑:
-
- 创建c1,c2,c3三个字符串,用于存储类型转换代码和异常捕捉代码,而后pts用于存储成员变量名和类型,ms用于存储方法描述信息(可理解为方法签名)及Method实例,mns为方法名列表,dmns用于存储“定义在当前类中的方法”的名称。在这里做完了一些初始工作
- 获取所有public字段,用c1存储条件判断及赋值语句,可以理解为通过c1能够为public字段赋值,而c2是条件判断及返回语句,同样的是得到public字段的值。再用pts存储<字段名,字段类型>。也就是现在能对目标类字段进行操作了,而要操作一些私有字段,是要访问set开头和get开头的方法,同样这些方法也都对应使用c1存set,c2存get,pts存储<属性名,属性类型>
- 现在到类中的方法,先检查方法中的参数,然后再检查是否有重载的方法。通过c3存储调用目标方法的语句以及方法中可能会抛出的异常,而后用mns集合进行存储方法名,对已经声明的方法存到ms中,未声明但是定义了的方法存在dmns中。
- 通过ClassGenerator为刚刚生成的代码构建Class类,并通过反射创建对象。ClassGenerator是Dubbo自己封装的,该类的核心是toClass()的重载方法 toClass(ClassLoader, ProtectionDomain),该方法通过javassist构建Class。
最后在创建完成Wapper类,回到上面的getInvoker方法然后通过下面这条语句
1 return wrapper.invokeMethod(proxy, methodName, parameterTypes, arguments); 2 3 //进入到invokeMethod中 4 5 public Object invokeMethod(Object instance, String mn, Class<?>[] types, Object[] args) throws NoSuchMethodException { 6 if ("getClass".equals(mn)) { 7 return instance.getClass(); 8 } else if ("hashCode".equals(mn)) { 9 return instance.hashCode(); 10 } else if ("toString".equals(mn)) { 11 return instance.toString(); 12 } else if ("equals".equals(mn)) { 13 if (args.length == 1) { 14 return instance.equals(args[0]); 15 } else { 16 throw new IllegalArgumentException("Invoke method [" + mn + "] argument number error."); 17 } 18 } else { 19 throw new NoSuchMethodException("Method [" + mn + "] not found."); 20 } 21 } 22 };
到这里Invoker就能实现调用服务提供类的方法了。也就是服务提供类的Invoker实体域创建完成。底层是通过javassist来构建对象的。
三、服务消费方的Invoker
在服务消费方,Invoker用于执行远程调用。Invoker是由 Protocol实现类构建而来。Protocol实现类有很多但是最常用的两个,分别是RegistryProtocol和DubboProtocol。
DubboProtocol的refer方法:
1 public <T> Invoker<T> refer(Class<T> serviceType, URL url) throws RpcException { 2 optimizeSerialization(url); 3 // 创建 DubboInvoker 4 DubboInvoker<T> invoker = new DubboInvoker<T>(serviceType, url, getClients(url), invokers); 5 invokers.add(invoker); 6 return invoker; 7 }
上述方法较为简单,最重要的一个在于getClients。这个方法用于获取客户端实例,实例类型为ExchangeClient。ExchangeClient实际上并不具备通信能力,它需要基于更底层的客户端实例进行通信。比如NettyClient、MinaClient等,默认情况下,Dubbo使用NettyClient进行通信。每次创建好的Invoker都会添加到invokers这个集合里。也就是可以认为服务消费方的Invoker是一个具有通信能力的Netty客户端
getClients方法:
上面的源码大概分一下几个逻辑:
-
- 通过refer方法进入DubboInvoker实例的创建,在这个实例中其实serviceType,url,以及invokers都已经是不用去关心的,invokers可以说是存储以及创建好的Invoker。而最关键的在于getClient方法。可以这么认为,现在的Invoker是一个Netty客户端。而在服务提供方的Invoker是一个Wapper类。
- 在getClient方法里面首先根据connections数量决定是获取共享客户端还是创建新的客户端实例,默认情况下是获取共享客户端,但是获取共享客户端中若缓存中拿不到对应客户端也会新建一个客户端。最终返回的是ExchangeClient,而当前的ExchangeClient也没有通信能力,需要更加底层的Netty客户端。
- initClient方法首先获取用户配置的客户端类型,默认为Netty,然后检测用户配置的客户端类型是否存在,不存在就要抛出异常,最后根据lazy配置觉得创建什么类型的客户端。LazyConnectExchangeClient代码并不是很复杂,该类会在request方法被调用时通过Exchangers的connect方法创建 ExchangeClient客户端
- getExchanger会通过SPI加载HeaderExchangeClient实例。最后通过Transporter实现类以及调用Netty的API来创建Netty客户端。最后层层返回,就最后成为了底层为Netty上层为DubboInvoker实例的这样一个类。
RegistryProtocol中的refer:
大致说一下上面的逻辑:
-
- 当前的Invoker底层依然是NettyClient,但是此时注册中心是集群搭建模式。所以需要将多个Invoker合并为一个,这里是逻辑合并的。实际上Invoker底层还是会有多个,只是通过一个集群模式来管理。所以暴露出来的就是一个集群模式的Invoker。于是进入Cluster.join方法。
- Cluster是一个通用代理类,会根据URL中的cluster参数值定位到实际的Cluster实现类也就是FailoverCluster。这里用到了@SPI注解,也就是需要ExtensionLoader扩展点加载机制,而该机制在实例化对象是,会在实例化后自动套上Wapper
- 但是是集群模式所以需要Dubbo中另外一个核心机制——Mock。Mock可以在测试中模拟服务调用的各种异常情况,还可以实现服务降级。在MockerClusterInvoker中,Dubbo先检查URL中是否存在mock参数。(这个参数可以通过服务治理后台Consumer端的屏蔽和容错进行设置或者直接动态设置mock参数值)如果存在force开头,这不发起远程调用直接执行降级逻辑。如果存在fail开头,则在远程调用异常时才会执行降级逻辑。
- 可以说注册中心为集群模式时,Invoker就会外面多包裹一层mock逻辑。是通过Wapper机制实现的。最终可以在调用或者重试时,每次都通过Dubbo内部的负载均衡机制选出多个Invoker中的一个进行调用
四、总结
到这里Invoker的实现就可以是说完了,总结一下,在服务提供方Invoker是javassist创建的服务类的实例,可以实现调用服务类内部的方法和修改字段。而在服务消费方的Invoker是基于Netty的客户端。最终通过服务消费方Netty客户端获得服务提供方创建的服务类实例。而后消费方为保护服务类就需要为其创建代理类,这样就可以在不实例化服务类情况下安全有效的远程调用服务类内部方法并且得到具体数据了。