正文
可扩展性好,可通过它提供的 ChannelHandler 组件对网络通信方面进行灵活扩展。
易用性,API 使用简单。
经过了许多商业应用的考验,在互联网、网络游戏、大数据、电信软件等众多行业得到成功商用。
Netty 采用了典型的三层网络架构进行设计,逻辑架构图如下:
图 4(Netty 三层网络逻辑架构)
第一层
:Reactor 通信调度层。该层的主要职责就是监听网络的连接和读写操作,负责将网络层的数据读取到内存缓冲区中,然后触发各种网络事件,例如连接创建、连接激活、读事件、写事件等,将这些事件触发到 Pipeline 中,再由 Pipeline 充当的职责链来进行后续的处理
第二层
:职责链 Pipeline 层。负责事件在职责链中有序的向前(后)传播,同时负责动态的编排职责链。Pipeline 可以选择监听和处理自己关心的事件。
第三层
:业务逻辑处理层,一般可分为两类:a. 纯粹的业务逻辑处理,例如日志、订单处理。b. 应用层协议管理,例如 HTTP(S) 协议、FTP 协议等。
我们都知道影响网络服务通信性能的主要因素有:网络 I/O 模型、线程(进程)调度模型和数据序列化方式。
在网络 I/O 模型方面,Netty 采用基于非阻塞 I/O 的实现,底层依赖的是 JDK NIO 框架的 Selector。
在线程调度模型方面,Netty 采用 Reactor 线程模型。常用的 Reactor 线程模型有三种,分别是:
-
Reactor 单线程模型:Reactor 单线程模型,指的是所有的 I/O 操作都在同一个 NIO 线程上面完成。对于一些小容量应用场景,可以使用单线程模型。
-
Reactor 多线程模型:Rector 多线程模型与单线程模型最大的区别就是有一组 NIO 线程处理 I/O 操作。主要用于高并发、大业务量场景。
-
主从 Reactor 多线程模型:主从 Reactor 线程模型的特点是服务端用于接收客户端连接的不再是一个单独的 NIO 线程,而是一个独立的 NIO 线程池。利用主从 NIO 线程模型,可以解决一个服务端监听线程无法有效处理所有客户端连接的性能不足问题。Netty 线程模型并非固定不变的,它可以支持三种 Reactor 线程模型。
在数据序列化方面,影响序列化性能的主要因素有:
-
序列化后的码流大小(网络带宽占用)。
-
序列化和反序列化操作的性能(CPU 资源占用)。
-
并发调用时的性能表现:稳定性、线性增长等。
Netty 默认提供了对 Google Protobuf 二进制序列化框架的支持,但通过扩展 Netty 的编解码接口,可以实现其它的高性能序列化框架,例如 Avro、Thrift 的压缩二进制编解码框架。
通过对 Netty 网络框架的分析研究以及对比测试(见后面的可行性分析测试报告)可判断,基于 Netty 的数据采集方案能解决高数据吞吐量和数据实时收集的难点。
对一些明感的采集数据,需要在数据传输过程中进行加密处理。目前存在的问题是,客户端采集代码比较容易被匿名用户获取并反编译(例如 Android、JavaScript),导致数据加密的算法和密钥被用户窃取,较难保证数据的安全性。根据加密结果是否可以被解密,算法可以分为可逆加密和不可逆加密(单向加密)。具体的分类结构如下:
图 5(加密算法分类)
密钥:对于可逆加密,密钥是加密解算法中的一个参数,对称加密对应的加解密密钥是相同的;非对称加密对应的密钥分为公钥和私钥,公钥用于加密,私钥用于解密。私钥是不公开不传送的,仅仅由通信双方持有保留;而公钥是可以公开传送的。非对称密钥还提供一种功能,即数字签名。通过私钥进行签名,公钥进行认证,达到身份认证的目的。