Netty实战八之引导

通过前面的学习，我们可能要考虑一个问题：如何将这些部分组织起来，成为一个可实际运行的应用程序呢？

答案是引导。简单来说，引导一个应用程序是指对它进行配置，并使它运行起来的过程——尽管该过程的具体细节可能并不如它定义那样简单，尤其是对于一个网络应用程序来说。

引导是我们一直以来都在组装的完整拼图中缺失的那一块。当你把它放到正确的位置上时，你的Netty应用程序就完整了。

1、Bootstarp类

引导类的层次结构包括一个抽象的父类和两个具体的引导子类，如下图所示。

相对于将具体的引导类分别看作用于服务器和客户端的引导来说，记住它们的本意是用来支撑不同的应用程序的功能的将有所裨益。也就是说，服务器致力于使用一个父Channel来接受来自客户端的连接、并创建子Channel以用于它们之间的通信；而客户端将最可能只需要一个单独的、没有父Channel的Channel来用于所有的网络交互（这也适用于无连接的传输协议，如UDP，因为它们并不是每个连接都需要一个单独的Channel）

两种应用程序类型之间通用的引导步骤由AbstractBootstrap处理，而特定于客户端或者服务器的引导步骤则分别由Bootstrap或ServerBootstrap处理。

为什么引导类是Cloneable的？

你有时可能会需要创建多个具有类似配置或者完全相同配置的Channel。为了支持这种模式而又不需要为每个Channel都创建并配置一个新的引导类实例，AbstractBootstrap被标记为了Cloneable。在一个已经配置完成的引导类实例上调用clone（）方法将返回另一个可以立即使用的引导类实例。

注意，这种方式只会创建引导类实例的EventLoopGroup的一个浅拷贝，所以，后者将在所有克隆的Channel实例之间共享。这是可以接受的，因为通常这些克隆的Channel的生命周期都很短暂，一个典型的场景是——创建一个Channel以进行一次HTTP请求。

AbstractBootstrap类的完整声明是：

public abstract class AbstractBootstrap ,C extends Channel>

在这个签名中，子类型B是其父类型的一个类型参数，因此可以返回到运行时实例的引用以支持方法的链式调用。

其子类的声明如下：

public class Bootstrap extends AbstractBootstrap

和

public class ServerBootstrap extends AbstractBootstrap

2、引导客户端和无连接协议

Bootstrap类被用于客户端或者使用了无连接协议的应用程序中。Bootstrap类负责为客户端和使用无连接协议的应用程序创建Channel，如下图所示。

以下代码引导了一个使用NIO TCP传输的客户端

这个示例使用了前面提到的流式语法，这些方法将通过每次方法调用所返回的对Bootstrap实例的引用链接在一起。

3、Channel和EventLoopGroup的兼容性

这段代码将会导致IllegalStateException，因为它混用了不兼容的传输。

关于IllegalStateException的更多讨论

在引导过程中，在调用bind（）或者connect（）方法之前，必须调用以下方法来设置所需的组件：

——group（）

——channel（）或者channelFactory（）

——handler（）

如果不这样做，则将会导致IllegalStateException。对handler（）方法的调用尤其重要，因为它需要配置好ChannelPipeline。

4、引导服务器

具体来说，ServerChannel的实现负责创建子Channel，这些子Channel代表了已被接受的连接。因此，负责引导ServerChannel的ServerBootstrap提供了这些方法，以简化将设置应用到已被接受的子Channel的ChannelConfig的任务。

下图展示了ServerBootstrap在bind（）方法被调用时创建了一个ServerChannel，并且该ServerChannel管理多个子Channel。

以下代码实现了服务器的引导过程。

5、从Channel引导客户端

假设你的服务器正在处理一个客户端的请求，这个请求需要它充当第三方系统的客户端。当一个应用程序必须要和组织现有的系统集成时，就可能发生这种情况。在这种情况下，将需要从已经被接受的子Channel中引导一个客户端Channel。

通过将已被接受的子Channel的EventLoop传递给Bootstrap的group（）方法来共享该EventLoop。因为分配给EventLoop的所有Channel都使用同一个线程，所以这避免了额外的线程创建，以及前面所提到的相关的上下文切换。这个共享的解决方案如下图所示。

