本文提到的dubbo版本为2.6.1
这段时间一直在跟DUBBO和netty的源码，下面描述下dubbo使用netty作为传输层的调用链，首先从dubbo启动nettyserver开始(至于nettyserver何时启动，这里暂时不深入讲解因为涉及到Spring解析ml,加载,实例化，初始化bean的一整套流程，有时间再写文章单独讲解，这里先暂时提一点关键点：ServiceBean<T>的onApplicationEvent方法)。
1：NettyServer在doOpen的时候会创建两个ExecutorService ，一个取名叫boss(起主要作用是，监听暴露的端口，当有新的连接请求的时候经过TCP三次握手成功后，其会初始化一个NioAcceptChannel,并将这个channel注册到另一个ExecutorService worker),另一个取名worker(其主要作用就是就收boss给自己的channel,并开启一个线程worker2(对应一个selector2)来轮询这个channel上面的事件，包括连接，断开连接，client的心跳，发送消息和接收消息等事件。)下面看看源代码截图：
2：boss将监听到的连接请求交给worker2后，boss就没什么事了就继续监听连接请求。下面就是worker2处理这个channel上面所有的事情了，worker2将会轮询注册在selector2上面的channel(一个selector可以管理多个channel连接),当监听到事件后，将事件一步一步交给ChannelPipeline,至于ChannelPipeline是有些什么，dubbo提供了三个handler(从上面第一张图上的77-88行代码可以看到)。这里说说三个handler的作用，decoder,用于对接收到的消息进行解码(dubbo提供了多种编解码方式，用户还可以自己扩展，具体的参看DUBBO的官方文档)，encoder,用与对相应消息进行编码，handler主要是构造另外三个channelhandler,包括MultiMessageHandler，HeartbeatHandler，AllDispatcher(AllChannelHandler，这里并不一定是AllDispatcher，具体请参考我的上一篇博文关于DUBBO线程模型的文章),这三个handler后面再说
3：接收到的请求经过解码后,将会交给MultiMessageHandler，HeartbeatHandler以及AllChannelHandler，HeartbeatHandler主要是进行心跳消息的接收和发送(为了维持长连接，必须发送心跳消息，这里又涉及到TCP长连接的知识，不再详细描述)。AllChannelHandler很重要。其关系到了DUBBO的线程模型，在DUBBO中线程模型是可以自定义扩展的，但是默认是ALLDispatcher。到这里后，worker就不再处理channel上面的事件了，其会将构造一个ChannelEventRunnable，并将任务交给业务线程池。
4：业务线程池拿到任务后会执行几个handler以及几个filter,每个handler和filter的功能就不描述了，大部分看名字就能知道功能。业务线程最终会跑到我们业务真正执行的地方即下面这张图的第二行 DemoServiceImpl.sayHello
5：处理完handler和filter后相应消息将会一层一层返回回来直到HeaderExchangeHandler，在HeaderExchangeHandler中其会调用channel的send方法发送相应消息，当然在真正发送响应消息之前是需要编码的，下面第二张图channel.getPipeline得到得三个handelr(上面第一张图代码77-88行代码所示),其中有一个就是对响应消息编码的(encoder)，下面第三张图就是进行编码。
6：对响应消息进行编码后，会将channel交给worker2,并让worker2代为发送响应消息，而worker2会将这个channel封装成为一个org.jboss.netty.channel.socket.nio.AbstractNioChannel的WriteTask,并最终会调用AbstractNioWorker的write0(AbstractNioChannel<?> channel)方法发消息。
到这里，基本上一个DUBBO服务从接收消息到响应消息就结束了，