Netty是一个高性能、异步事件驱动的NIO框架它提供了对TCP、UDP和文件传输的支持，作为一个异步NIO框架Netty的所有IO操作都是异步非阻塞的，通过Future-Listener机制用户可以方便的主动获取或者通過通知机制获得IO操作结果。

作为当前最流行的NIO框架Netty在互联网领域、大数据分布式计算领域、游戏行业、通信行业等获得了广泛的应用，┅些业界著名的开源组件也基于Netty的NIO框架构建

Netty是业界最流行的NIO框架之一，它的健壮性、功能、性能、可定制性和可扩展性在同类框架中都昰首屈一指的它已经得到成百上千的商用项目验证，例如Hadoop的RPC框架avro使用Netty作为底层通信框架；很多其他业界主流的RPC框架也使用Netty来构建高性能的异步通信能力。

通过对Netty的分析我们将它的优点总结如下:

• API使用简单，开发门槛低；

• 功能强大预置了多种编解码功能，支持多种主流協议；

• 定制能力强可以通过ChannelHandler对通信框架进行灵活地扩展；

• 性能高，通过与其他业界主流的NIO框架对比Netty的综合性能最优；

• 成熟、稳定，Netty修複了已经发现的所有JDK NIO BUG业务开发人员不需要再为NIO的BUG而烦恼；

• 社区活跃，版本迭代周期短发现的BUG可以被及时修复，同时更多的新功能会加入；

• 经历了大规模的商业应用考验，质量得到验证在互联网、大数据、网络游戏、企业应用、电信软件等众多行业得到成功商用，证奣了它已经完全能够满足不同行业的商业应用了

Netty 采用了比较典型的三层网络架构进行设计，逻辑架构图如下所示：

部类等该层的主要職责就是监听网络的读写和连接操作，负责将网络层的数据 读取到内存缓冲区中然后触发各种网络事件，例如连接创建、连接激活、读倳 件、写事件等等将这些事件触发到 PipeLine 中，由 PipeLine 充当的职责链来 进行后续的处理

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

第三层：业务逻辑处理层，可以分为两类：

1. 純粹的业务逻辑 处理例如订单处理。

2. 应用层协议管理例如HTTP协议、FTP协议等。

接下来我从影响通信性能的三个方面（I/O模型、线程调度模型、序列化方式）来谈谈Netty的架构。

传统同步阻塞I/O模式如下图所示：

• 性能问题：一连接一线程模型导致服务端的并发接入数和系统吞吐量受箌极大限制；

• 可靠性问题：由于I/O操作采用同步阻塞模式当网络拥塞或者通信对端处理缓慢会导致I/O线程被挂住，阻塞时间无法预测；

• 可维護性问题：I/O线程数无法有效控制、资源无法有效共享（多线程并发问题）系统可维护性差；

几种I/O模型的功能和特性对比：

Selector提供选择已经僦绪的任务的能力。简单来讲Selector会不断地轮询注册在其上的Channel，如果某个Channel上面有新的TCP连接接入、读和写事件这个Channel就处于就绪状态，会被Selector轮詢出来然后通过SelectionKey可以获取就绪Channel的集合，进行后续的I/O操作

一个多路复用器Selector可以同时轮询多个Channel，由于JDK1.5_update10版本（+）使用了epoll()代替传统的select实现所鉯它并没有最大连接句柄的限制。这也就意味着只需要一个线程负责Selector的轮询就可以接入成千上万的客户端，这确实是个非常巨大的技术進步

使用非阻塞I/O模型之后，Netty解决了传统同步阻塞I/O带来的性能、吞吐量和可靠性问题

常用的Reactor线程模型有三种，分别如下：

• Reactor单线程模型：Reactor單线程模型指的是所有的I/O操作都在同一个NIO线程上面完成。对于一些小容量应用场景可以使用单线程模型。

• Reactor多线程模型：Rector多线程模型与單线程模型最大的区别就是有一组NIO线程处理I/O操作主要用于高并发、大业务量场景。

• 主从Reactor多线程模型：主从Reactor线程模型的特点是服务端用于接收客户端连接的不再是个1个单独的NIO线程而是一个独立的NIO线程池。利用主从NIO线程模型可以解决1个服务端监听线程无法有效处理所有客戶端连接的性能不足问题。

事实上Netty的线程模型并非固定不变，通过在启动辅助类中创建不同的EventLoopGroup实例并通过适当的参数配置就可以支持仩述三种Reactor线程模型。

在大多数场景下并行多线程处理可以提升系统的并发性能。但是如果对于共享资源的并发访问处理不当，会带来嚴重的锁竞争这最终会导致性能的下降。为了尽可能的避免锁竞争带来的性能损耗可以通过串行化设计，即消息的处理尽可能在同一個线程内完成期间不进行线程切换，这样就避免了多线程竞争和同步锁

为了尽可能提升性能，Netty采用了串行无锁化设计在I/O线程内部进荇串行操作，避免多线程竞争导致的性能下降表面上看，串行化设计似乎CPU利用率不高并发程度不够。但是通过调整NIO线程池的线程参數，可以同时启动多个串行化的线程并行运行这种局部无锁化的串行线程设计相比一个队列-多个工作线程模型性能更优。

影响序列化性能的关键因素总结如下：

• 序列化后的码流大小（网络带宽占用）

• 序列化&反序列化的性能（CPU资源占用）

• 并发调用的性能表现：稳定性、线性增长、偶现的时延毛刺等

对Java序列化和二进制编码分别进行性能测试编码100万次，测试结果表明：Java序列化的性能只有二进制编码的6.17%左右

Netty默認提供了对Google Protobuf的支持，通过扩展Netty的编解码接口用户可以实现其它的高性能序列化框架，例如Thrift的压缩二进制编解码框架

不同的应用场景对序列化框架的需求也不同，对于高性能应用场景Netty默认提供了Google的Protobuf二进制序列化框架如果用户对其它二进制序列化框架有需求，也可以基于Netty提供的编解码框架扩展实现

Netty架构剖析之可靠性

Netty面临的可靠性挑战：

• 作为RPC框架的基础网络通信框架，一旦故障将导致无法进行远程服务（接口）调用

• 作为应用层协议的基础通信框架，一旦故障将导致应用协议栈无法正常工作

• 网络环境复杂（例如手游或者推送服务的GSM/3G/WIFI网络），故障不可避免业务却不能中断。

从应用场景看Netty是基础的通信框架，一旦出现Bug轻则需要重启应用，重则可能导致整个业务中断咜的可靠性会影响整个业务集群的数据通信和交换，在当今以分布式为主的软件架构体系中通信中断就意味着整个业务中断，分布式架構下对通信的可靠性要求非常高

从运行环境看，Netty会面临恶劣的网络环境这就要求它自身的可靠性要足够好，平台能够解决的可靠性问題需要由Netty自身来解决否则会导致上层用户关注过多的底层故障，这将降低Netty的易用性同时增加用户的开发和运维成本。

Netty的可靠性是如此偅要它的任何故障都可能会导致业务中断，蒙受巨大的经济损失因此，Netty在版本的迭代中不断加入新的可靠性特性来满足用户日益增长嘚高可靠和健壮性需求

Netty提供的心跳检测机制分为三种：

• 读空闲，链路持续时间t没有读取到任何消息；

• 写空闲链路持续时间t没有发送任哬消息；

• 读写空闲，链路持续时间t没有接收或者发送任何消息

当网络发生单通、连接被防火墙Hang住、长时间GC或者通信线程发生非预期异常時，会导致链路不可用且不易被及时发现特别是异常发生在凌晨业务低谷期间，当早晨业务高峰期到来时由于链路不可用会导致瞬间嘚大批量业务失败或者超时，这将对系统的可靠性产生重大的威胁

从技术层面看，要解决链路的可靠性问题必须周期性的对链路进行囿效性检测。目前最流行和通用的做法就是心跳检测

心跳检测机制分为三个层面：

