选择Netty作为基础通信框架 .

在开始之前,我先讲一个亲身经历的故事:曾经有两个项目组同时用到了NIO编程技术,一个项目组选择自己开发NIO服务端,直接使用JDK原生的API,结果两个多月过去了,他们的NIO服务端始终无法稳定,问题频出。由于NIO通信是它们的核心组件之一,因此项目的进度受到了严重的影响。另一个项目组直接使用Netty作为NIO服务端,业务的定制开发工作量非常小,测试表明,功能和性能都完全达标,项目组几乎没有在NIO服务端上花费额外的时间和精力,项目进展也非常顺利。

这两个项目组的不同遭遇告诉我们:开发出高质量的NIO程序并不是一件简单的事情,除去NIO固有的复杂性和BUG不谈,作为一个NIO服务端,需要能够处理网络的闪断、客户端的重复接入、客户端的安全认证、消息的编解码、半包读写等情况,如果你没有足够的NIO编程经验积累,一个NIO框架的稳定往往需要半年甚至更长的时间。更为糟糕的是,一旦在生产环境中发生问题,往往会导致跨节点的服务调用中断,严重的可能会导致整个集群环境都不可用,需要重启服务器,这种非正常停机会带来巨大的损失。

从可维护性角度看,由于NIO采用了异步非阻塞编程模型,而且是一个I/O线程处理多条链路,它的调试和跟踪非常麻烦,特别是生产环境中的问题,我们无法进行有效的调试和跟踪,往往只能靠一些日志来辅助分析,定位难度很大。

1 不选择Java原生NIO编程的原因

现在我们总结一下为什么不建议开发者直接使用JDK的NIO类库进行开发,具体原因如下。

(1)NIO的类库和API繁杂,使用麻烦,你需要熟练掌握Selector、ServerSocketChannel、SocketChannel、ByteBuffer等。

(2)需要具备其他的额外技能做铺垫,例如熟悉Java多线程编程。这是因为NIO编程涉及到Reactor模式,你必须对多线程和网路编程非常熟悉,才能编写出高质量的NIO程序。

(3)可靠性能力补齐,工作量和难度都非常大。例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理等问题,NIO编程的特点是功能开发相对容易,但是可靠性能力补齐的工作量和难度都非常大。

(4)JDK NIO的BUG,例如臭名昭著的epoll bug,它会导致Selector空轮询,最终导致CPU 100%。官方声称在JDK 1.6版本的update18修复了该问题,但是直到JDK 1.7版本该问题仍旧存在,只不过该BUG发生概率降低了一些而已,它并没有得到根本性解决。该BUG以及与该BUG相关的问题单可以参见以下链接内容。

◎    http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6403933

◎    http://bugs.java.com/bugdatabase/view_bug.do?bug_id=2147719

异常堆栈如下。

java.lang.Thread.State: RUNNABLE

 at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)

        at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:210)

        at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:65)

at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)

- locked <0x0000000750928190> (a sun.nio.ch.Util$2)

- locked <0x00000007509281a8> (a java.util.Collections$ UnmodifiableSet)

- locked <0x0000000750946098> (a sun.nio.ch.EPollSelectorImpl)

 at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)

at net.spy.memcached.MemcachedConnection.handleIO(Memcached Connection.java:217)

at net.spy.memcached.MemcachedConnection.run(MemcachedConnection. java:836)

由于上述原因,在大多数场景下,不建议大家直接使用JDK的NIO类库,除非你精通NIO编程或者有特殊的需求。在绝大多数的业务场景中,我们可以使用NIO框架Netty来进行NIO编程,它既可以作为客户端也可以作为服务端,同时支持UDP和异步文件传输,功能非常强大。

下个小节我们就看看为什么选择Netty作为基础通信框架。

2 为什么选择Netty

Netty是业界最流行的NIO框架之一,它的健壮性、功能、性能、可定制性和可扩展性在同类框架中都是首屈一指的,它已经得到成百上千的商用项目验证,例如Hadoop的RPC框架Avro就使用了Netty作为底层通信框架,其他还有业界主流的RPC框架,也使用Netty来构建高性能的异步通信能力。

通过对Netty的分析,我们将它的优点总结如下。

◎    API使用简单,开发门槛低;

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

◎    定制能力强,可以通过ChannelHandler对通信框架进行灵活地扩展;

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

◎    成熟、稳定,Netty修复了已经发现的所有JDK NIO BUG,业务开发人员不需要再为NIO的BUG而烦恼;

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

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

正是因为这些优点,Netty逐渐成为了Java NIO编程的首选框架。

时间: 2024-10-03 16:14:16

选择Netty作为基础通信框架 .的相关文章

netty作为基础通信组件

阿里分布式服务框架 Dubbo 的 RPC 框架使用 Dubbo 协议进行节点间通信,Dubbo 协议默认使用 Netty 作为基础通信组件,用于实现各进程节点之间的内部通信.其中,服务提供者和服务消费者之间,服务提供者.服务消费者和性能统计节点之间使用 Netty 进行异步/同步通信. 除了 Dubbo 之外,淘宝的消息中间件 RocketMQ 的消息生产者和消息消费者之间,也采用 Netty 进行高性能.异步通信.

