Dubbo源码分析(十)--------消费者Invoker的调用过程分析

1,941 阅读2分钟

Dubbo版本2.7.3.Release.

之前分析过Directory、Router、LoadBalance接下来最后就是调用Invoker的过程分析,之前有在分析Reference过程注入@Reference属性的代理对象引用的Invoker对象是RegistryDirectory中通过注册中心的提供者的URL转化成Invoker(实际里面是InvokerDelegate,InvokerDelegate里面包含的真实对象是DubboInvoker),下图就是RegistryDirectory转化Invoker的地方
RegistryDirectory里面默认是通过DubboProtocol的refer服务引用,其父类中AbstractProtocol的refer方法返回AsyncToSyncInvoker对象,protocolBindingRefer则是臭抽象方法,则有具体的协议默认DubboProtocol实现.
我们先看下DubooProtocol中的protocolBindingRefer方法实现,首先是通过getClient获取ReferenceCountExchangeClient的集合.并构造DubboInvoker返回.
DubboPrtocol中getClient中判断是否配置connections的参数,则每一次调用则是使用共享的ExchangeClient,否是是一个根据配置的connections个数实现对多个connection共享使用, 获取共享的ReferenceCountExchangeClient的集合.
ReferenceCountExchangeClient传入ExchangeClient是通过DubboProtocol中的initClient方法来构造ExchangeClient的对象,通过调用Exchangers.connect传入url和requestHander,最终通过默认的Exchanger扩展点是HeaderExchanger的connect方法返回HeaderExchangeClient
HeaderExchanger是调用connect返回的HeaderExchangeClient,传入的Client是通过Transport扩展点实现的NettyTransporter,传入url以及包装DecodeHander(解码器处理器)的ExchangeHandler和HeaderExchangeHandler(头部处理器)的Exchangehandler,
NettyTransporter的bind方法直接返回的是NettyClient, 并传入上图构造的DecodeHandler, 实际执行顺序: DecodeHander--->HeaderExchangeHandler----->ExchangeHandler, Dubbo很 多地方都是用了装饰器去做服务增强.
下面就是传入HeaderExchangerHandler的ExchangeHandler其实这里实现的是一个匿名内部类,重写了reply方法,主要是在接受请求参数后调用Invoker的invoker方法,并设置RpcContext的远程调用host
首先看下AbstractInvoker的invoke逻辑,这里使用的模板模式,先传入的参数是Invocation对象,这里主要是加入隐式参数到attachemnet中,然后设置设置是否是异步调用,并调用doInvoke的抽象方法,这个是DubboInvoker实现,.
这里是DubboInvoker的doInvoke的远程调用的过程,这里可以看到消费端是通过ExchangeClient端发起请求的,默认是共享的ExchangeClient(默认实际对象是HeaderExchangeClient),这里会判断是否是双向的,单向就直接返回,双向的则调用ExchangeClient的request方法发起远程请求调用,调用异步返回.通过AsyncRpcResult订阅返回结果.
HeaderExchangeClient的request通过ExchangeChannel(默认实例是HeaderExchangeChannel)的request方法请求.
可以看到HeaderExchangeChannel里面request方法中会对Request参数进行封装,然后调用channel的send方法进行请求的发送.
最终通过NettyChannel调用send发送0消息(RpcInvocation)给服务端调用远程方法.
总结
今天主要分析了消费者的Invoker的调用的过程.