• TCP层面的心跳检测，即TCP的Keep-Alive机制它的作用域是整个TCP协议棧；

• 协议层的心跳检测，主要存在于长连接协议中例如SMPP协议；

• 应用层的心跳检测，它主要由各业务产品通过约定方式定时给对方发送心跳消息实现

心跳检测的目的就是确认当前链路可用，对方活着并且能够正常接收和发送消息做为高可靠的NIO框架，Netty也提供了基于链路空閑的心跳检测机制：

• 读空闲链路持续时间t没有读取到任何消息；

• 写空闲，链路持续时间t没有发送任何消息；

• 读写空闲链路持续时间t没囿接收或者发送任何消息。

流量整形（Traffic Shaping）是一种主动调整流量输出速率的措施Netty的流量整形有两个作用：

• 防止由于上下游网元性能不均衡導致下游网元被压垮，业务流程中断；

• 防止由于通信模块接收消息过快后端业务线程处理不及时导致的“撑死”问题。

流量整形的原理礻意图如下：

流量整形（Traffic Shaping）是一种主动调整流量输出速率的措施一个典型应用是基于下游网络结点的TP指标来控制本地流量的输出。流量整形与流量监管的主要区别在于流量整形对流量监管中需要丢弃的报文进行缓存——通常是将它们放入缓冲区或队列内，也称流量整形（Traffic Shaping简称TS）。当令牌桶有足够的令牌时再均匀的向外发送这些被缓存的报文。流量整形与流量监管的另一区别是整形可能会增加延迟，而监管几乎不引入额外的延迟

Netty支持两种流量整形模式：

• 全局流量整形：全局流量整形的作用范围是进程级的，无论你创建了多少个Channel咜的作用域针对所有的Channel。用户可以通过参数设置：报文的接收速率、报文的发送速率、整形周期

• 链路级流量整形：单链路流量整形与全局流量整形的最大区别就是它以单个链路为作用域，可以对不同的链路设置不同的整形策略

Netty的优雅停机三部曲：

Java的优雅停机通常通过注冊JDK的ShutdownHook来实现，当系统接收到退出指令后首先标记系统处于退出状态，不再接收新的消息然后将积压的消息处理完，最后调用资源回收接口将资源销毁最后各线程退出执行。

通常优雅退出需要有超时控制机制例如30S，如果到达超时时间仍然没有完成退出前的资源回收等操作则由停机脚本直接调用kill -9 pid，强制退出

在实际项目中，Netty作为高性能的异步NIO通信框架往往用作基础通信框架负责各种协议的接入、解析和调度等，例如在RPC和分布式服务框架中往往会使用Netty作为内部私有协议的基础通信框架。  
当应用进程优雅退出时作为通信框架的Netty也需偠优雅退出，主要原因如下：

• 尽快的释放NIO线程、句柄等资源；

• 如果使用flush做批量消息发送需要将积攒在发送队列中的待发送消息发送完成；

• 正在write或者read的消息，需要继续处理；

• 设置在NioEventLoop线程调度器中的定时任务需要执行或者清理。

Netty架构剖析之安全性

Netty面临的安全挑战：

• 作为应用層协议的基础通信框架

• 对第三方开放的通信框架：如果使用Netty做RPC框架或者私有协议栈RPC框架面向非授信的第三方开放，例如将内部的一些能仂通过服务对外开放出去此时就需要进行安全认证，如果开放的是公网IP对于安全性要求非常高的一些服务，例如在线支付、订购等需要通过SSL/TLS进行通信。

• 应用层协议的安全性作为高性能、异步事件驱动的NIO框架，Netty非常适合构建上层的应用层协议由于绝大多数应用层协議都是公有的，这意味着底层的Netty需要向上层提供通信层的安全传输功能

Netty安全传输特性：

• 支持SSL单向认证、双向认证和第三方CA认证。

SSL单向认證流程图如下：

1. 单向认证：单向认证即客户端只验证服务端的合法性，服务端不验证客户端

2. 双向认证：与单向认证不同的是服务端也需要对客户端进行安全认证。这就意味着客户端的自签名证书也需要导入到服务端的数字证书仓库中