新手入门:目前为止最透彻的的Netty高性能原理和框架架构解析(阿里)

1.引言 Netty 是一个广受欢迎的异步事件驱动的Java开源网络应用程序框架,用于快速开发可维护的高性能协议服务器和客户端. 本文基于 Netty 4.1 展开介绍相关理论模型,使用场景,基本组件.整体架构,知其然且知其所以然,希望给大家在实际开发实践.学习开源项目方面提供参考. 本文作者的另两篇<高性能网络编程(五):一文读懂高性能网络编程中的I/O模型>.<高性能网络编程(六):一文读懂高性能网络编程中的线程模型>也写的很好,有兴趣的读者可以一并看看. 关于作者: 陈彩华(

Spark1.6之后为何使用Netty通信框架替代Akka

解决方案: 一直以来,基于Akka实现的RPC通信框架是Spark引以为豪的主要特性,也是与Hadoop等分布式计算框架对比过程中一大亮点. 但是时代和技术都在演化,从Spark1.3.1版本开始,为了解决大块数据(如Shuffle)的传输问题,Spark引入了Netty通信框架,到了1.6.0版本,Netty居然完成取代了Akka,承担Spark内部所有的RPC通信以及数据流传输. 网络IO扫盲贴 在Linux操作系统层面,网络操作即为IO操作,总共有:阻塞式,非阻塞式,复用模型,信号驱动和异

高性能NIO通信框架之Netty入门(一)

一.不选择Java原生NIO编程的原因(1)NIO的类库和API复杂,使用麻烦,你需要熟练掌握Selector.ServerSocketChannel.SocketChannel.ByteBuffer等(2)需要具备其他的额外技能做铺垫,例如熟悉Java多线程编程.这是因为NIO编程涉及到Reactor模式,你必须对多线程和网络编程非常熟悉,才能编写出高质量NIO程序.(3)可靠性能力补齐,工作量和难度都非常大.例如客户端面临断链重连.网络闪断.半包读写.失败缓存.网络拥塞和异常码流的处理等问题

NetworkComms c#通信框架与Java的Netty框架通信 解决粘包问题

上次写了一篇文章  基于networkcomms V3通信框架的c#服务器与java客户端进行通信之Protobuf探讨 其中没有解决粘包问题,抛砖引玉,文章得到了失足程序员 老师的点评,并给出了解决方案:[最多评论]java netty socket库和自定义C#socket库利用protobuf进行通信完整实例(10/591) » 于是马上开始学习,并把c#服务器端换成了我比较熟悉的networkcomms v3 c#通信框架(商业版,本文并不提供) ,以方便与已经存在的系统进行整合. 客户

Web3D编程入门总结——面向对象的基础Web3D框架

本篇主要通过分析Tony Parisi的sim.js库(原版代码托管于:https://github.com/tparisi/WebGLBook/tree/master/sim),总结基础Web3D框架的编写方法.在上一篇的基础上,要求读者具有简短英文阅读或者查字典的能力. 限于水平和时间,本文难免出现错误与遗漏,您在阅读过程中如果遇到错误或者疑问请在评论区中指出,我将尽快回复. 为提高JavaScript编程效率,建议使用WebStorm工具进行网页程序编写,WebStorm官网:http:/

OHSCE 教程:高可靠性的 PHP 通信框架

OHSCE高可靠性的PHP通信框架. PHP以太网(TCP/UDP/ICMP).RS232.RS485通信,可广泛直接或桥接各种网络工程通信. 特别合适于对可靠性要求较高.上位机与末端协同工作的场景.如物联网设备通信.智能化系统.工业与自动化系统.可靠网络服务器. 可运行于Windows.Linux.OS X(基础教程qkxue.net).对Windows提供了全项功能支持,与自动化生态亲和. 不过分追求高性能,充分平衡了可靠性与高性能. 天生支持分布式,可大规模部署. 在保证您的网络可靠性的前

HP-SOCKET TCP/UDP通信框架库解析

项目概述: HP-SOCKET是一套通用TCP/UDP通信框架,包括服务器.客户端.Agent组件:其目标是提供高性能.通用性.简易性.可扩展.可定制: 鉴于此,其仅实现基本的通用框架通信.数据收发功能,供上层应用直接简单使用的接口实现:而对于数据包完整性和协议解析等未处理, 也就意味着需要应用层自己处理一些数据包构造或解析等操作: 事实上目前只能支持windows平台: 1. 对于TCP通信模式下:服务器端和Agent均采用的是异步IO模型中的完成端口模型,客户端采用的是就绪IO通告模型中的W

RPC通信框架——RCF介绍(替换COM)

阅读目录 RPC通信框架 为什么选择RCF 简单的性能测试 参考资料 总结 现有的软件中用了大量的COM接口,导致无法跨平台,当然由于与Windows结合的太紧密,还有很多无法跨平台的地方.那么为了实现跨平台,支持Linux系统,以及后续的分布式,首要任务是去除COM接口. 在对大量框架进行调研后,决定使用RCF替换COM接口. 回到顶部 RPC通信框架 CORBA ICE Thrift zeromq dbus RCF YAMI4 TAO 回到顶部 为什么选择RCF 经过各项对比,认为: RCF