Dubbo源码深度解析(五)

上一篇博客主要讲服务提供方服务的发布，以及Netty是如何启动的，客户端发过来的请求，会经过哪些处理器，以及补充之前没讲完的SPI机制等等。这篇博客将会接着继续讲，在看这篇博客之前，请先看上一篇博客：《Dubbo源码深度解析(四)》。

上一篇讲到了DubboProtocol的exporterMap属性的设置，代码如下：

存入的值究竟是什么对象？我觉得有必要彻底搞清楚。还是回到ServiceConfig#doExportUrlsFor1Protocol()方法，直接看关键的地方，代码如下：

因此到这里为止，可以知道，调用Protocol$Adaptive#export()方法，传入的Invoker对象为RegistryProtocol.InvokerDelegate对象，而RegistryProtocol.InvokerDelegate对象invoker是DelegateProviderMetaDataInvoker对象，而DelegateProviderMetaDataInvoker对象的invoker属性为抽象类AbstractProxyInvoker的匿名实现类。最终调用的是AbstractProxyInvoker匿名实现类的 doInvoke()方法，而该方法调用的是 Wrapper实现类的invokeMethod()方法，打断点验证：

到这里还没完，再看看Protocol$Adaptive#export()方法，代码如下：

因此，看ProtocolFilterWrapper#export()方法，代码如下：

重点看看ProtocolFilterWrapper#buildInvokerChain()方法，代码如下：

这里也涉及到SPI，不详细讲了，直接看org.apache.dubbo.rpc.Filter文件，内容如下：

就是获取这些实现类，只不过指定了group为"provider"，举例，如下面这两种：

最终的结果为多个FilterNode对象嵌套，其中FilterNode对象的filter属性是Filter对象，next属性还是FilterNode对象，只不过它的filter属性变了。打断点，结果如下：

再调用ProtocolListenerWrapper#export()方法，代码如下：

再看看RegistryProtocol#doLocalExport方法，代码如下：

回到ServiceConfig#doExportUrlsFor1Protocol()方法核心的地方法，代码如下：

可知返回的exporter为RegistryProtocol.DestroyableExporter对象，而RegistryProtocol.DestroyableExporter对象的exporter属性为RegistryProtocol.ExporterChangeableWrapper对象，而RegistryProtocol.ExporterChangeableWrapper对象的exporter属性为ListenerExporterWrapper对象，而ListenerExporterWrapper对象的exporter属性为DubboExporter对象，而DubboExporter对象的invoker属性为FilterNode对象链，而FilterNode的filter是前面读取的Filter对象的实现类(被@Activate注解修饰，切group的值为"provider")，FilterNode的next属性还是FilterNode对象，最后一个FilterNode对象的next属性为RegistryProtocol.InvokerDelegate对象，而RegistryProtocol.InvokerDelegate对象的invoker属性为DelegateProviderMetaDataInvoker对象，而DelegateProviderMetaDataInvoker对象那个的invoker属性为AbstractProxyInvoker抽象类的匿名实现类。断点验证，结果如下：

由断点结果来看，符合预期(层层嵌套....在看代码的时候，不做笔记，很容易漏掉)。当然，这里的RegistryProtocol.DestroyableExporter对象也不是那么重要，重要的是DubboExporter对象，因为最终获取的是DubboExporter#getInvoker()方法，获取Invoker对象，并执行Invoker#invoke()方法，直接看调用Invoker#invoke()方法的地方，代码如下：

看看FilterNode#invoke()方法，代码如下：

(注：每个Filter的实现类都提供了不同的功能，这里我就不讲了,有兴趣的自己看) 剩下要经过的的Filter实现类为以下这些，Filter#invoker()方法分别是为：

最后一个Filter为ExceptionFilter，在ExceptionFilter#invoke()方法中，才会真正的调用Invoker#invoke()方法，代码如下：

看看AbstractProxyInvoker#invoke()方法，代码如下：

在JavassistProxyFactory中创建了AbstractProxyInvoker抽象类的匿名实现类，并且实现了AbstractProxyInvoker#doInvoke()方法，代码如下：

可知，最终是调用Wrapper实现类的invokeMethod()方法，只不过这个实现类是加载String动态动态生成的字节码对象，反射调用构造方法传创建的，这在前面提到过，这里不再赘述。但是我把Wrapper实现类.java文件弄出来了，它的invokeMethod()方法为：

最后得到结果，返回。顺便看看返回执行的逻辑是怎样的，还是回到NettyServerHandler#channelRead()方法，代码如下：

看看NettyChannel#getOrAddChannel()方法，代码如下：

看看HeaderExchangeChannel#getOrAddChannel()方法，看看返回的ExchangeChannel的实现类是哪个，代码如下：

断点看看，结果如下：

上图调用Channel#writeAndFlush()方法的时候，并不会马上向客户端发消息，而是经过一系列ChannelHandler链，代码就不追了，对Netty有兴趣的，可以看我写的博客《Netty源码深度解析》。大概是这样：如果是服务端向客户端发消息的话，会经过一系列ChannelOutboundHandler对象。其实就是一个ChannelHandler链，从tail -> head (tail 和 head均为DefaultChannelPipeline类的成员属性，通过AbstractChannelHandlerContext的next和prev属性关联起来，组成双向链表，而ChannelOutboundHandler对象会先包装成DefaultChannelHandlerContext对象，它是AbstractChannelHandlerContext的子类，再添加到tail 和 head之间)；如果是客户端给服务端发消息，则是head -> tail (调用的是一系列ChannelInboundHandler#channelRead()方法)。这里就是往DefaultChannelPipeline中添加ChannelOutboundHandler对象，如添加编码类，代码如下：

之前聊到解码的时候没详细讲调用链路，这里我在讲编码的时候，讲细一点。这里的编码是通过InternalEncoder完成的，看看该类，代码如下：

看看InternalEncoder的继承图，结果如下：

可知InternalEncoder实现了ChannelOutboundHandler，最终消息发出去之前，肯定会调用ChannelOutboundHandler#write()方法，具体的实现是在InternalEncoder的父类MessageToByteEncoder#write()方法，代码如下：

再看看InternalEncoder#encode()方法，代码如下：

到这里为止，我觉得应该是把服务提供方目标方法的调用，以及执行结果是如何响应给客户端，讲解得非常清楚了。同时，还顺便提了一点Netty相关的代码，希望我讲的，能给各位带来一点启发。

再回到RegistryProtocol#export()方法，还会干一件事，也就是将服务提供方的ip/port等信息注册到注册中心，核心代码如下：

先看看RegistryProtocol#getRegistry()方法，代码如下：

由于RegistryProtocol是通过Dubbo的SPI机制加载创建的，之前也提到过，通过Dubbo的SPI创建对象的时候，会找出所有没有被@DisableInject修饰的Setter方法，然后从Spring容器中或者Dubbo的SPI找对应的类的对象，通过反射调用Setter方法进行赋值，很显然RegistryFactory对象在Spring容器中是没有，因此是通过进行Dubbo的SPI的，看看RegistryFactory接口，代码如下：