到处是异步，异步滚滚而来Netty和ADBCJ

下一个Big Thing应该是异步。

JBoss发布了其NIO非堵塞IO框架Netty，总算追上GlassFish的Grizzly，赶超apache mina，经过测试，Netty性能要超过Mina，Netty是MINA的一个创始人跳到JBoss后开发的项目。

MINA使用系列I/O线程处理读和写，这是很多典型NIO框架的手法。但是Netty要比MINA聪明得多，当发送Queue中是空的，Netty将直接发送数据，不再例行公事放入Queue中，如果发送Queue不是空的，Netty将这个数据放入队列，这时类似MINA做法。所以，Netty要快些。

使用异步数据库驱动ADBCJ，在一个完全异步非堵塞场景下比较， I conducted a simple performance test comparing MINA and Netty. The test runs 100 simple select SQL queries against MySQL that each return a single string. Each test was run 100,000 times.

MINA 618,912,430.60ns 104,509,066.50ns
Netty 563,756,985.70ns 104,440,106.73ns

Netty架构：

异步数据库驱动ADBCJ：
http://code.google.com/p/adbcj/

异步Netty:
http://www.jboss.org/netty/index.html

在设计RESTful系统中，我们一般使用RESTLet结合MINA实现服务器端，但是MINA的产品性不是很强，文档不齐全，而Netty则弥补了这个空白，看来RESTLet + Netty可以获得一个高性能的可伸缩的分布式式架构。
[该贴被banq于2009-07-27 17:22修改过]

比较常见的几种著名的nio框架：grizzly,mina,xsocket和bang介绍的这个netty，从易用性上说，只有xsocket真正做到了高效和简洁。xsocket更新也比较及时，看得出作者的确用心。令人惊奇的是xsocket的简洁！它直接支持原生数据类型的io操作，不像mina和grizzly自作聪明的无耻的干扰用户应用程序逻辑（比如mina和grizzly都提供有关协议解析接口），也就是说mina和grizzly提供的api更加的侵入用户程序。这使得它们难以驾驭。学习过程非常复杂，而且容易出错。xsocket则尽量避免了这些，就像它的作者一直强调的一样，xsocket保持了nio的简洁性。xsocket的官方教程只有短短的经过精心设计的一页！大约40分钟的阅读，你便可以完全掌握它。除了编程模型跟阻塞式不同（nio框架写的好的全都是基于事件的模型，阻塞式io就是不断的轮询），io操作上跟阻塞式io编程很像。xsocket本身并不提供跟用户程序领域模型有关的一切，只是像阻塞式io那样的提供原生数据类型（byte,int ,String,byte[]...）的操作。这会是你最想看到的，因为我猜你也跟我一样不愿意去思考mina、grizzly之流提供的侵入应用逻辑的概念。下载xsocket以后你会发现，它不依赖与任何第三方类库！只有一个300多k的jar包，它的log功能也不是常规使用的log4j或者common log，而是直接使用jdk的logger。这一切都是我欣赏的！自从接触xsocket，mina、grizzly之流就被我彻底抛垃圾桶里了，不是它们不好，是因为它们太复杂难用。

Xsocket是不错。

想找个有Restful风格的异步Http服务器，加上推Push机制，这样一个组合应该很新潮，是未来趋势。

nio应该还包括jetty6 Continous和tomcat6 comet吧

jetty6 Continous和tomcat6 comet属于Push机制，是使用异步实现的PUSH。

这些框架服务器包括xsocket都在服务器端处理客户Session，而Restful是在客户端自己处理自己的session状态，所以，寻找Restful的轻量的异步框架中，目前没有看到。

如果这个轻量框架出现，将会冲击或替代SOA/SCA/ESB这个重量世界。

无论是grizzly,mina,xsocket，自己构建服务器在生产环境下实在是不现实，因为除非你有非常专业的IO知识，否则即便是别人封装好的api，自己封装出来的服务器，尤其是应用开发商招很多毕业学生，做这些就是没有把握的事情。所以为了迎合Rest以及异步机制而自己封装服务器一直停留在Demo阶段。

bloodrate 谈得有理，不过我们现在是在架构层面来谈这些，而不是从用户角度谈，从架构高度要细分，从用户角度要合，这样交给用户的是一个DSL之类的快速开发运行环境。

架构师应该更关注细分，正像ebay架构师总结伸缩性要旨为：任何地方都要异步，在每个环节都能异步，只有细分，打破串行化，才能异步，所以，异步架构思维是一种新式思维，是一种并发计算的新思维。

其实很羡慕互联网应用自己为自己搞技术，那种环境下的架构师才是真正的架构师

怎么就没人提到国内的 Cindy 呢？这个框架也挺不错的啊

不必老外的差，只是因为是国产的，就不用？

从文档和例子来说，xsocket和netty最好，grizzly的最烂；
性能应该netty最好，xsocket不知道如何。
基础类型IO倒是xsocket特有的；

这位仁兄有点极端。
在我看在技术只有适合不适合使用，而不是这种技术或者框架使用不现实。
也许有一天你会用到netty也说不定，而且是在生产环境。

据我所知有很服务都是基础mina、netty做的，而且是一些在中国来说比较牛的公司。

mina、netty、grizzly都做过测试，的确是mina最慢。
netty和grizzly比较的话，还是grizzly稍微快那么一点点点点......

2009年07月29日 13:32 "bloodrate"的内容

无论是grizzly,mina,xsocket，自己构建服务器在生产环境下实在是不现实，因为除非你有非常专业的IO知识，否则即便是别人封装好的api，自己封装出来的服务器，尤其是应用开发商招很多毕业学生，做这些就是没有把握的事情。所以为了迎合REST以及异步机制而自己封装服务器一直停留在Demo阶段。

我上面说的是对这个仁兄说的。