在上面那一篇文章中，大致的介绍了一下dubbo的通信机制。不过感觉说的有点乱，总结了下面一张图：
图中的从“外到内”对应着“从dubbo底层到应用的业务逻辑层”，我把在这个过程中起到关键作用的类都标注了出来，**注意：**这里还是基于dubbo的默认协议dubbo，默认通信框架netty，以及默认的序列化方式dubbocodec。
这里我想讨论的是，注意看图中的“AllChannelHandler”类的职责之一：
把对应事件（connected、disconnected、received、caught）的执行业务分配给线程池中可使用线程
dubbo处理handler所使用的线程并非来自netty提供的I/O Work线程，而是dubbo自身来维护的一个java原生线程池，源码见com.alibaba.dubbo.remoting.transport.dispatcher.WrappedChannelHandler。why？
但从netty线程模型的分析中，可以认为netty提供的那些nio工作线程主要被用于消息链路的读取、解码、编码和发送。而dubbo把业务逻辑的执行放在自身维护的线程池中是否就是为了贯彻netty的这一原则呢？
从上面给的链接中可以注意到下面这段话：
Netty是个异步高性能的NIO框架，它并不是个业务运行容器，因此它不需要也不应该提供业务容器和业务线程。合理的设计模式是Netty只负责提供和管理NIO线程，其它的业务层线程模型由用户自己集成，Netty不应该提供此类功能，只要将分层划分清楚，就会更有利于用户集成和扩展。
正如文中所说，dubbo这么做有利于分离通信层，方便的替换掉netty。至于是否还有更高深的理由，我就不清楚了，希望大牛赐教。
另外dubbo在进行数据的读取和解析上做了很多工作，体现出了开发人员的功底，由于我在这部分没有经验，勉强看得懂就已经不错了，谈不上分析，就不瞎掰了。