本文共 3641 字，大约阅读时间需要 12 分钟。

6.1 逻辑架构

Netty 采用了典型的三层网络架构进行设计和开发，逻辑架构如图 6-1 所示：

Reactor 通信调度层：它由一系列辅助类完成，包括 Reactor 线程 NioEventLoop 及其父类，NioSocketChannel/ NioServerSocketChannel 及其父类， ByteBuffer 以及由其衍生出来的各种 Buffer，Unsafe 以及其衍生出的各种内部 类等。该层的主要职责就是监听网络的读写和连接操作，负责将网络层的数据读 取到内存缓冲区中，然后触发各种网络事件，例如连接创建、连接激活、读事件、 写事件等，将这些事件触发到 PipeLine 中，由 PipeLine 管理的职责链来进行后 续的处理。

职责链 ChannelPipeline：它负责事件在职责链中的有序传播，同时负责动 态地编排职责链。职责链可以选择监听和处理自己关心的事件，它可以拦截处理 和向后 / 向前传播事件。不同应用的 Handler 节点的功能也不同，通常情况下， 往往会开发编解码 Hanlder 用于消息的编解码，它可以将外部的协议消息转换成 内部的 POJO 对象，这样上层业务则只需要关心处理业务逻辑即可，不需要感知 底层的协议差异和线程模型差异，实现了架构层面的分层隔离。

业务逻辑编排层（Service ChannelHandler）：业务逻辑编排层通常有两类： 一类是纯粹的业务逻辑编排，还有一类是其他的应用层协议插件，用于特定协议 相关的会话和链路管理。例如 CMPP 协议，用于管理和中国移动短信系统的对接。

架构的不同层面，需要关心和处理的对象都不同，通常情况下，对于业务开 发者，只需要关心职责链的拦截和业务 Handler 的编排。因为应用层协议栈往往 是开发一次，到处运行，所以实际上对于业务开发者来说，只需要关心服务层的 业务逻辑开发即可。各种应用协议以插件的形式提供，只有协议开发人员需要关 注协议插件，对于其他业务开发人员来说，只需关心业务逻辑定制。这种分层的 架构设计理念实现了 NIO 框架各层之间的解耦，便于上层业务协议栈的开发和业 务逻辑的定制。

正是由于 Netty 的分层架构设计非常合理，基于 Netty 的各种应用服务器和 协议栈开发才能够如雨后春笋般得到快速发展。

6.2 关键架构质量属性

6.2.1 高性能

影响最终产品的性能因素非常多，其中软件因素如下 :

• 架构不合理导致的性能问题；

• 编码实现不合理导致的性能问题，例如锁的不恰当使用导致性能瓶颈。 硬件因素如下 :

• 服务器硬件配置太低导致的性能问题；

• 带宽、磁盘的IOPS等限制导致的I/O操作性能差；

• 测试环境被共用导致被测试的软件产品受到影响。 尽管影响产品性能的因素非常多，但是架构的性能模型合理与否对性能的影 响非常大。如果一个产品的架构设计得不好，无论开发如何努力，都很难开发出 一个高性能、高可用的软件产品。

“性能是设计出来的，而不是测试出来的”。下面我们看 Netty 的架构设 计是如何实现高性能的。

（1）采用异步非阻塞的 I/O 类库，基于 Reactor 模式实现，解决了传统同 步阻塞 I/O 模式下一个服务端无法平滑地处理线性增长的客户端的问题。

（2）TCP 接收和发送缓冲区使用直接内存代替堆内存，避免了内存复制， 提升了 I/O 读取和写入的性能。

（3）支持通过内存池的方式循环利用 ByteBuf，避免了频繁创建和销毁 ByteBuf 带来的性能损耗。

（4）可配置的 I/O 线程数、TCP 参数等，为不同的用户场景提供定制化的 调优参数，满足不同的性能场景。

（5）采用环形数组缓冲区实现无锁化并发编程，代替传统的线程安全容器 或者锁。

（6）合理地使用线程安全容器、原子类等，提升系统的并发处理能力。

（7）关键资源的处理使用单线程串行化的方式，避免多线程并发访问带来 的锁竞争和额外的 CPU 资源消耗问题。

（8）通过引用计数器及时地申请释放不再被引用的对象，细粒度的内存管 理降低了 GC 的频率，减少了频繁 GC 带来的时延增大和 CPU 损耗。

无论是 Netty 的官方性能测试数据，还是携带业务实际场景的性能测试， Netty 在各个 NIO 框架中综合性能是最高的。

6.2.2 可靠性