实现EventLoop共享涉及通过调用group（）方法来设置EventLoop，如下代码所示。

以上示例都反应了编写Netty应用程序的一个一般准则：尽可能地重用EventLoop，以减少线程创建带来的开销。

6、在引导过程中添加多个ChannelHandler

在所有我们展示过的代码示例中，我们都在引导的过程中调用了handler（）或者childHandler（）方法来添加单个的ChannelHandler。这对于简单的应用程序来说可能已经足够了，但是它不能满足更加复杂的需求。例如，一个必须要支持多种协议的应用程序将会有很多的ChannelHandler，而不会是一个庞大而又笨重的类。

正如你经常看到的一样，你可以根据需要，通过在ChannelPipeline中将它们链接在一起来部署尽可能多的ChannelHandler。但是，如果在引导的过程中你只能设置一个ChannelHandler，那么你应该怎么做到这一点呢？

正是针对于这个用例，Netty提供了一个特殊的ChannelInboundHandlerAdapter子类：

public abstract class ChannelInitializer extends ChannInboundHandlerAdapter

它定义了下面的方法：

protected abstract void initChannel(C ch) throws Exception

这个方法提供了一种将多个ChannelHandler添加到一个ChannelPipeline中的简便方法。你只需要简单地向Bootstrap或ServerBootstrap的实例提供你的ChannelInitializer实现即可，并且一旦Channel被注册到了它的EventLoop之后，就会调用你的initChannel（）版本。在该方法返回之后，ChannelInitializer的实例将会从ChannelPipeline中移除它自己。

以下代码定义了ChannelInitializer类，并通过ServerBootstrap的childHandler（）方法注册了它。

7、使用Netty的ChannelOption和属性

在每个Channel创建时都手动配置它可能会变得相当乏味。幸运的是，你不必这样做。相反，你可以使用option（）方法来将ChannelOption应用到引导。你所提供的值将会被自动应用到引导所创建的所有Channel。可用的ChannelOption包括了底层连接的详细信息，如keep-aliva或者超时属性以及缓冲区设置。

Netty应用程序通常与组织的专有软件集成在一起，而像Channel这样的组件可能甚至会在正常的Netty生命周期之外被使用。在某些常用的属性和数据不可用时，Netty提供了AttributeMap抽象（一个由Channel和引导类提供的集合）以及AttributeKey（一个用于插入和获取属性值的泛型类）。使用这些工具，便可以安全地将任何类型的数据项与客户端和服务器Channel（包含ServerChannel的子Channel）相关联了。

例如，考虑一个用于跟踪用户和Channel之间的关系的服务器应用程序。这可以通过将用户的ID存储为Channel的一个属性来完成。类似的技术可以被用来基于用户的ID将消息路由给用户，或者关闭活动较少的Channel。

以下代码展示了可以如何使用ChannelOption来配置Channel，以及如果使用属性来存储整型值。

8、引导DatagramChannel

前面的引导代码示例使用的都是基于TCP协议的SocketChannel，但是Bootstrap类也可以被用于无连接的协议。为此，Netty提供了各种DatagramChannel的实现。唯一区别就是，不再调用connect（）方法，而是只调用bind（），如下代码所示。

9、关闭

引导使你的应用程序启动并且运行起来，但是迟早你都需要优雅地将它关闭。当然你也可以让JVM在退出时处理好一切，但是这不符合优雅的定义，优雅是指干净地释放资源。关闭Netty应用程序并没有太多的魔法，但是还是有些事情需要记在心上。

最重要的是，你需要关闭EventLoopGroup，它将处理任何挂起的事件和任务，并且随后释放所有活动的线程。这就是调用EventLoopGroup.shutdownGracefully()方法的作用。这个方法调用将会返回一个Future，这个Future将在关闭完成时接收到通知。需要注意的是，所返回的Future注册一个监听器以在关闭完成时获得通知。

或者，你也可以调用EventLoopGroup.shutdownGracefully（）方法之前，显式地在所有活动的Channel上调用Channel.close（）方法。但是在任何情况下，都请记得关闭EventLoopGroup本身。