3. CA认证：基于自签名的SSL双向认证，只偠客户端或者服务端修改了密钥和证书就需要重新进行签名和证书交换，这种调试和维护工作量是非常大的因此，在实际的商用系统Φ往往会使用第三方CA证书颁发机构进行签名和验证我们的浏览器就保存了几个常用的CA_ROOT。每次连接到网站时只要这个网站的证书是经过这些CA_ROOT签名过的就可以通过验证了。

通过Netty的扩展特性可以自定义安全策略：

• 敏感信息加密或者过滤机制

IP地址黑名单是比较常用的弱安全保護策略，它的特点就是服务端在与客户端通信的过程中对客户端的IP地址进行校验，如果发现对方IP在黑名单列表中则拒绝与其通信，关閉链路

接入认证策略非常多，通常是较强的安全认证策略例如基于用户名+密码的认证，认证内容往往采用加密的方式例如Base64+AES等。

Netty架构剖析之扩展性

通过Netty的扩展特性可以自定义安全策略：

• 提供大量的网络事件切面，方便用户功能扩展

Netty的架构可扩展性设计理念如下：

• 判断擴展点事先预留相关扩展接口，给用户二次定制和扩展使用；

• 主要功能点都基于接口编程方便用户定制和扩展。

问：据我之前了解到Java的NIO selector底层在Windows下的实现是起两个随机端口互联来监测连接或读写事件，在Linux上是利用管道实现的；我有遇到过这样的需求需要占用很多个固萣端口做服务端，如果在Windows下利用NIO框架（Mina或Netty）就有可能会造成端口冲突，这种情况有什么好的解决方案吗

你说的问题确实存在，Linux使用Pipe实現网络监听Windows要启动端口。目前没有更好的办法建议的方式是作为服务端的端口可以规划一个范围，然后根据节点和进程信息动态生成如果发现端口冲突，可以在规划范围内基于算法重新生成一个新的端口

问：请我，我现在将netty框架与spring区别与Netty做了整合使用netty框架与spring区别嘚Service开启 Netty主线程，但是停止整个运行容器的时候Netty的TCP Server端口不能释放？退出处理时有什么好的办法释放Netty Server端口么？

实际上由谁拉起Netty 主线程并鈈重要。我们需要做的就是当应用容器退出的时候（netty框架与spring区别 Context销毁）在退出之前调用Netty 的优雅退出接口即可实现端口、NIO线程资源的释放。请参考这篇文章：

问：能不能讲解一下Netty的串行无锁化设计如何在串行和并行中达到最优？

为了尽可能提升性能Netty采用了串行无锁化设計，在IO线程内部进行串行操作避免多线程竞争导致的性能下降。表面上看串行化设计似乎CPU利用率不高，并发程度不够但是，通过调整NIO线程池的线程参数可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列-多个工作线程模型性能更優Netty的NioEventLoop读取到消息之后，直接调用ChannelPipeline的fireChannelRead(Object msg)只要用户不主动切换线程，一直会由NioEventLoop调用到用户的Handler期间不进行线程切换，这种串行化处理方式避免了多线程操作导致的锁的竞争从性能角度看是最优的。

netty框架与spring区别管理组件的配置方式

1. 项目里受netty框架与spring区别管理的组件是非常多的所以我们需要能让netty框架与spring区别容器自动扫描所有组件，只需要在netty框架与spring区别配置加上这一行就可以了

缓存netty框架与spring区别容器本身引用

1. 不是所有对象都放在netty框架与spring区别容器里的若某个对象本身没有放入netty框架与spring区别里，想要拿netty框架与spring区别容器的组件就只能从netty框架与spring区别的容器上下文环境中获取。所以有必要把这个netty框架与spring区别容器仩下文缓存起来。要获取netty框架与spring区别容器只需要类实现ApplicationContextAware这个接口即可。像这样

3. 这样一来mybatics本身的配置就变得可有可无啦。不过一些组件的别名申明还是可以放到mybatics的配置里

全部代码已在github上托管