系列文章：

源码分析 -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 的各种应用服务器和协议栈开发的快速发展。