前言:
RPC(Remote Procedure Call)远程过程调用,简单的理解是一个节点请求另一个节点提供的服务,这其中就涉及到了网络通信,Java做网络通信这块,离不开Netty框架。
Java程序员想要进阶,绕不开Netty。
如果你想脱离只会CRUD的编程苦海,同样绕不开Netty。
网络通信编程,是通往神级程序员的必经之路,其中涉及到的知识浩渺如海,但同时也能让你得到技术升华
- 网卡
- IP地址 (局域网IP,公网IP)
- 路由器
- 交换机
- 网线 (数据发送出去了)
- 如果数据在发送的过程中,有时间,有流动性,水流的时候 突然放上指头,水就会断一下
- 接收方,接收数据的时候,怎么判断数据接收完成
- socket套接字
Netty是一款基于NIO(Nonblocking I/O,非阻塞IO)开发的网络通信框架
以两个应用程序通讯为例:应用A向应用B发送一条消息
BIO 全称Block-IO 是一种同步且阻塞的通信模式
阻塞就是发起读取数据请求的时,当数据还没准备就绪的时候,这时请求是即刻返回,还是在这里等待数据的就绪,如果需要等待的话就是阻塞,反之如果即刻返回就是非阻塞。
在IO模型里面如果请求方从发起请求到数据最后完成的这一段过程中都需要自己参与,那么这种我们称为同步请求;反之,如果应用发送完指令后就不再参与过程了,只需要等待最终完成结果的通知,那么这就属于异步。
上面的例子中,都是使用的java的原生io。
使用原生io有以下问题:
- NIO的类库和API繁杂,使用麻烦
- 可靠性能力补齐,工作量和难度都非常大。例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理等问题,NIO编程的特点是功能开发相对容易,但是可靠性能力补齐的工作量和难度都非常大。
- JDK NIO的BUG,例如臭名昭著的epoll bug,它会导致Selector空轮询,最终导致CPU 100%。官方声称在JDK 1.6版本的update18修复了该问题,但是直到JDK 1.7版本该问题仍旧存在,只不过该BUG发生概率降低了一些而已,它并没有得到根本性解决。
- 需要具备其他的额外技能做铺垫,例如熟悉Java多线程编程。这是因为NIO编程涉及到Reactor模式,你必须对多线程和网络编程非常熟悉,才能编写出高质量的NIO程序。
Netty是业界最流行的NIO框架之一,它的健壮性、功能、性能、可定制性和可扩展性在同类框架中都是首屈一指的,它已经得到成百上千的商用项目验证,例如Hadoop的RPC框架Avro就使用了Netty作为底层通信框架,其他还有业界主流的RPC框架(dubbo等),也使用Netty来构建高性能的异步通信能力。
优点:
- API使用简单,开发门槛低
- 功能强大,预置了多种编解码功能,支持多种主流协议
- 定制能力强,可以通过ChannelHandler对通信框架进行灵活地扩展
- 性能高,通过与其他业界主流的NIO框架对比,Netty的综合性能最优
- 成熟、稳定,Netty修复了已经发现的所有JDK NIO BUG,业务开发人员不需要再为NIO的BUG而烦恼
- 社区活跃,版本迭代周期短,发现的BUG可以被及时修复,同时,更多的新功能会加入
- 经历了大规模的商业应用考验,质量得到验证。Netty在互联网、大数据、网络游戏、企业应用、电信软件等众多行业已经得到了成功商用,证明它已经完全能够满足不同行业的商业应用了
我们要实现一个RPC框架,使得远程调用就和本地调用一样,屏蔽底层的网络通信的复杂性,让我们更加专注于业务,同时传输性能要高。