[Netty 1] 初识Netty

1. 简介

最先接触netty是在阅读Zookeeper源码的时候，后来看到Storm的消息传输层也由ZMQ转为Netty，因此决心好好来研究和学习一下netty这个框架。

Netty项目地址：http://netty.io/index.html 

Github项目： https://github.com/netty/netty

Netty是一个异步的、事件驱动的网络应用框架，基于它可以快速开发高性能协议的服务器和客户端。Netty是基于NIO的，它大大简化了网络编程，Netty强调“quick and easy“，但并不只限于”quick and easy“，它的实现是创建在吸收了许多协议（FTP、SMTP、HTTP等）的实现经验的基础之上的，通过做者精心的设计探索，成功的找到了一种方式，在保证易于开发的同时还保证了其应用的性能，稳定性和伸缩性。

2. 架构介绍

netty的架构图：

 

 咱们能够看到主要有三大部分组成：Core、Transport Services和Protocol Support。

2.1 Core

Core封装了底层通讯接口并提供了一个抽象的可扩展的事件模型。

2.1.1 Zero-Copy-Capable Rich Byte Buffer

netty基于NIO，可是它并无使用NIO的ByteBuffer，而是使用了本身定义的Buffer： ChannelBuffer。这是Netty用来表示二进制或文本消息的最基本的数据结构。 ChannelBuffer类型的设计从底层解决了ByteBuffer的问题，并可以知足平常网络应用开发。它相比ByteBuffer有着明显的优点，主要体如今：

• 容许自定义缓冲类型
• 基于内置复合缓冲类型实现透明的零拷贝
• 提供开箱的动态缓冲类型，容量能够根据须要扩充，这点跟StringBuffer很相似
• 再也不须要调用flip（）方法
• 一般会比ByteBuffer更快

 至于每一点的详细介绍，请参考官方文档： http://docs.jboss.org/netty/3.2/api/org/jboss/netty/buffer/package-summary.html#package_description

2.1.2 Universal Communication API

传统的Java I/O API在应对不一样的传输协议时须要使用不一样的类型和方法。例如，java.net.Socket 和 java.net.DatagramSocket它们并不具备相同的超类型，所以，这就须要使用不一样的调用方式执行socket操做。

这种模式上的不匹配使得在更换一个网络应用的传输协议时变得繁杂和困难。因为（Java I/O API）缺少协议间的移植性，当你试图在不修改网络传输层的前提下增长多种协议的支持，这时便会产生问题。而且理论上讲，多种应用层协议可运行在多种传输 层协议之上例如TCP/IP,UDP/IP,SCTP和串口通讯。
让这种状况变得更糟的是，Java新的I/O（NIO）API与原有的阻塞式的I/O（OIO）API并不兼容，NIO.2(AIO)也是如此。因为全部的API不管是在其设计上仍是性能上的特性都与彼此不一样，在进入开发阶段，你经常会被迫的选择一种你须要的API。
例如，在用户数较小的时候你可能会选择使用传统的OIO(Old I/O) API，毕竟与NIO相比使用OIO将更加容易一些。然而，当你的业务呈指数增加而且服务器须要同时处理成千上万的客户链接时你便会遇到问题。这种状况下 你可能会尝试使用NIO，可是复杂的NIO Selector编程接口又会耗费你大量时间并最终会阻碍你的快速开发。
Netty有一个叫作Channel的统一的异步I/O编程接口，这个编程接口抽象了全部点对点的通讯操做。也就是说，若是你的应用是基于Netty的某一种传输实现，那么一样的，你的应用也能够运行在Netty的另外一种传输实现上。Netty提供了几种拥有相同编程接口的基本传输实现：

• NIO-based TCP/IP transport (See org.jboss.netty.channel.socket.nio),
• OIO-based TCP/IP transport (See org.jboss.netty.channel.socket.oio),
• OIO-based UDP/IP transport, and
• Local transport (See org.jboss.netty.channel.local).

切换不一样的传输实现一般只需对代码进行几行的修改调整，例如选择一个不一样的ChannelFactory实现。
此外，你甚至能够利用那些尚未写入的新的传输协议，只需替换一些构造器的调用方法便可，例如串口通讯。并且因为核心API具备高度的可扩展性，你还能够完成本身的传输实现。

2.1.3 Extensible Event Model

Netty框架是基于事件驱动的，因此设计一个良好的具备很好的可扩展性的事件模型是很是必要的。

