Dubbo源码分析 服务端 Handler & Filter

前面花了1个月时间 把netty 源码大致的过了一下 了解其工作原理及各个组件设计 可能有助于在使用上心更心里有底
然后花了几天时间 阅读理解了McQueenRPC 对rpc的实现有了更进一步的理解 

 

为什么看dubbo 

netty一直在用  也用过一些 nfs-rpc 看过几个rpc的实现

所以想看一下dubbo是怎么优秀的

服务注册 接口暴露这块待有空再看
趁热打铁 先了解一下dubbo协议是怎么定义 及netty通讯这块的调用链

先从服务器调用分析  客户端请求过来到 netty handler - messageReceived  收到消息之前有编码过程 
跟踪一遍 ExchangeCodec 从流协议头的处理到request的转换

然后再调用链再到reponse 返回

 

这里延伸出协议的定义 有一篇可写  

相关  AbstractPeer  维护ChannelHandler，实际构建时的handler为new DecodeHandler(new HeaderExchangeHandler(handler))

 

最后调用了handelr.reply()方法， 它的实现与具体的协议有关，比如默认配置下就是在DubboProtocol中构建的requestHandler，在createServer()方法中传递给Exchanger。

 

dubbo支持的filter接口还有一些不常用的

比如

 

这个Invoker实例来自于根据chanel 和message 参数  得到 serviceKey查找的Exporter，它是通过ExtensionLoader创建的，是一个ProtocolFilterWrapper实例。

 

这里会将原来的Invoker通过各种Filter包装成一个InvokerChain，一次调用会依次经过这些FilterChain到达最终的Filter。在这些Filter中可以进行超时校验、数据监控等工作，每个Filter相对独立，使得代码结构非常清晰，也便于为新功能进行扩展。

每一个filter 对应一个invoker   Invoker.invoker() 会不停代代相传最后到JavassistProxyFactory 执行然后返回

 

 

总结 基于NettyServer 增加 NettyHandler 实际是HeaderExchangeHandler 

通过 DubboProtocol 和ProtocolFilterWrapper  组装定位Invoker最后 JavassistProxyFactory 返回结果