dubbo ChannelHandler

记得我们在做服务暴露的bind和服务调用的connect都有一个ExchangeHandler的实例作为入参：

这个handler最终会利用装饰者模式被封装若干层，Dubbo中提供了大量的Handler去承载特性和扩展，这些Handler最终会和底层通信框架做关联。在NettyServer和NettyClient中最多有3个Handler，分别是编码，解码和NettyServerHandler或NettyClientHandler：

 其实这里也不止我们看到的这些层包装，我们继续看下构造NettyClient的逻辑：

 

可以看到在DecoderHandler之后还层包装了Dispatcher，HeartbeatHandler，MultiMessageHandler

 

在图中Dispatcher就是线程池派发器，Dispatcher真实的职责是创建具有线程派发能力的ChannelHandler，比如AllChannelHandler，MessageOnlyChannelHandler和ExecutionChannelHandler，其本身不具备线程派发能力

通过 Exchange 层为框架引入 Request 和 Response 语义

 这里看下connect返回的HaderEchangeClient：

 这里将Transports.connect()返回的client包装成一个HeaderExchangeChannel，我们看下这里的request方法：

直接调用channel的request，继续看下HeaderExchangeChannel的构造方法和request方法：

可以看到最后还是调用了transports.connect()返回的client的send方法，继续nettyClient的send方法：

send的真正实现是在其超类的超类AbstractPeer中

 

补充下dubbo官方文档的调用栈帧：

 

后面的就不详细截图了，注意到我们给transports.connect()传递的DecodeChannel并没有在发起调用的时候发挥作用，之前的帖子还在奇怪为什么connect和bind用了同一个ExchangeHandlerAdapter的实现

补充下各Handler的作用： 

 dispatcher扩展点：

 

 

作用如下：

all：将所有I/O事件交给Dubbo线程池处理，Dubbo默认启用

connection:单独线程池处理连接断开事件，和Dubbo线程池分开

direct:所有方法调用和事件处理在I/O线程中，不推荐

execution:只在线程池处理接收请求，其他事件在I/O线程池中

message:只在线程池处理请求和响应事件，其他事件在I/O线程池中

mockdispatcher:默认返回null