Netty 和 Mina 是 Java 世界非常知名的通讯框架。它们都出自同一个作者,Mina 诞生略早,属于 Apache 基金会,而 Netty 开始在 Jboss 名下,后来出来自立门户 netty.io。关于 Mina 已有 @FrankHui 的 Mina 系列文章,我正好最近也要做一些网络方面的开发,就研究一下 Netty 的源码,顺便分享出来了。

Netty 目前有两个分支:4.x 和 3.x。4.0 分支重写了很多东西,并对项目进行了分包,规模比较庞大,入手会困难一些,而 3.x 版本则已经被广泛使用。本系列文章针对 netty 3.7.0 final。3.x 和 4.0 的区别可以参考这篇文章:http://www.oschina.net/translate/netty-4-0-new-and-noteworthy?print

起:Netty 是什么

大概用 Netty 的,无论新手还是老手,都知道它是一个 “网络通讯框架”。所谓框架,基本上都是一个作用:基于底层 API,提供更便捷的编程模型。那么 "通讯框架" 到底做了什么事情呢?回答这个问题并不太容易,我们不妨反过来看看,不使用 netty,直接基于 NIO 编写网络程序,你需要做什么 (以 Server 端 TCP 连接为例,这里我们使用 Reactor 模型):

  1. 监听端口,建立 Socket 连接
  2. 建立线程,处理内容
    1. 读取 Socket 内容,并对协议进行解析
    2. 进行逻辑处理
    3. 回写响应内容
    4. 如果是多次交互的应用 (SMTP、FTP),则需要保持连接多进行几次交互
  3. 关闭连接

建立线程是一个比较耗时的操作,同时维护线程本身也有一些开销,所以我们会需要多线程机制,幸好 JDK 已经有很方便的多线程框架了,这里我们不需要花很多心思。

此外,因为 TCP 连接的特性,我们还要使用连接池来进行管理:

  1. 建立 TCP 连接是比较耗时的操作,对于频繁的通讯,保持连接效果更好
  2. 对于并发请求,可能需要建立多个连接
  3. 维护多个连接后,每次通讯,需要选择某一可用连接
  4. 连接超时和关闭机制

想想就觉得很复杂了!实际上,基于 NIO 直接实现这部分东西,即使是老手也容易出现错误,而使用 Netty 之后,你只需要关注逻辑处理部分就可以了。

承:体验 Netty

这里我们引用 Netty 的 example 包里的一个例子,一个简单的 EchoServer,它接受客户端输入,并将输入原样返回。其主要代码如下:

public void run() {
    // Configure the server.
    ServerBootstrap bootstrap = new ServerBootstrap(
            new NioServerSocketChannelFactory(
                    Executors.newCachedThreadPool(),
                    Executors.newCachedThreadPool()));

    // Set up the pipeline factory.
    bootstrap.setPipelineFactory(new ChannelPipelineFactory() {
        public ChannelPipeline getPipeline() throws Exception {
            return Channels.pipeline(new EchoServerHandler());
        }
    });

    // Bind and start to accept incoming connections.
    bootstrap.bind(new InetSocketAddress(port));

这里 EchoServerHandler是其业务逻辑的实现者,大致代码如下:

public class EchoServerHandler extends SimpleChannelUpstreamHandler {

    @Override
    public void messageReceived(
            ChannelHandlerContext ctx, MessageEvent e) {
        // Send back the received message to the remote peer.
        e.getChannel().write(e.getMessage());
    }

还是挺简单的,不是吗?

转:Netty 背后的事件驱动机制

完成了以上一段代码,我们算是与 Netty 进行了第一次亲密接触。如果想深入学习呢?

首先推荐 Netty 的官方 User Guide:http://netty.io/3.7/guide/。其次,阅读源码是了解一个开源工具非常好的手段,但是 Java 世界的框架大多追求大而全,功能完备,如果逐个阅读,难免迷失方向,Netty 也并不例外。相反,抓住几个重点对象,理解其领域概念及设计思想,从而理清其脉络,相当于打通了任督二脉,以后的阅读就不再困难了。

理解 Netty 的关键点在哪呢?我觉得,除了 NIO 的相关知识,另一个就是事件驱动的设计思想。什么叫事件驱动?我们回头看看 EchoServerHandler的代码,其中的参数:public void messageReceived(ChannelHandlerContext ctx, MessageEvent e),MessageEvent 就是一个事件。这个事件携带了一些信息,例如这里 e.getMessage()就是消息的内容,而 EchoServerHandler则描述了处理这种事件的方式。一旦某个事件触发,相应的 Handler 则会被调用,并进行处理。这种事件机制在 UI 编程里广泛应用,而 Netty 则将其应用到了网络编程领域。

在 Netty 里,所有事件都来自 ChannelEvent接口,这些事件涵盖监听端口、建立连接、读写数据等网络通讯的各个阶段。而事件的处理者就是 ChannelHandler,这样,不但是业务逻辑,连网络通讯流程中底层的处理,都可以通过实现 ChannelHandler来完成了。事实上,Netty 内部的连接处理、协议编解码、超时等机制,都是通过 handler 完成的。当博主弄明白其中的奥妙时,不得不佩服这种设计!

下图描述了 Netty 进行事件处理的流程。Channel是连接的通道,是 ChannelEvent 的产生者,而 ChannelPipelin可以理解为 ChannelHandler 的集合。17403218rb190591.png

合:开启 Netty 源码之门

理解了 Netty 的事件驱动机制,我们现在可以来研究 Netty 的各个模块了。Netty 的包结构如下:

org
└── jboss
    └── netty
		├── bootstrap 配置并启动服务的类
		├── buffer 缓冲相关类,对NIO Buffer做了一些封装
		├── channel 核心部分,处理连接
		├── container 连接其他容器的代码
		├── example 使用示例
		├── handler 基于handler的扩展部分,实现协议编解码等附加功能
		├── logging 日志
		└── util 工具类

在这里面,channelhandler两部分比较复杂。我们不妨与 Netty 官方的结构图对照一下,来了解其功能。

225721R0w2190591.png

具体的解释可以看这里:http://netty.io/3.7/guide/#architecture。图中可以看到,除了之前说到的事件驱动机制之外,Netty 的核心功能还包括两部分:

  • Zero-Copy-Capable Rich Byte Buffer
    零拷贝的 Buffer。为什么叫零拷贝?因为在数据传输时,最终处理的数据会需要对单个传输层的报文,进行组合或者拆分。NIO 原生的 ByteBuffer 要做到这件事,需要对 ByteBuffer 内容进行拷贝,产生新的 ByteBuffer,而 Netty 通过提供 Composite(组合) 和 Slice(切分) 两种 Buffer 来实现零拷贝。这部分代码在 org.jboss.netty.buffer包中。
  • Universal Communication API
    统一的通讯 API。因为 Java 的 Old I/O 和 New I/O,使用了互不兼容的 API,而 Netty 则提供了统一的 API(org.jboss.netty.channel.Channel) 来封装这两种 I/O 模型。这部分代码在 org.jboss.netty.channel包中。

此外,Protocol Support 功能通过 handler 机制实现。

接下来的文章,我们会根据模块,详细的对 Netty 源码进行分析。

转自: https://my.oschina.net/flashsword/blog/162936


标题:Netty 那点事(一)概述
作者:sharkshen@outlook.com
地址:https://linkjb.com/articles/2020/07/29/1596016696800.html