Netty有什么用？如何实现WebSocket聊天？

 

Netty 是一个Java 开源框架，提供异步的，时间驱动的网络应用程序框架和工具，用以快速开发高性能，高可靠性的网络服务器和客户端程序。

Netty是一个NIO客户端，服务端框架，允许快速简单的开发网络应用程序。例如：服务端和客户端之间的协议。

牛XX: 简化了网络编程规范

例如：TCP和UDP的Socket服务

 

通俗点理解：

Netty本身是用于快速构建服务端与客户端之间通信协议的框架。Netty在消息处理上使用责任链模式，用户可以轻松方便的对它进行扩展。官方也提供了大量的优秀的扩展。

Netty是一个NIO客户端服务器框架，可以快速，轻松地开发网络应用程序，如协议服务器和客户端。 它大大简化和简化了网络编程，如TCP和UDP套接字服务器。

“快速和容易”并不意味着结果应用程序将遇到可维护性或性能问题。 Netty已经仔细设计了从许多协议，如FTP，SMTP，HTTP和各种二进制和基于文本的遗留协议的实现获得的经验。 因此，Netty成功地找到了一种方法来实现易于开发，性能，稳定性和灵活性的应用程序。

 

Netty有什么用

API 使用简单，开发门槛低

功能强大，预置了多种编码解码功能，支持多种主流协议

定制能力强，可以通过ChannelHandler对通信框架进行灵活的扩展

性能高，通过与其他业界主流的NIO框架对比，Netty的综合性能最优

成熟，稳定，Netty修复了已经发现的所有JDK NIOBUG 业务开发人员不再为NIO的bug而烦恼

社区活跃。版本迭代周期短，发现的bug可以被及时修复，同时，更多的新功能会加入

经历了大规模的商业应用考验。质量得到验证。Netty在互联网，大数据，网络游戏，企业应用，电信软件等众多行业已经得到了成功商用，证明它已经完全能够满足不同行业的商业应用了

 

 小明的案例

随着移动互联网的爆发性增长，小明公司的电子商务系统访问量越来越大，由于现有系统是个单体的巨型应用，已经无法满足海量的并发请求，拆分势在必行。

在微服务的大潮之中， 架构师小明把系统拆分成了多个服务，根据需要部署在多个机器上，这些服务非常灵活，可以随着访问量弹性扩展。

世界上没有免费的午餐， 拆分成多个“微服务”以后虽然增加了弹性，但也带来了一个巨大的挑战：服务之间互相调用的开销。

比如说：原来用户下一个订单需要登录，浏览产品详情，加入购物车，支付，扣库存等一系列操作，在单体应用的时候它们都在一台机器的同一个进程中，说白了就是模块之间的函数调用，效率超级高。

现在好了，服务被安置到了不同的服务器上，一个订单流程，几乎每个操作都要越网络，都是远程过程调用(RPC)， 那执行时间、执行效率可远远比不上以前了。

 

远程过程调用的第一版实现使用了HTTP协议，也就是说各个服务对外提供HTTP接口。 小明发现，HTTP协议虽然简单明了，但是废话太多，仅仅是给服务器发个简单的消息都会附带一大堆无用信息：

GET /orders/1 HTTP/1.1                                                                  

Host: order.myshop.com

User-Agent: Mozilla/5.0 (Windows NT 6.1; )

Accept: text/html;

Accept-Language: en-US,en;

Accept-Encoding: gzip

Connectin: keep-alive

看看那User-Agent，Accept-Language ，这个协议明显是为浏览器而生的！但是我这里是程序之间的调用，用这个HTTP有点亏。

能不能自定义一个精简的协议？ 在这个协议中我只需要把要调用方法名和参数发给服务器即可，根本不用这么多乱七八糟的额外信息。

但是自定义协议客户端和服务器端就得直接使用“低级”的Socket了，尤其是服务器端，得能够处理高并发的访问请求才行。

小明复习了一下服务器端的socket编程，最早的Java是所谓的阻塞IO(Blocking IO)， 想处理多个socket的连接的话需要创建多个线程， 一个线程对应一个。

这种方式写起来倒是挺简单的，但是连接（socket）多了就受不了了，如果真的有成千上万个线程同时处理成千上万个socket，占用大量的空间不说，光是线程之间的切换就是一个巨大的开销。

 

更重要的是，虽然有大量的socket，但是真正需要处理的（可以读写数据的socket）却不多，大量的线程处于等待数据状态（这也是为什么叫做阻塞的原因），资源浪费得让人心疼。

后来Java为了解决这个问题，又搞了一个非阻塞IO(NIO：Non-Blocking IO，有人也叫做New IO)， 改变了一下思路：通过多路复用的方式让一个线程去处理多个Socket。

这样一来，只需要使用少量的线程就可以搞定多个socket了，线程只需要通过Selector去查一下它所管理的socket集合，哪个Socket的数据准备好了，就去处理哪个Socket，一点儿都不浪费。

