NIO服务器框架

缺乏、安全感 2022-09-30 04:53 8阅读 0赞

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

**1、**[**MINA**][MINA]   一个优秀的NIO框架。ACE式的NIO和线程模型，filter chains机制，IO层与protocol层的分离，设计师们可以依赖着开发高性能的自定义协议TCP/IP服务器。其他框架：[Grizzly][]，脱胎于[Glassfish][]的NIO框架，性能好像比MINA还好一点。  
**2、**[**CXF**][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**][Mule]    作为Enterprise Service Bus (ESB) and Messaging broker，能力就夸张了：  
[可插入的连接方式][Link 1] 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**][JBoss] **/ **[**Geronimo**][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][--MINA_CXF_Mule_JBoss_Geronimo] [设计美好的服务器II--站在JBoss MicroKernel上][II--_JBoss MicroKernel] [轻的，谁都会写的Service方案--REST与JSON][Service_--REST_JSON] [设计美好的服务器(4)--Mule ESB笔记][4_--Mule ESB] [Grizzly介绍][Grizzly 1]声明：任何人转载或引用该问必须保持该文章的链接。必须以超链接的形式标明文章的作者和出处。 声明：本文参考自[https://grizzly.dev.java.net/presentations/FISL-2007.pdf][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][http_blog.csdn.net_zhangliulin_archive_2007_10_16_1826708.aspx] **一个NIO框架——Cindy简介**  
**Cindy简介 **（作者Blog: [http://spaces.msn.com/members/crmky][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][http_cindy.sourceforge.net]  
Netty2：[http://gleamynode.net/dev/][http_gleamynode.net_dev]  
MINA：[http://www.apache.org/~trustin/mina-20050207/index.html][http_www.apache.org_trustin_mina-20050207_index.html]

[http_blog.csdn.net_liu251_archive_2009_02_03_3860652.aspx]: http://blog.csdn.net/liu251/archive/2009/02/03/3860652.aspx
[MINA]: http://mina.apache.org/
[Grizzly]: https://grizzly.dev.java.net/
[Glassfish]: https://glassfish.dev.java.net/
[CXF]: http://incubator.apache.org/cxf/
[Mule]: http://mule.codehaus.org/
[Link 1]: http://mule.codehaus.org/display/MULE/Transports+Guide
[Enterprise Integration Patterns]: http://www.enterpriseintegrationpatterns.com/
[SEDA processing model]: http://mule.codehaus.org/display/MULE/SEDA
[Spring]: http://mule.codehaus.org/display/MULE/Spring
[BPM]: http://mule.codehaus.org/display/MULE/BPM+Connector
[JBoss]: http://labs.jboss.com/jbossas/
[Geronimo]: http://geronimo.apache.org/
[Tuscany]: http://incubator.apache.org/tuscany/
[Esper]: http://esper.codehaus.org/
[GridGain]: http://www.gridgain.com/
[MINA Presentation Materials]: http://mina.apache.org/#Documentation-PresentationMaterials
[CXF Architecture Guide]: http://cwiki.apache.org/CXF20DOC/cxf-architecture.html
[Mule Developers Guide]: http://mule.codehaus.org/display/MULE/Developers+Guide
[MuleCon 2007]: http://mule.codehaus.org/display/MULE/MuleCon+2007%2C+San+Francisco
[Geronimo Architecture]: http://cwiki.apache.org/GMOxDEV/geronimo-architecture.html
[The JBoss 4 Application Server Guide]: http://docs.jboss.org/jbossas/jboss4guide/r5/html/index.html
[--MINA_CXF_Mule_JBoss_Geronimo]: http://blog.csdn.net/calvinxiu/archive/2007/04/28/1588852.aspx
[II--_JBoss MicroKernel]: http://blog.csdn.net/calvinxiu/archive/2007/05/30/1631693.aspx
[Service_--REST_JSON]: http://blog.csdn.net/calvinxiu/archive/2007/06/15/1653414.aspx
[4_--Mule ESB]: http://blog.csdn.net/calvinxiu/archive/2007/06/19/1657989.aspx
[Grizzly 1]: http://azi.javaeye.com/blog/170009
[https_grizzly.dev.java.net_presentations_FISL-2007.pdf]: https://grizzly.dev.java.net/presentations/FISL-2007.pdf
[http_blog.csdn.net_zhangliulin_archive_2007_10_16_1826708.aspx]: http://blog.csdn.net/zhangliulin/archive/2007/10/16/1826708.aspx
[http_spaces.msn.com_members_crmky]: http://spaces.msn.com/members/crmky
[http_cindy.sourceforge.net]: http://cindy.sourceforge.net/
[http_gleamynode.net_dev]: http://gleamynode.net/dev/
[http_www.apache.org_trustin_mina-20050207_index.html]: http://www.apache.org/~trustin/mina-20050207/index.html