2.6 选择Netty的理由
在开始本节之前，我先讲一个亲身经历的故事：曾经有两个项目组同时用到了NIO编程技术，一个项目组选择自己开发NIO服务端，直接使用JDK原生的API，结果两个多月过去了，他们的NIO服务端始终无法稳定，问题频出。由于NIO通信是它们的核心组件之一，因此，项目的进度受到了严重的影响，领导对此也非常恼火。另一个项目组直接使用Netty作为NIO服务端，业务的定制开发工作量非常小，测试表明，功能和性能都完全达标，项目组几乎没有在NIO服务端上花费额外的时间和精力，项目进展也非常顺利。
这两个项目组的不同遭遇告诉我们：开发出高质量的NIO程序并不是一件简单的事情，除去NIO固有的复杂性和BUG不谈，作为一个NIO服务端，需要能够处理网络的闪断、客户端的重复接入、客户端的安全认证、消息的编解码、半包读写等情况，如果你没有足够的NIO编程经验积累，一个NIO框架的稳定往往需要半年甚至更长的时间。更为糟糕的是，一旦在生产环境中发生问题，往往会导致跨节点的服务调用中断，严重的可能会导致整个集群环境都不可用，需要重启服务器，这种非正常停机会带来巨大的损失。
从可维护性角度看，由于NIO采用了异步非阻塞编程模型，而且是一个I/O线程处理多条链路，它的调试和跟踪非常麻烦，特别是生产环境中的问题，我们无法进行有效的调试和跟踪，往往只能靠一些日志来辅助分析，定位难度很大。
喜欢的朋友可以添加我们的微信账号：
51CTO读书频道二维码
51CTO读书频道活动讨论群：342347198