Netty实战三之Netty的组件和设计

有关Netty，咱们能够从两个视角来讨论Netty：类库的视角以及框架的视角，对于使用Netty编写高效的、可重用的和可维护的代码来讲，二者缺一不可。

Netty解决了两个响应的关注领域，能够大体标志为技术的和体系结构的。

它基于Java NIO的异步和事件驱动的实现，保证了高负载下应用程序性能的最大化和可伸缩性。其次，Netty也包含了一组设计模式，将应用程序逻辑从网络层解耦，简化开发过程，同时也最大限度地提升了可测试性、模块化以及代码的可重用性。

Netty网络抽象的表明：

——Channel：Socket

——EventLoop：控制流、多线程处理、并发

——ChannelFuture：异步通知

一、Channel接口

Netty的Channel接口所提供的的API，大大下降了直接使用Socket类的复杂性，此外，Channel也拥有许多预约义的、专门化实现的普遍类层次结构的根。

——EmbeddedChannel

——LocalServerChannel

——NioDatagramChannel

——NioSctpChannel

——NioSocketChannel

二、EventLoop接口

EventLoop定义了Netty的核心抽象，用于处理链接的生命周期中所发生的事件。图3-1在高层次上说明了Channel、EventLoop、Thread以及EventLoopGroup之间的关系。

——EventLoopGroup包含一个或者多个EventLoop

——一个EventLoop在它的生命周期内只和一个Thread绑定

——全部由EventLoop处理的I/O事件都将在它专有的Thread上被处理

——一个Channel在它的生命周期内只注册于一个EventLoop

——一个EventLoop可能会被分配给一个或多个Channel

注意，在这种设计中，一个给定Channel的I/O操做都是由相同的Thread执行的，实际上消除了对于同步的须要。

三、ChannelFuture接口

Netty中全部的I/O操做都是异步的，由于一个操做可能不会当即返回，因此咱们须要一种用于在以后的某个时间点肯定其结果的方法，为此，Netty提供了ChannelFuture接口，其addListener（）方法注册了一个ChannelFutureListener，以便在某个操做完成时（不管是否成功）获得通知。

关于ChannelFuture的更多讨论——能够将ChannelFuture看做是未来要执行的结果的占位符，它究竟何时被执行则可能取决于若干的因素，所以不可能准确地预测，可是能够确定的是它将会被执行，此外，全部属于同一个Channel的操做都被保证其将以它们被调用的顺序被执行。

四、ChannelHandler接口

Netty的主要组件是ChannelHandler，它充当了全部处理入站和出站数据的应用程序逻辑的容器。由于ChannelHandler的方法是由网络事件触发的。事实上，ChannelHandler可专门用于几乎任何类型的动做，例如将数据从一种格式转换为另外一种格式，或者处理转换过程当中所抛出的异常。

例如，ChannelInboundHandler 是一个你将会常常实现的子接口，这种类型的ChannelHandler接收入站事件和数据，这些数据随后将会被你的应用程序的业务逻辑所处理。当你要给链接的客户端发送响应时，也能够从ChannelInboundHandler冲刷数据。你的应用程序的业务逻辑一般驻留在一个或者多个ChannelInboundHandler中。

五、ChannelPipeline接口

ChannelPipeline为ChannelHandler链提供了容器，并定义了用于在该链上传播入站和出站事件流的API。当Channel被建立时，它会被自动地分配到它专属的ChannelPipeline。

——一个ChannelInitializer的实现被注册到了ServerBootstrap中； ——当ChannelInitializer.initChannel()方法被调用时，ChannelInitializer将在ChannelPipeline中安装一组自定义的ChannelHandler； ——ChannelInitializer将它本身从ChannelPipeline中移除；

ChannelHandler是专为支持普遍的用途而设计的，能够将它看做是处理往来ChannelPipeline事件（包括数据）的任何代码的通用容器。图2-3说明了这一点，其展现了从ChannelHandler派生的ChannelInboundHandler和ChannelOutboundHandler接口。

使得事件流经ChannelPipeline是ChannelHandler的工做，它们是在应用程序的初始化或者引导阶段被安装的，这些对象接收事件、执行它们所实现的处理逻辑，并将数据传递给链中的下一个ChannelHandler。它们的执行顺序是由它们被添加的顺序所决定的。ChannelPipeline就是ChannelHandler的编排顺序。

图3-3说明了一个Netty应用程序中入站和出站数据流之间的区别。从一个客户端应用程序的角度来看，若是事件的运动方向是从客户端到服务器端，那么咱们称这些事件为出站，反之则称为入站。

由上图可看出入站和出站ChannelHandler能够被安装到同一个ChannelPipeline中，事件的读取将从ChannelPipeline的头部开始流动，并被传递给第一个ChannelInboundHandler，这个ChannelHandler不必定会实际修改数据，具体取决于它的具体功能，在以后，数据将会传递给链中的下一个ChannelInboundHandler，最终，数据将会到达ChannelPipeline的尾端，即全部处理结束。

出站事件也相同的流程，在到达链的头部以后，出站数据将会到达网络传输层，这里显示为Socket，一般状况下，这将触发一个写操做。

关于入站和出站ChannelHandler的更多讨论

