1）传输：IO模型在很大程度上决定了框架的性能，相比于bio，netty建议采用异步通信模 式，因为nio一个线程可以并发处理N个客户端连接和读写操作，这从根本上解决了传统同步阻 塞IO一连接一线程模型，架构的性能、弹性伸缩能力和可靠性都得到了极大的提升。正如代码 中所示，使用的是NioEventLoopGroup和NioSocketChannel来提升传输效率。
2）协议：采用什么样的通信协议，对系统的性能极其重要，netty默认提供了对Google Protobuf的支持，也可以通过扩展Netty的编解码接口，用户可以实现其它的高性能序列化框 架。
3）线程：netty使用了Reactor线程模型，但Reactor模型不同，对性能的影响也非常大，下 面介绍常用的Reactor线程模型有三种，分别如下：
Reactor单线程模型：单线程模型的线程即作为NIO服务端接收客户端的TCP连接，又作为 NIO客户端向服务端发起TCP连接，即读取通信对端的请求或者应答消息，又向通信对端发送 消息请求或者应答消息。理论上一个线程可以独立处理所有IO相关的操作，但一个NIO线程同时处理成百上千的链路，性能上无法支撑，即便NIO线程的CPU负荷达到100%，也无法满足 海量消息的编码、解码、读取和发送，又因为当NIO线程负载过重之后，处理速度将变慢，这 会导致大量客户端连接超时，超时之后往往会进行重发，这更加重了NIO线程的负载，最终会 导致大量消息积压和处理超时，NIO线程会成为系统的性能瓶颈。
Reactor多线程模型：有专门一个NIO线程用于监听服务端，接收客户端的TCP连接请求；网 络IO操作(读写)由一个NIO线程池负责，线程池可以采用标准的JDK线程池实现。但百万客户 端并发连接时，一个nio线程用来监听和接受明显不够，因此有了主从多线程模型。 主从Reactor多线程模型：利用主从NIO线程模型，可以解决1个服务端监听线程无法有效处理 所有客户端连接的性能不足问题，即把监听服务端，接收客户端的TCP连接请求分给一个线程 池。因此，在代码中可以看到，我们在server端选择的就是这种方式，并且也推荐使用该线程 模型。在启动类中创建不同的EventLoopGroup实例并通过适当的参数配置，就可以支持上述 三种Reactor线程模型。
