NIO服务器框架

引用：http://blog.csdn.net/liu251/archive/2009/02/03/3860652.aspx

 

1、MINA   一个优秀的NIO框架。ACE式的NIO和线程模型，filter chains机制，IO层与protocol层的分离，设计师们可以依赖着开发高性能的自定义协议TCP/IP服务器。其他框架：Grizzly，脱胎于Glassfish的NIO框架，性能好像比MINA还好一点。
2、CXF 前身就是XFire，一个完整的Web Service Framework：
HTTP, JMS, and Jabber 的Transports SOAP, REST and Corba的Binding JAXB 2.0、 XML Beans、Castor and JiBX的DataBinding Support JAX-WS2.0、CORBA，SCA与JBI 可以部署在：
Standalone java server Tomcat or Spring-based 的轻量级容器 Weblogic、WebSphere、JBoss的J2EE容器 ServiceMix，OpenESB的JBI容器 Tuscany的SCA容器 设计师们可以学习它眼花缭乱的机制，从一个Stand alone，ad Hoc协议的服务器，开始支持更多更公共的endpoint，也把自己作为一个Module，部署到更大更稳健的服务器之中。
3、Mule    作为Enterprise Service Bus (ESB) and Messaging broker，能力就夸张了：
可插入的连接方式 such as WebService，JMS , VM (embedded), JDBC, TCP, UDP, multicast, http, servlet, SMTP, POP3, file, XMPP. 同步，异步，request-response的请求模式。 Client/Server, Peer-to-Peer, ESB的拓扑模式。 大量的Routing，Transform选择 Enterprise Integration Patterns的遵循者。 SEDA processing model的高性能模式。 Spring，BPM的整合。      面对这样一个诱人的ESB方案，看起来比前面的CXF模式更加合适，那如何应用？和业界一样的踌躇。
4、JBoss / Geronimo      地球人都知道这是两个应用服务器，特别在于，它们都有某种良好的插件机制，将EJB Container，Servlet Container，JMS 模块作为Module部署到服务器中，成为服务器的一种能力。 JBoss的每个Service就是一个MBean，配合一个service描述文件。Geronimo更是著名的以GBean作为底层架构，跑马圈地的把开源社区的方案集合在repository目录中，玩票式的组成了一个通过J2EE 1.4认证的应用服务器。我们自写的服务，可不可以也通过相同的机制，嵌入到JBoss/Geronimo之中，从而直接拥有了应用服务器的其他一切能力，就像把Tomcat建于JBoss MicroKernel之上，拥有JBossJTA，JBoss Cache能力的JBoss Web？   Labourey说：“Microkernel 是JBoss 的心脏。现在有许多电讯公司使用Microkernel ，用作其服务器应用软件的基础”看来自己并没有发明创造:(     其他服务器：Glassfish
5.世界的其他角落
Tuscany SCA 的开源实现，IBM与BEA联手贡献。 Esper Event-Driven Application Servers。 GridGain 开源网格计算平台，集成Spring,JBoss。 6.小结MINA提供了工具，Mule/JBoss/Geronimo提供了容器， CXF/Mule提供了模式，而这些都还仅是Java开源社区的冰山一角，回望那个只有ICE和ACE/TAO的孤寂世界.......
二、开动：
1、入门文档
MINA Presentation Materials CXF Architecture Guide Mule Developers Guide、MuleCon 2007 Geronimo Architecture The JBoss 4 Application Server Guide 2、阅读代码        阅读只是为了发掘文档里没有描述的架构与模式，而其实很多模式在代码里都很显眼，来来去去就那几道斧子，所以有了快速略读的可能，而不是Apache源码阅读式的愚公移山，精卫填海。
设计美好的服务器系列文章：
设计一个美好的服务器--MINA、CXF、Mule、JBoss/Geronimo 设计美好的服务器II--站在JBoss MicroKernel上 轻的，谁都会写的Service方案--REST与JSON 设计美好的服务器(4)--Mule ESB笔记 Grizzly介绍声明：任何人转载或引用该问必须保持该文章的链接。必须以超链接的形式标明文章的作者和出处。 声明：本文参考自https://grizzly.dev.java.net/presentations/FISL-2007.pdf。
1、介绍Grizzly：Grizzly是一种应用程序框架，专门解决编写成千上万用户访问服务器时候产生的各种问题。

2、什么是Grizzly？ 使用JAVA NIO作为基础，并隐藏其编程的复杂性。容易使用的高性能的API。带来非阻塞socketd到协议处理层。利用高性能的缓冲和缓冲管理使用高性能的线程池。

3、Grizzly与Mina的性能比较：比较结果Grizzly比Mina更好。 

4、Grizzly的HTTP性能：支持的并发客户端：平均响应时间：8S 90%时间在3S内出错率在0.1%以下。

5、Grizzly的历史：在GlassFish项目中于2004年诞生。后来为Grizzly 1.0。 Grizzly1.0跟Sun Java System Application Server8.1，8.2和所有的GlassFish版本。用来代替本地的Sun WebServer运行时。开始目的是建构一个HTTP Web服务器，用来代替Tomcat的Coyote连接器和Sun WebServ er6.1。 Grizzly1.0在2006年的时候变得相当流行。多数协议实现都基于它。但是Grizzly1.0有HTTP协议的特定实现逻辑包含在传送层中。主要类SelectorThread包含若干的HTTP的处理，如文件cache，请求监控等。为了使用框架，需要扩展SelectorThread，例如JettySelectorThread，SSLSelectorThread。 Grizzly1.0混合了扩展和实现。 虽然如此，但Grizzly1.0仍然是很好的实现，有下面几个协议利用了Grizzly1.0： JRuby On Grizzly ；Alaska的HTTP BC组件 ；GlassFishV3的微内核 ；Phobos GlassFish的SOAP ； Comet、Cometd ；AsyncWeb ；GlassFishV2 ；Sun Web2.0 Developer pack(REST Http Server) 。

Grizzly1.5于2006年开始开发。Grizzly1.5的目标：

1，删除所有的HTTP或者GlassFish的依赖；

2， 所有1.0的应用仍能在1.5上工作；

3， 支持Grizzly1.0时候的性能优化。

4， 不依赖于任何的第三方软件。 2007年2月6日Grizzly开源了。  

6、控制器： Controller是主要的进入点，Controller由下面部分构成： SelectorHandler； SelectionKeyHandler； ProtocolChainInstanceHandler ；ProtocolChain 。Pipeline 这些组件在Grizzly框架中都是可以配置的。  

7、SelectorHandler ： SelectorHandler处理所有的nio。channel。Selector操作。可以处理1个或多个的Selector。

8、SelectionKeyHandler ：用来处理SelectionKey的生命周期。例如取消，注册，或者关闭SelectionKeys由SelectionKeyHandler来处理。

9、InstanceHandler： InstanceHandler用来创建或者缓冲几个ProtocolChain。 InstanceHandler决定有状态或者无状态的协议链是否需要被创建。注意：InstanceHandler重命名为ProtocolChainInstanceHandler。

10、Pipeline ：一个接口用来封装各种线程池。 Grizzly1.5包含了几个的管道的实现。最佳性能实现的管道是默认配置的管道。 

11、ProtocolChain ：协议链实现责任链模式。协议链由若干的协议过滤器组合成。注意：协议连的所有者必须调用postExecute()方法。 

12、ProtocolFilter ：协议过滤器由两个方法构成：execute和postExecute。 Context包含了动态的计算状态。协议过滤器封装了一个将要工作的单元。目的是检查或修改状态的改变。 独立的协议链可以被集成到协议链。 当使用默认的协议链的时候，协议过滤器应该设计成线程安全的。通常，这表示协议过滤器应该不包含维护状态信息。 维护状态信息应该由ProtocolContext来维护，并通过method和postExecute来传递。

14、谁在使用Grizzly？—— Jetty ，Alaska ，Tango ，Jruby on Grizzly ，php on Grizzly ，Ning ，Comet、Cometd 。

15、谁在寻找或投资Grizzly？—— Sun Java System Message Queue ；Sun JDK ORB； GlassFish ORB； Derby、JavaDB 等。
http://blog.csdn.net/zhangliulin/archive/2007/10/16/1826708.aspx 一个NIO框架——Cindy简介
Cindy简介 （作者Blog: http://spaces.msn.com/members/crmky）

Cindy是一个基于java nio的I/O框架，支持TCP/UDP单播/UDP多播/Pipe，为应用程序提供了一个统一的接口去实现异步和同步的网络操作。
java io包提供了一个简单的模型去处理网络流，它读写均为阻塞操作，在一般的应用里，用户总是开启一个独立线程或一个线程池去处理这些IO操作。它非常简单易用，但在扩展性和效率上存在着一些问题。如果用户只需要一两个网络连接，开启几个独立线程操作无伤大雅，但是如果面对服务器端的成百上千个连接，采用java io提供的机制，就需要同时开启成百上千个线程，即使能够处理过来，花在线程上下文切换的时间也远远多于网络操作的用时。
在JDK 1.4中，Java引入了nio包，除开nio提供的一些其他功能外，最吸引人的就是引入了非阻塞IO的实现。但是直接使用nio中非阻塞I/O需要处理众多异常，维护状态，为应用带来不必要的复杂性。并且JDK 1.4中的nio包只实现了普通TCP/UDP单播/Pipe，JDK 5.0中引入了SSLEngine类，使得基于非阻塞I/O的TCP可以支持SSL和TLS，未来在JDK 6.0才会加入对非阻塞I/O UDP多播的实现。如果应用程序只想使用同一个模型去操作网络I/O，而不想关心这些诸多限制，那么Cindy是一个很好的选择。
目前基于nio的开源I/O框架很多，Cindy并不是唯一的选择，比较好实现如Netty2、MINA等等。由于是Cindy的作者，对Cindy的了解程度要高于对其他框架的了解程度，这里所做的比较只是基于作者自身的看法，可能会有失偏颇。在你进行选择之前，你应该从你自身应用的角度进行仔细的比较。
Netty2具有很好的构架，并且该框架非常有名，使用该框架的项目不少，这意味着开发团队持续更新的动力非常大（BTW，刚知道Netty2的开发已经停止了，抱歉）。同时Netty2的文档非常齐全，并且支持JMX（这是我不熟悉的领域，不做评论）。Netty2的缺点就是实现代码的质量不是非常好，最大的缺点就是只支持普通的TCP。
MINA是Netty2作者的一个新项目，该项目目前实现的版本已经支持TCP/UDP/Pipe，并且由它的Roadmap上可得知将来会加入对JMX和容器的支持。我未曾使用过该项目，不过既然是Netty2作者的新项目，应该也吸收了Netty2的优点，并且对Netty2中的缺点做了改良。从该项目带的Example来看，使用起来应该是非常简单的。
Cindy起源于Netty2之后，借鉴了Netty2中MessageRecognizer类的设计，在当前的版本中已经全面支持普通TCP/Secure TCP/UDP单播/UDP多播/Pipe，可以使用同一个模型进行同步/异步IO处理，并且成功的应用在JML项目中（Java Msn Messenger Library，开源项目，目前发布的版本基于Cindy老的版本），并且在目前公司的项目中也有实际使用。Cindy目前并不打算加入对JMX的支持（不熟悉），也没有计划加入对容器的支持（这个应该是应用做的事情），我想保持Cindy核心的简洁和高效，最好能够代替Socket/DatagramSocket的地位（简单应用的话也许还是使用这个更好：））。Cindy目前缺点是文档相对较少以及应用的项目比较少，希望这几篇文档能够稍微弥补以下Cindy在这文档方面的不足。
Cindy：http://cindy.sourceforge.net
Netty2：http://gleamynode.net/dev/
MINA：http://www.apache.org/~trustin/mina-20050207/index.html