经过使用做为参数传递到每一个方法的ChannelHandlerContext，事件能够被传递给当前ChannelHandler链中的下一个ChannelHandler。由于你有时会忽略那些不感兴趣的事件，因此Netty提供了抽象基类ChannelInboundHandlerAdapter和ChannelOutboundHandlerAdapter。经过调用ChannelHandlerContext上的对应方法，每一个都提供了简单地将事件传递给下一个ChannelHandler的方法的实现，随后，你能够经过重写你所感兴趣的那些方法来扩展这些类。

虽然ChannelInboundHandler和ChannelOutboundHandler都扩展自ChannelHandler，可是Netty能区分ChannelInboundHandler实现和ChannelOutboundHandler实现，并确保数据只会在具备相同定向类型的两个ChannelHandler之间传递。

当ChannelHandler被添加到ChannelPipeline时，它将被分配一个ChannelHandlerContext，其表明了ChannelHandler和ChannelPipeline之间的绑定。虽然这个对象能够被用于获取底层的Channel，可是它主要仍是被用于写出站数据。

在Netty中，有两种发送消息的方式。你能够直接写到Channel中，也能够写到ChannelHandler相关联的ChannelHandlerContext对象中，前一种方式将会致使消息从ChannelPipeline的尾端开始流动，然后者将致使消息从ChannelPipeline中的下一个ChannelHandler开始流动。

六、深刻了解ChannelHandler

有许多不一样类型的ChannelHandler，它们各自的功能主要取决于它们的超类。Netty以适配器类的形式提供了大量默认的ChannelHandler实现，其旨在简化应用程序处理逻辑的开发过程，ChannelPipeline中的每一个ChannelHandler将负责把事件转发到链中的下一个ChannelHandler，这些适配器将自动执行这个操做，因此你能够只重写那些你想要特殊处理的方法和事件。

为何须要适配器类

有些适配器类能够将编写自定义的ChannelHandler所须要的努力降到最低限度，由于他们提供了定义在对应接口中的全部方法的默认实现。

——ChannelHandlerAdapter

——ChannelInboundHandlerAdapter

——ChannelOutboundHandlerAdapter

——ChannelDuplexHandler

七、编码器和解码器

当你经过Netty发送或者接收一个消息的时候，就将会发生一次数据转换。入站就解码为Java对象，出站就编码为字节。（网络数据老是一系列的字节）

全部由Netty提供的编码器、解码器适配器类都实现了ChannelOutboundHandler或者ChannelInboundHandler接口。

你将会发现对于入站数据，channelRead方法、事件已经被重写了，对于每一个从入站Channel读取消息，这个方法都将会被调用，随后，它将调用由预置解码器所提供的的decode（）方法，并将已解码的字节转发给ChannelPipeline中的下一个ChannelInboundHandler。

出站消息的模式是相反方向的：编码器将消息转换为字节，并将它们转发给下一个ChannelOutboundHandler。

八、抽象类SimpleChannelInboundHandler

最多见的状况是，你的应用程序会利用一个ChannelHandler来接收解码消息，并对该数据应用业务逻辑。要建立一个这样的ChannelHandler，你只须要扩展基类SimpleChannelInboundHandler，其中T是你要处理的消息的Java类型，在这个ChannelHandler中，你将须要重写基类的一个或者多个方法，而且获取一个到ChannelHandlerContext的引用，这个引用将做为输入参数传递给ChannelHandler的全部方法。

在这种类型的ChannelHandler中，最重要的方法是channelRead0（ChannelHandlerContext，T）。除了要求不要阻塞当前的I/O线程以外，其具体实现彻底取决于你。

九、引导

Netty的引导类为应用程序的网络层配置提供了容器，这涉及将一个进程绑定到某个指定的端口，或者将一个进程链接到另外一个运行在某个指定主机的指定端口上的进程。

“服务器”和“客户端”实际上表示了不一样的网络行为：是监听传入的链接仍是创建到一个或者多个进程的链接。

面向链接的协议：请记住，严格来讲，“链接”这个属于仅适用于面向链接的协议，如TCP、其保证了两个链接端点之间消息的有序传递。

所以，有两种类型的引导：一种用于客户端（简单称为Bootstrap），而另外一种（ServerBootstrap）用于服务器。不管你的应用程序使用哪些协议或者处理哪一种类型的数据，惟一决定它使用哪一种引导类的是它是做为一个客户端仍是做为一个服务器。 

这两种类型的引导类之间的第一个区别已经讨论过了：ServerBootstrap将绑定到一个端口，由于服务器必需要监听链接，而Bootstrap则由想要链接到远程节点的客户端应用程序所使用的。

第二个区别可能更加明显，引导一个客户端只须要一个EventLoopGroup，可是一个ServerBootstrap则须要两个（也能够是同一个实例），为何呢？

由于服务器须要两组不一样的Channel。第一组将只包含一个ServerChannel，表明服务器自身的已绑定到某个本地端口的正在监听的套接字。而第二组将包含全部已建立的用来处理传入客户端链接（对于每一个服务器已经接受的链接都有一个）的Channel。 

与ServerChannel相关联的EventLoopGroup将分配一个负责为传入链接请求建立Channel的EventLoop。一旦链接被接收，第二个EventLoopGroup就会给它的Channel分配一个EventLoop。