ChannelPipeline
-
基于Netty的网路应用程序中根据业务需求会使用Netty已经提供的Channelhandler
或者自行开发ChannelHandler，这些ChannelHandler都放在ChannelPipeline中统一
管理，事件就会在ChannelPipeline中流动，并被其中一个或者多个ChannelHandler处理
-
ChannelPipeline提供了ChannelHandler链的容器，并定义了在该链上传播入站(也就是从网络到业务处理)
和出站(也就是从业务处理到网络)，各种事件流的API，代码中的ChannelHandler都是放在ChannelPipeline中的。 -
使得事件流经ChannelPipeline是ChannelHandler的工作，它们是在应用程序的初始化或者引导阶段被安装的。
这些ChannelHandler对象接收事件、执行它们所实现的处理逻辑，并将数据传递给链中的下一个ChannelHandler,
而且Channelhandler对象也完全可以拦截事件不让事件继续传递。它们的执行顺序是由它们被添加的顺序所决定的。
- ChannelPipeline上的方法。
既然ChannelPipeline以双向链表的形式进行维护管理Handler，自然也提供了对应的方法在ChannelPipeline中
增加或者删除、替换handler.
addFist、addBefore、addAfter、addLast将一个ChannelHandler添加到ChannelPipeline中。
remove将一个ChannelHandler从ChannelPipeline中移除
replace将ChannelPipeline中的一个ChannelHandler替换为另一个ChannelHandler
get通过类型或者名称返回ChannelHandler
context返回和ChannelHandler绑定的ChannelHandlerContext
names返回ChannelPipeline中所有ChannelHandler的名称
ChannelPipeline的API公开了用于调用入站和出站操作的附加方法
ChannelHandler
- ChannelPipeline中的ChannelHandler.
入站和出站ChannelHandler被安装到同一个ChannelPipeline中，ChannelPipeline以双向链表的形式进行维护管理。如上图，在网络上传递的数据，要求加密，但是加密后密文比较大，需要压缩后再传输，而且按照业务要求，需要检查报文中携带的用户信息是否合法，于是图中实现了，解压(入)Handler、压缩(出)Handler、解密(入)Handler、加密(出)Handler
授权(入)Handler. - 如果一个消息或者任何其他入站事件被读取，那么它会从ChannelPipeline的头部开始流动，但是只被处理入站事件的Handler处理，也就是解压(入)Handler、解密(入)Handler、授权(入)Handler，最终，数据将会到达ChannelPipeline的尾端，届时，所有的处理就都结束了
- 数据的出站运动(即正在被写的数据)在概念上也是一样的。在这种情况下，数据将从链的尾端开始流动，但是制备处理出站的Handler处理，也就是加密(出)Handler、压缩(出)Handler，直到它到达链的头部为止。在这之后，出站数据将会到达网络传输层，也就是Socket
Handler可以放在解压(入)Handler和解密(入)Handler中间，也可以放在解密(入)Handler和授权之间
-
而同属一个方向的Handler则是有顺序的，因为上一个Handler处理的结果往往是下一个Handler的要求的输入。比如入站处理，对于收到的数据，只有先解压才能得到密文，才能解密，只有解密后才能拿到明文中的用户信息进行授权检查，所以解压-解密-授权这个，三个入站Handler的顺序就不能乱
