Jetty一个开源的servlet容器
Jetty 是一个用 Java 实现、开源、基于标准的,并且具有丰富功能的 Http 服务器和 Web 容器,可以免费的用于商业行为。Jetty 这个项目成立于 1995 年,现在已经有非常多的成功产品基于 Jetty,比如 Apache Geromino, JBoss, IBM Tivoli, Cisco SESM 等。Jetty 可以用来作为一个传统的 Web 服务器,也可以作为一个动态的内容
Jetty 是一个用 Java 实现、开源、基于标准的,并且具有丰富功能的 Http 服务器和 Web 容器,可以免费的用于商业行为。Jetty 这个项目成立于 1995 年,现在已经有非常多的成功产品基于 Jetty,比如 Apache Geromino, JBoss, IBM Tivoli, Cisco SESM 等。Jetty 可以用来作为一个传统的 Web 服务器,也可以作为一个动态的内容服务器,并且 Jetty 可以非常容易的嵌入到 Java 应用程序当中。
特性
易用性
易用性是 Jetty 设计的基本原则,易用性主要体现在以下几个方面:
通过 XML 或者 API 来对Jetty进行配置;默认配置可以满足大部分的需求;将 Jetty 嵌入到应用程序当中只需要非常少的代码;
可扩展性
在使用了 Ajax 的 Web 2.0 的应用程序中,每个连接需要保持更长的时间,这样线程和内存的消耗量会急剧的增加。这就使得我们担心整个程序会因为单个组件陷入瓶颈而影响整个程序的性能。但是有了 Jetty:
即使在有大量服务请求的情况下,系统的性能也能保持在一个可以接受的状态。利用 Continuation 机制来处理大量的用户请求以及时间比较长的连接。 另外 Jetty 设计了非常良好的接口,因此在 Jetty 的某种实现无法满足用户的需要时,用户可以非常方便地对 Jetty 的某些实现进行修改,使得 Jetty 适用于特殊的应用程序的需求。
易嵌入性
Jetty 设计之初就是作为一个优秀的组件来设计的,这也就意味着 Jetty 可以非常容易的嵌入到应用程序当中而不需要程序为了使用 Jetty 做修改。从某种程度上,你也可以把 Jetty 理解为一个嵌入式的Web服务器。
Jetty 可以作为嵌入式服务器使用,Jetty的运行速度较快,而且是轻量级的,可以在Java中可以从test case中控制其运行。从而可以使自动化测试不再依赖外部环境,顺利实现自动化测试。
工作原理
下面的内容就从jetty工作原理来解释为什么Jetty具备这些特性:
Jetty 目前的是一个比较被看好的 Servlet 引擎,它的架构比较简单,也是一个可扩展性和非常灵活的应用服务器,它有一个基本数据模型,这个数据模型就是 Handler,所有可以被扩展的组件都可以作为一个 Handler,添加到 Server 中,Jetty 就是帮你管理这些 Handler。
下图是 Jetty 的基本架构图,整个 Jetty 的核心组件由 Server 和 Connector 两个组件构成,整个 Server 组件是基于 Handler 容器工作的,它类似与 Tomcat 的 Container 容器,Jetty 与 Tomcat 的比较在后面详细介绍。Jetty 中另外一个比不可少的组件是 Connector,它负责接受客户端的连接请求,并将请求分配给一个处理队列去执行。如图:
Handler
前面所述 Jetty 主要是基于 Handler 来设计的,Handler 的体系结构影响着整个 Jetty 的方方面面。下面总结了一下 Handler 的种类及作用:
Jetty 的 Continuation 机制
讨论 Jetty 的 Continuation 机制,首先需要提到 Ajax 技术,Ajax 技术是当前开发 Web 应用的非常热门的技术,也是 Web 2.0 的一个重要的组成部分。Ajax 技术中的一个核心对象是 XMLHttpRequest 对象,这个对象支持异步请求,所谓异步请求即是指当客户端发送一个请求到服务器的时候,客户端不必一直等待服务器的响应。这样就不会造成整个页面的刷新,给用户带来更好的体验。而当服务器端响应返回时,客户端利用一个 Javascript 函数对返回值进行处理,以更新页面上的部分元素的值。但很多时候这种异步事件只是在很小一部分的情况下才会发生,那么怎么保证一旦服务器端有了响应之后客户端马上就知道呢,我们有两种方法来解决这个问题,一是让浏览器每隔几秒请求服务器来获得更改,我们称之为轮询。二是服务器维持与浏览器的长时间的连接来传递数据,长连接的技术称之为 Comet。
大家很容易就能发现轮询方式的主要缺点是产生了大量的传输浪费。因为可能大部分向服务器的请求是无效的,也就是说客户端等待发生的事件没有发生,如果有大量的客户端的话,那么这种网络传输的浪费是非常厉害的。特别是对于服务器端很久才更新的应用程序来讲,比如邮件程序,这种浪费就更是巨大了。并且对 Server 端处理请求的能力也相应提高了要求。如果很长时间才向 Server 端发送一次请求的话,那么客户端就不能的得到及时的响应。
如果使用 Comet 技术的话,客户端和服务器端必须保持一个长连接,一般情况下,服务器端每一个 Servlet 都会独占一个线程,这样就会使得服务器端有很多线程同时存在,这在客户端非常多的情况下也会对服务器端的处理能力带来很大的挑战。
Jetty 利用 Java 语言的非堵塞 I/O 技术来处理并发的大量连接。 Jetty 有一个处理长连接的机制:一个被称为 Continuations 的特性。利用 Continuation 机制,Jetty 可以使得一个线程能够用来同时处理多个从客户端发送过来的异步请求,以达到jetty高性能的特点。
部署应用程序
将自己的应用程序部署到 Jetty 上面是非常简单的,首先将开发好的应用程序打成 WAR 包放到 Jetty 的 Webapps 目录下面。然后用如下的命令来启动 Jetty 服务器:Java –jar start.jar
, 在启动服务器后。我们就可以访问我们的应用程序了,Jetty 的默认端口是 8080,WAR 的名字也就是我们的应用程序的WebRoot。例如一个典型的 URL 就是:http://127.0.0.1:8080/demo/index.jsp 。
Jetty 的安全性
为了防止任何人都有权限去关闭一个已经开启的 Jetty 服务器, 我们可以通过在启动 Jetty 服务器的时候指定参数来进行控制,使得用户必须提供密码才能关闭 Jetty 服务器,启动 Jetty 服务器的命令如下所示:
java -DSTOP.PORT=8079 -DSTOP.KEY=mypassword -jar start.jar
这样,用户在停止 Jetty 服务器的时候,就必须提供密码“mypassword”。
maven集成
在maven中,用plugin的方式使用jetty,需要改动maven的setting.xml文件,才可以使用命令mvn jetty:run.setting.xml中找到标签
<pluginGroups>1<pluginGroup>org.mortbay.jetty</pluginGroup>
Jetty和Tomcat为目前全球范围内最著名的两款开源的webserver/servlet容器。由于它们的实现都遵循Java Servlet规范,一个Java Web应用部署
于两款容器的任意一个皆可。但选择哪个更优?也许这得看场景。
很多人关注Jetty,也许主要是因为GAE放弃了Tomcat而选择了Jetty。于是,以很直接的想法,Jetty更符合GAE的需求、即云环境的需求,亦分布式
环境的需求。
1.Jetty更轻量级。这是相对Tomcat而言的。
由于Tomcat除了遵循Java Servlet规范之外,自身还扩展了大量JEE特性以满足企业级应用的需求,所以Tomcat是较重量级的,而且配置较
Jetty亦复杂许多。但对于大量普通互联网应用而言,并不需要用到Tomcat其他高级特性,所以在这种情况下,使用Tomcat是很浪费资源的。这种劣
势放在分布式环境下,更是明显。换成Jetty,每个应用服务器省下那几兆内存,对于大的分布式环境则是节省大量资源。而且,Jetty的轻量级也
使其在处理高并发细粒度请求的场景下显得更快速高效。
2.Jetty更灵活,体现在其可插拔性和可扩展性,更易于开发者对Jetty本身进行二次开发,定制一个适合自身需求的Web Server。
相比之下,重量级的Tomcat原本便支持过多特性,要对其瘦身的成本远大于丰富Jetty的成本。用自己的理解,即增肥容易减肥难。
3.然而,当支持大规模企业级应用时,Jetty也许便需要扩展,在这场景下Tomcat便是更优的。
Google选择Jetty的关键原因是它的体积和灵活性。 在云计算里,体积的因素是很重要,如果你运行几万个Jetty的实例,每个server省1兆,那就会省10几个G的内存(或能够给其他应用提供更多的内存)。
Jetty 被设计成了可插拔和可扩展的特性,这样Google就可以高度的自定义它。 他们在其中替换了他们自己的HTTP connector,Google认证,以及他们自己的session集群。也真是奇怪,这个特性对于云计算来说是非常出色的,但同时也让Jetty非常适合嵌入小的设备中,例如手机和机顶盒。
总结:Jetty更满足公有云的分布式环境的需求,而Tomcat更符合企业级环境。
更多推荐
所有评论(0)