Netty具备定义良好的I/O事件模型。因为严格的层次结构区分了不一样的事件类型，所以Netty容许你在不破坏现有代码的状况下实现本身的事件类 型，这是与其余框架相比另外一个不一样的地方。不少NIO框架没有或者仅有有限的事件模型概念；在你试图添加一个新的事件类型的时候经常须要修改已有的代码， 或者根本就不容许你进行这种扩展。
在一个ChannelPipeline内部一个ChannelEvent被一组ChannelHandler处理。所以对于一个事件如何被处理以及管道内部处理器间的交互过程，你都将拥有绝对的控制力。

有关事件模型的更多信息，参考API文档中的ChannelEvent 和ChannelPipeline部分。

2.2 Transport Services 和 Protocol Support

上述所说起的核心组件已经足够实现各类类型的网络应用，除此以外，Netty也提供了一系列的高级组件来加速你的开发过程。

2.2.1. Codec框架

从业务逻辑代码中分离协议处理部分老是一个很不错的想法。然而若是一切从零开始便会遭遇 到实现上的复杂性。你不得不处理分段的消息。一些协议是多层的（例如构建在其余低层协议之上的协议）。一些协议过于复杂以至难以在一台主机（single state machine）上实现。

所以，一个好的网络应用框架应该提供一种可扩展，可重用，可单元测试而且是多层的codec框架，为用户提供易维护的codec代码。
Netty提供了一组构建在其核心模块之上的codec实现，这些简单的或者高级的codec实现帮你解决了大部分在你进行协议处理开发过程会遇到的问题，不管这些协议是简单的仍是复杂的，二进制的或是简单文本的。

2.2.2. SSL / TLS 支持

不一样于传统阻塞式的I/O实现，在NIO模式下支持SSL功能是一个艰难的工做。你不能只是简单的包装一下流数据并进行加密或解密工做，你不得不借助于 javax.net.ssl.SSLEngine，SSLEngine是一个有状态的实现，其复杂性不亚于SSL自身。你必须管理全部可能的状态，例如密 码套件，密钥协商（或从新协商），证书交换以及认证等。此外，与一般指望状况相反的是SSLEngine甚至不是一个绝对的线程安全实现。
在Netty内部，SslHandler 封装了全部艰难的细节以及使用SSLEngine可能带来的陷阱。你所作的仅是配置并将该SslHandler插入到你的ChannelPipeline中。一样Netty也容许你实现像StartTlS 那样所拥有的高级特性，这很容易。

2.2.3.  HTTP实现

HTTP无疑是互联网上最受欢迎的协议，而且已经有了一些例如Servlet容器这样的HTTP实现。所以，为何Netty还要在其核心模块之上构建一套HTTP实现？
与现有的HTTP实现相比Netty的HTTP实现是至关不同凡响的。在HTTP消息的低层交互过程当中你将拥有绝对的控制力。这是由于Netty的 HTTP实现只是一些HTTP codec和HTTP消息类的简单组合，这里不存在任何限制——例如那种被迫选择的线程模型。你能够为所欲为的编写那种能够彻底按照你指望的工做方式工做 的客户端或服务器端代码。这包括线程模型，链接生命期，快编码，以及全部HTTP协议容许你作的，全部的一切，你都将拥有绝对的控制力。
因为这种高度可定制化的特性，你能够开发一个很是高效的HTTP服务器，例如：

•  要求持久化连接以及服务器端推送技术的聊天服务（e.g. Comet ）
•  须要保持连接直至整个文件下载完成的媒体流服务（e.g. 2小时长的电影）
•  须要上传大文件而且没有内存压力的文件服务（e.g. 上传1GB文件的请求）
•  支持大规模mash-up应用以及数以万计链接的第三方web services异步处理平台

2.2.4. Google Protocol Buffer 整合

Google Protocol Buffers 是快速实现一个高效的二进制协议的理想方案。经过使用 ProtobufEncoder 和ProtobufDecoder，你能够把Google Protocol Buffers 编译器（protoc）生成的消息类放入到Netty的codec实现中。请参考官方示例中的“LocalTime”示例，这个例子也同时显示出开发一个由简单协议定义的客户及服务端是多么的容易。

2.3. 总述

在这一章节，咱们从功能特性的角度回顾了Netty的总体架构。Netty有一个简单却不失强大的架构。这个架构由三部分组成——缓冲（buffer）， 通道（channel），事件模型（event model）——全部的高级特性都构建在这三个核心组件之上。一旦你理解了它们之间的工做原理，你便不难理解在本章简要说起的更多高级特性。

 

参考： http://blog.sina.com.cn/s/blog_3fe961ae01011oob.html