Reprinted from: https://blog.csdn.net/bjweimengshu/article/details/78786315
With the explosive growth of the mobile Internet, Xiaoming's e-commerce system has more and more visits. Since the existing system is a single giant application, it can no longer meet the massive concurrent requests, so splitting is imperative.
In the tide of microservices, architect Xiao Ming divided the system into multiple services, which were deployed on multiple machines as needed. These services are very flexible and can be elastically expanded with the number of visits.
There is no free lunch in the world. After splitting into multiple "microservices", although it increases flexibility, it also brings a huge challenge: the overhead of calling each other between services.
For example, the original user needs to log in, browse product details, add to the shopping cart, pay, deduct inventory and other operations when placing an order. The function calls between them are super efficient.
Well now, the service is placed on different servers. In an order process, almost every operation has to go over the network, and it is a remote procedure call (RPC). The execution time and execution efficiency are far less than before.
The first version of the remote procedure call implementation uses the HTTP protocol, which means that each service provides an HTTP interface to the outside world. Xiao Ming found that although the HTTP protocol is simple and clear, there is too much nonsense. Just sending a simple message to the server will bring a lot of useless information:
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了。