小明先定义了一套精简的RPC的协议，里边规定了如何去调用一个服务，方法名和参数该如何传递，返回值用什么格式......等等。然后雄心勃勃地要把这个协议用Java NIO给实现了。

可是美好的理想很快被无情的现实给击碎， 小明努力了一周就意识到自己陷入了一个大坑之中，Java NIO虽然看起来简单，但是API还是太“低级”了，有太多的复杂性，没有强悍的、一流的编程能力根本无法驾驭，根本做不到高并发情况下的可靠和高效。

小明不死心，继续向领导要人要资源，一定要把这个坑给填上，挣扎了6个月以后，终于实现了一个自己的NIO框架，可以执行高并发的RPC调用了。

 

然后又是长达6个月的修修补补，小明经常半夜被叫醒：生产环境的RPC调用无法返回了！ 这样的Bug不知道改了多少个。

在那些不眠之夜中，小明经常仰天长叹：我用NIO做个高并发的RPC框架怎么这么难呐！

一年之后，自研的框架终于稳定，可是小明也从张大胖那里听到了一个让他崩溃的消息： 小明你知道吗?有个叫Netty的开源框架，可以快速地开发高性能的面向协议的服务器和客户端。 易用、健壮、安全、高效，你可以在Netty上轻松实现各种自定义的协议！咱们也试试？

像上面小明的例子，想使用Java NIO来实现一个高性能的RPC框架，调用协议，数据的格式和次序都是自己定义的，现有的HTTP根本玩不转，那使用Netty就是绝佳的选择。

 

其实游戏领域是个更好的例子，长连接，自定义协议，高并发，Netty就是绝配。

因为Netty本身就是一个基于NIO的网络框架， 封装了Java NIO那些复杂的底层细节，给你提供简单好用的抽象概念来编程。

注意几个关键词，首先它是个框架，是个“半成品”，不能开箱即用，你必须得拿过来做点定制，利用它开发出自己的应用程序，然后才能运行（就像使用Spring那样）。

一个更加知名的例子就是阿里巴巴的Dubbo了，这个RPC框架的底层用的就是Netty。

高性能，如果你的应用根本没有高并发的压力，那就不一定要用Netty了

 

 

实现WebSocket 聊天

 

  Netty实现WebSocket

Netty已经实现了WebSocket的细节，我们在使用时只需要创建一个WebSocket的握手对象即可

在接收消息时，要判断消息是普通Http消息还是WebSocket的消息

如果是普通的消息，则通过获取请求头中Upgrade中数据

如果是"websocket"的话，就表示这个Http消息是用来创建WebSocket连接的，这时候，就可以创建一个Websocket握手对象。

如果消息对象是一个WebSocket消息，就取出其中的内容，进行相应的逻辑处理，最后再写回一个WebScoket消息即完成了一次客户端向服务器请求WebSocket网络通信过程

当然我们也可以主动给客户端发送消息，我们在handler active之后就每秒钟来查询是否已经创建了WebSocket握手对象

如果已经创建了，就向客户端写一条消息，这就是服务器主动给客户端发送消息，实现网络双工通信

 

WebSocket

通过握手 从标准的http 协议转为自定义的协议，在应用中请求以ws结束时。我们才升级以Websocket。

服务器逻辑：

1.客户端、用户连接到服务器并加入聊天

2.HTTP请求页面或WebSocket升级握手

3.服务器处理所有的客户端和用户

4.响应url"/" 的请求，转到html页面

如果访问的url “ws”  ,处理websocket升级握手

升级握手完成后，通过Websocket发送聊天消息

 

总结Netty架构

 

第一层：Reactor  通信调度层，它由一系列辅助类完成，包括 Reactor 线程 NioEventLoop 以及其父类、NioSocketChannel/NioServerSocketChannel 

以及其父 类、ByteBuffer 以及由其衍生出来的各种 Buffer、Unsafe 以及其衍生出的各种内 部类等。

该层的主要职责就是监听网络的读写和连接操作，负责将网络层的数据 读取到内存缓冲区中，然后触发各种网络事件

例如连接创建、连接激活、读事 件、写事件等等，将这些事件触发到 PipeLine 中，由 PipeLine 充当的职责链来 进行后续的处理。

 

第二层：PipeLine     职责链

它负责事件在职责链中的有序传播，同时负责动态的 编排职责链，职责链可以选择监听和处理自己关心的事件，它可以拦截处理和向 后/向前传播事件，不同的应用的 Handler 节点的功能也不同

通常情况下，往往 会开发编解码 Hanlder 用于消息的编解码，它可以将外部的协议消息转换成内部 的 POJO 对象，这样上层业务侧只需要关心处理业务逻辑即可，不需要感知底层 的协议差异和线程模型差异，实现了架构层面的分层隔离。

 

第三层：业务逻辑处理层，可以分为两类：

1.纯粹的业务逻辑 处理，例如订单处理。

2.应用层协议管理，例如HTTP协议、FTP协议等。