随着移动互联网的爆发性增长,小明公司的电子商务系统访问量越来越大,由于现有系统是个单体的巨型应用,已经无法满足海量的并发请求,拆分势在必行。
在微服务的大潮之中, 架构师小明把系统拆分成了多个服务,根据需要部署在多个机器上,这些服务非常灵活,可以随着访问量弹性扩展。
世界上没有免费的午餐, 拆分成多个“微服务”以后虽然增加了弹性,但也带来了一个巨大的挑战:服务之间互相调用的开销。
比如说:原来用户下一个订单需要登录,浏览产品详情,加入购物车,支付,扣库存等一系列操作,在单体应用的时候它们都在一台机器的同一个进程中,说白了就是模块之间的函数调用,效率超级高。
现在好了,服务被安置到了不同的服务器上,一个订单流程,几乎每个操作都要越网络,都是远程过程调用(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
Connection: 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,一点儿都不浪费。
好了,就是 Java NIO 了!
小明先定义了一套精简的 RPC 的协议,里边规定了如何去调用一个服务,方法名和参数该如何传递,返回值用什么格式......等等。然后雄心勃勃地要把这个协议用 Java NIO 给实现了。
可是美好的理想很快被无情的现实给击碎, 小明努力了一周就意识到自己陷入了一个大坑之中,Java NIO 虽然看起来简单,但是 API 还是太“低级”了,有太多的复杂性,没有强悍的、一流的编程能力根本无法驾驭,根本做不到高并发情况下的可靠和高效。
小明不死心,继续向领导要人要资源,一定要把这个坑给填上,挣扎了 6 个月以后,终于实现了一个自己的 NIO 框架,可以执行高并发的 RPC 调用了。
然后又是长达 6 个月的修修补补,小明经常半夜被叫醒:生产环境的 RPC 调用无法返回了! 这样的 Bug 不知道改了多少个。
在那些不眠之夜中,小明经常仰天长叹:我用 NIO 做个高并发的 RPC 框架怎么这么难呐!
一年之后,自研的框架终于稳定,可是小明也从张大胖那里听到了一个让他崩溃的消息: 小明你知道吗?有个叫 Netty 的开源框架,可以快速地开发高性能的面向协议的服务器和客户端。 易用、健壮、安全、高效,你可以在 Netty 上轻松实现各种自定义的协议!咱们也试试?
小明赶紧研究,看完后不由得“泪流满面”:这东西怎么不早点出来啊!
好了,这个故事我快编不下去了,要烂尾了。
说说 Netty 到底是何方神圣, 要解决什么问题吧。
像上面小明的例子,想使用 Java NIO 来实现一个高性能的 RPC 框架,调用协议,数据的格式和次序都是自己定义的,现有的 HTTP 根本玩不转,那使用 Netty 就是绝佳的选择。
其实游戏领域是个更好的例子,长连接,自定义协议,高并发,Netty 就是绝配。
因为 Netty 本身就是一个基于 NIO 的网络框架, 封装了 Java NIO 那些复杂的底层细节,给你提供简单好用的抽象概念来编程。
注意几个关键词,首先它是个框架,是个“半成品”,不能开箱即用,你必须得拿过来做点定制,利用它开发出自己的应用程序,然后才能运行(就像使用 Spring 那样)。
一个更加知名的例子就是阿里巴巴的 Dubbo 了,这个 RPC 框架的底层用的就是 Netty。
另外一个关键词是高性能,如果你的应用根本没有高并发的压力,那就不一定要用 Netty 了。
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于