Netty 5.0源码分析之综述

1. 前言

本系列主要是用于梳理Netty的架构流程,深入设计细节,重点关注Netty是如何实现它所声称的特性。
(ps:本人水平有限,如有错误,请不吝指教 : ))

2. 什么是Netty

Netty 是一个异步事件驱动的网络编程框架和工具,使用Netty 可以快速开发出可维护的,高性能、高扩展能力的协议服务及其客户端应用。Netty极大地简化并优化网络编程,例如TCP和UDP套接字服务器。

Netty吸收了多种协议的实现经验,包括FTP、SMPT、HTTP、各种二进制和文本协议,成功找到一种开发应用程序的方法,保证易于开发、性能、稳定性、扩展性等特性。

3. Netty总体架构

Netty架构图

  • 为不同的传输类型定义统一的API,适用于阻塞和非阻塞套接字;
  • 基于一个灵活、可扩展的事件模型,允许关注明确的任务分工;
  • 高度可定制的线程模型,适用于单线程、一个或多个像SEDA这样的线程池;
  • 真正无连接的数据报套接字支持(版本3.1+);
  • 完整的 SSL / TLS 和 StartTLS 的支持;
  • HTTP、WebSocket支持;
  • Google Protocol Buffer支持。

4. 关注点

本系列文章主要关注Core部分的实现:

  • Extensible Event Model(可扩展的事件模型);
  • Universal Communication API(统一的通信API);
  • Zero-Copy-Capable Rich Byte Buffer(零拷贝的Buffer)。

4.1 Extensible Event Model

Netty具有定义良好的I/O事件模型。由于严格的层次结构区分了不同的事件类型,因此Netty允许你在不破坏现有代码的情况下实现自己的事件类型,这是与其他框架相比另一个不同的地方。

4.2 Universal Communication API

Java的Old I/O和New I/O,使用了互不兼容的API,而Netty则提供了统一的API封装这两种I/O模型。

4.3 Zero-Copy-Capable Rich Byte Buffer

在数据传输时,最终处理的数据会需要对单个传输层的报文,进行组合或者拆分。NIO原生的ByteBuffer要做到这件事,需要对ByteBuffer内容进行拷贝,产生新的ByteBuffer,而Netty通过提供Composite(组合)和Slice(切分)两种Buffer来实现零拷贝。

5. Netty源码结构

为了理解Netty的异步事件驱动机制,需要研究Netty的源码实现。其包结构如下所示:

io.netty
- bootstrap 配置启动服务相关的类
- buffer 缓冲区相关的类
- channel 处理连接的核心类
- handler 实现协议编解码的类
- util 工具类

接下来,我们就逐一分析这些包结构中的实现。


(END)

转载于:https://www.cnblogs.com/vectoryao/p/6273234.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Netty5.0 架构剖析源码解读 作者:李林锋 版权所有 email neu_lilinfeng@ © Netty5.0 架构剖析源码解读1 1. 概述2 1.1. JAVA 的IO演进2 1.1.1. 传统BIO通信的弊端2 1.1.2. Linux 的网络IO模型简介4 1.1.3. IO复用技术介绍7 1.1.4. JAVA的异步IO8 1.1.5. 业界主流的NIO框架介绍10 2.NIO入门10 2.1. NIO服务端10 2.2. NIO客户端13 3.Netty源码分析16 3.1. 服务端创建16 3.1.1. 服务端启动辅助类ServerBootstrap16 3.1.2. NioServerSocketChannel 的注册21 3.1.3. 新的客户端接入25 3.2. 客户端创建28 3.2.1. 客户端连接辅助类Bootstrap28 3.2.2. 服务端返回ACK应答,客户端连接成功32 3.3. 读操作33 3.3.1. 异步读取消息33 3.4. 写操作39 3.4.1. 异步消息发送39 3.4.2. Flush操作42 4.Netty架构50 4.1. 逻辑架构50 5. 附录51 5.1. 作者简介51 5.2. 使用声明51 1. 概述 1.1.JAVA 的IO演进 1.1.1. 传统BIO通信的弊端 在JDK 1.4推出JAVANIO1.0之前,基于JAVA 的所有Socket通信都采用 BIO 了同步阻塞模式( ),这种一请求一应答的通信模型简化了上层的应用开发, 但是在可靠性和性能方面存在巨大的弊端。所以,在很长一段时间,大型的应 C C++ 用服务器都采用 或者 开发。当并发访问量增大、响应时间延迟变大后, 采用JAVABIO作为服务端的软件只有通过硬件不断的扩容来满足访问量的激 增,它大大增加了企业的成本,随着集群的膨胀,系统的可维护性也面临巨大 的挑战,解决这个问题已经刻不容缓。 首先,我们通过下面这幅图来看下采用BIO 的服务端通信模型:采用BIO 通信模型的 1connect NewThread1 WebBrowse 2connect 2handle(Req) WebBrowse 3connect Acceptor NewThread2 WebBrowse WebBrowse 4connect NewThread3 3sendResponsetopeer NewThread4 图1.1.1-1 BIO通信模型图 服务端,通常由一个独立的Accepto 线程负责监听客户端的连接,接收到客户 端连接之后为客户端连接创建一个新的线程处理请求消息
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值