`
Microhardest
  • 浏览: 9565 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论

试读《Netty权威指南》

 
阅读更多
已经很久没有从事Java开发的相关工作,现在一直是用nodejs做一些轻量级的web 应用。对于Java写的Web应用了解还停留在阻塞式IO的层次上:每一个链接都会独占一个线程,并且分配到一些栈空间。一旦在执行过程中没有接收到相应,就会保持阻塞状态。

没人告诉我为什么非这样做不可,只知道几乎所有关于Java Web的教材上都是基于一个理想的环境下,如何通过已有的成熟的框架,标准的讲解关于使用Java语言实现业务逻辑,如何链接数据库,如何对meta data进行处理,如何进行增删查改...一旦在真正的业务场景下,才会发现这些书籍讲的只是基本功,最宝贵的还是自己的挖掘和实践。

这本书中,作者对于netty的兴趣也正是来源于在正常的技术手段下不能很好的单方面响应阻塞的问题。按照标准的逻辑来看,一边依次发送请求,一边依次解析请求,做出反馈,然后这边再解析反馈执行业务逻辑,这是一个非常标准的流程。但是很多不可抗拒因素,比如网络速度异常,机箱长时间发热降低执行效率...这些根本不是代码本身可以控制的,唯一的办法就是改变标准的策略,尽可能减少单方面阻塞造成的影响。

一旦选择变革,就必然意味着寻找并适应方案所带来的过程。新的方案是否成熟,是否会给今后的拓展造成影响。作者在当时的条件下没有选择直接从BIO转型NIO,首先是技术上对NIO的模型不熟悉,其次没有业内较为成熟的基于Java的NIO解决方案。即便是NIO可以证明在理论上能够解决当前问题的情况下,依然存在着巨大的风险。最终作者只是通过微调已有方案的配置策略来降低问题的发生几率,我想这也是在当时实际情况下最为稳妥的解决方案。

目前,基于Java的NIO技术和框架在无数技术人员的不断创新和推广下,已经有了非常巨大的发展,。很多互联网公司及传统行业大佬们都意识其的重要性,使得NIO技术获得了无数商用场景下的成功案例,这无疑为我们这些后来者扫清了道路。即便对于NIO框架本身不是非常熟悉,仍然有不少社区可以提供帮助和解答。这对于构建Netty的生态系统起到了十分积极的作用。

谈谈试读章节,试读章节中印象比较深刻的就是上文中提到的选择netty作为通信技术应用到实际项目中的过程。至于下一个试读章节中讲到的应用实例,我觉得花了太多的笔墨在描写如何绑定XML数据格式上,还有request的编码解码,response的编码解码,而这些内容并非和Netty有着直接的联系。直到“HTTP和XML客户端开发”一节开始才正式开始提到以NIO相关的编程内容。在NIO相关代码上,一些关于“Group”和“Channel”的概念不是特别了解,但是即便如此,还是可以从代码风格上看到使用Netty的确十分优雅。希望有机会能够读到完整版的《Netty权威指南》,使得对Java场景下的NIO和nodejs的AIO机制做一个更全面的比较。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics