NIO服务器框架

NIO 专栏收录该内容
1 篇文章 0 订阅

引用: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的高性能模式。 SpringBPM的整合。      面对这样一个诱人的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开源社区的冰山一角,回望那个只有ICEACE/TAO的孤寂世界.......
二、开动:
1、入门文档
MINA Presentation Materials CXF Architecture Guide Mule Developers GuideMuleCon 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

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值