作为一个高性能的异步通信框架，架构的可靠性是大家选择的一个重要依据。 下面我们探讨 Netty 架构的可靠性设计。

1．链路有效性检测

由于长连接不需要每次发送消息都创建链路，也不需要在消息交互完成时关 闭链路，因此相对于短连接性能更高。对于长连接，一旦链路建立成功便一直维 系双方之间的链路，直到系统退出。

为了保证长连接的链路有效性，往往需要通过心跳机制周期性地进行链路检 测。使用周期性心跳的原因是：在系统空闲时，例如凌晨，往往没有业务消息。 如果此时链路被防火墙 Hang 住，或者遭遇网络闪断、网络单通等，通信双方无 法识别出这类链路异常。等到第二天业务高峰期到来时，瞬间的海量业务冲击会 导致消息积压无法发送给对方，由于链路的重建需要时间，这期间业务会大量失 败（集群或者分布式组网情况会好一些）。为了解决这个问题，需要周期性的心 跳对链路进行有效性检测，一旦发生问题，可以及时关闭链路，重建 TCP 连接。

当有业务消息时，无须心跳检测，可以由业务消息进行链路可用性检测。所 以心跳消息往往是在链路空闲时发送的。

为了支持心跳，Netty 提供了如下两种链路空闲检测机制：

• 读空闲超时机制：当连续周期T没有消息可读时，触发超时Handler，用户 可以基于读空闲超时发送心跳消息，进行链路检测；如果连续N个周期仍 然没有读取到心跳消息，可以主动关闭链路。

• 写空闲超时机制：当连续周期T没有消息要发送时，触发超时Handler，用 户可以基于写空闲超时发送心跳消息，进行链路检测；如果连续N个周期 仍然没有接收到对方的心跳消息，可以主动关闭链路。

为了满足不同用户场景的心跳定制，Netty 提供了空闲状态检测事件通知机 制，用户可以订阅空闲超时事件、写空闲超时事件、读或者写超时事件，在接收 到对应的空闲事件之后，灵活地进行定制。

2. 内存保护机制

Netty 提供多种机制对内存进行保护，包括以下几个方面：

• 通过对象引用计数器对Netty的ByteBuf等内置对象进行细粒度的内存申请 和释放，对非法的对象引用进行检测和保护。

• 通过内存池来重用ByteBuf，节省内存。

• 可设置的内存容量上限，包括ByteBuf、线程池线程数等。

如果长度解码器没有单个消息最大报文长度限制，当解码错位或者读取到畸 形码流时，长度值可能是个超大整数值，例如 4294967296，这很容易导致内存 溢出。如果有上限保护，例如单条消息最大不允许超过 10MB，当读取到非法消 息长度 4294967296 后，直接抛出解码异常，这样就避免了大内存的分配。

3. 优雅停机

相比于 Netty 的早期版本，Netty 5.0 版本的优雅退出功能做得更加完善。 优雅停机功能指的是当系统退出时，JVM 通过注册的 Shutdown Hook 拦截到退出 信号量，然后执行退出操作，释放相关模块的资源占用，将缓冲区的消息处理完 成或者清空，将待刷新的数据持久化到磁盘或者数据库中，等到资源回收和缓冲 区消息处理完成之后，再退出。

优雅停机往往需要设置个最大超时时间 T，如果达到 T 后系统仍然没有退出， 则通过 Kill - 9 pid 强杀当前的进程。Netty 所有涉及到资源回收和释放的地 方都增加了优雅退出的方法。它们的相关接口如表 6-1 所示。

6.2.3 可定制性

Netty 的可定制性主要体现在以下几点：

• 责任链模式：ChannelPipeline基于责任链模式开发，便于业务逻辑的拦 截、定制和扩展。

• 基于接口的开发：关键的类库都提供了接口或者抽象类，如果Netty自身 的实现无法满足用户的需求，可以由用户自定义实现相关接口。

• 提供了大量工厂类，通过重载这些工厂类可以按需创建出用户实现的对 象。

• 提供了大量的系统参数供用户按需设置，增强系统的场景定制性。

6.2.4 可扩展性

基于 Netty 的基础 NIO 框架，可以方便地进行应用层协议定制，例如 HTTP 协议栈、Thrift 协议栈、FTP 协议栈等。这些扩展不需要修改 Netty 的源码，直 接基于 Netty 的二进制类库即可实现协议的扩展和定制。

目前，业界存在大量的基于 Netty 框架开发的协议，例如基于 Netty 的 HTTP 协议、Dubbo 协议、RocketMQ 内部私有协议等。

备注：本文参考《深入浅出Netty》，作者：李林锋

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

转载地址：http://gjyab.baihongyu.com/