系列文章：
源码分析 -Netty：开篇
源码分析 -Netty：多线程在 Netty 中的应用
源码分析-Netty: 并发编程的实践（二）
一 概述
前面描述了Netty的架构图、特性、基本版本信息和并发编程实践等，本篇将详细剖析Netty的逻辑架构，自顶向下梳理Netty的设计思想和主体实现方式，并据此对Netty框架有一个整体的把握。
二 逻辑架构
Netty的逻辑架构图如下所示：
图1 逻辑架构图
可见Netty采用了三层网络结构的架构设计进行设计和开发。Reactor、PipeLine 和 Service三层组成了Netty的逻辑架构。
三 通信调度-Reactor
前面我们介绍过Reactor线程模型。事实上，Netty中的Reactor由多个辅助类组成，包括Reactor线程NioEventLoop及其父类，NioSocketChannel及其父类、ByteBuffer及其衍生的多个Buffer、Unsafe以及它们衍生出的各种内部类等等。
作为三层结构中的最底层，Reactor层主要负责监听网络的读写和链接操作，负责将网络层的数据读取到内存缓冲区中，然后触发网络事件，如连接创建、连接激活、读/写事件等，这些事件会被触发到PipeLine中，由PipeLine管理的责任链来进行后续处理。
四 责任链-ChannelPipeline
责任链（Netty权威指南 第2版中称为职责链），负责事件在责任链中的有序传播，同时也负责责任链的动态编排。如果你对设计模式足够熟悉，那么应该知道有一个叫做责任链的设计模式，可以简单理解为这一层就是责任链模式的一个实现。
责任链可以选择监听和处理关心的事件，可以拦截处理和向后or向前传播时间（类似filter）。不同应用的Handler节点的功能也有所不同。
通常情况下，我们需要开发编解码Handler用于处理接收到消息的编解码，用于把外部传来的协议消息转换成内部的数据结构（POJO对象）。通过这样的处理，上层业务只需要关心核心业务逻辑即可，不必再感知底层的协议差异和线程模型差异，实现了架构层面的分层隔离。
五 业务逻辑层-Service ChannelHandler
业务逻辑层也可以分为两大部分：应用层协议插件， 以及纯粹的业务逻辑编排。应用协议插件用于特定协议相关会话和链路管理，例如图1 逻辑架构图中所包含的FTP、HTTP和CMPP三种协议插件，其中CMPP就是用于管理和中国移动短信系统对接的协议插件。
在这一层，作为业务开发人员，我们只需要关心责任链的拦截和业务Handler的编排。因为应用层协议栈通常是只需要开发一次，后续可以直接使用。这样把开发人员的职责聚焦到服务层的业务逻辑开发上，可以更高效，并且逻辑清晰。这样的设计实现了NIO框架各层之间的解耦，便于上层业务协议栈的开发和业务逻辑的定制。
六 总结
本篇介绍了Netty的逻辑架构。看似内容不多，但深入分析，可以发现『简单』的基础之上蕴含了很多我们曾经学习过的架构设计原则，例如分层架构、Reactor模型、责任链设计模式、事件模型等等。正是由于有这些非常合理的设计，才有基于Netty的各种应用服务器和协议栈开发的快速发展。
