Jetty服务器的简介

一、jetty的特点

jetty被大家冠以最多的词语可能便是灵活性和可扩展性较高的应用服务器，下面我就灵活性和扩展性说说jetty的几个特点：

—灵活性：一般来说，此服务器的默认配置便可以满足日常大部分需求，
但就算你想去配置它也是比较容易的，只需修改相关的xml文件（具体如何配置这里不做介绍，本文只作为jetty的基本概念性介绍）。jetty的嵌入当然也只需少量的代码就可以做到。

—扩展性：主要得益于jetty良好的接口设计。

当然这里补充下，此服务器的灵活的嵌入也应该算是灵活性的一方面吧，应用程序不需为了使用jetty而去做出修改。

二、jetty的基本架构设计

首先，我们需要了解这样一个概念，即基本数据模型，我们也可以称之为handler,这个模型可以被扩展，添加进server里面（jetty的核心组件由Server和Connector两个组件构成，而此处的handler便类似于Tomcat的Container）。

此处可能需要一张结构图，更容易的来了解jetty的结构特征，如下：

对于handler，我要说的是：
jetty中handler分为两种类型：一是HandlerWrapper,一是HandlerCollection。

三、启动过程

因为jetty中所有的组件都会集成LifeCycle，所以server的start方法调用就会调用所有已经注册到server的组件，server启动其他组件的顺序是：首先启动设置到server的handler，通常这个handler会有子handler，这些handler将组成handler链，最后启动Connector,打开端口，接受客户端发来的请求。

四、接受请求

jetty既可以作为一个独立的servlet引擎独立提供web服务，也可以与其他web应用服务器集成，所以它可以提供基于两种协议工作，一是http,一是AJP协议，若将jetty集成到jboss或Apache,那么就可以使用AJP协议。

通常，一个web服务站点的后端服务器不是将java的应用服务器直接暴露给服务访问者，而是在应用服务器，如在jboss的前面加上一个web服务器，如apache、ngnix以便用来做日志分析、负载均衡、权限控制、防止恶意请求以及静态资源的预加载。

在这种架构之下，servlet引擎就不需要解析和封装返回的http协议，因为http协议的解析工作已经在apache、nginx服务器上完成，jboss只需要基于更加简单的ajp协议工作就ok了，这样能加快请求的相应速度。

实际上在AJP处理请求相比较http唯一的不同就是在读取到socket数据包时，如何来转换这个数据包，是按照http协议的包格式就是httpParser,按照ajp协议来解析就是Ajp13Parser。封装返回的数据也是如此。

让jetty工作在AJP协议之下，需要配置connector的实现类：Ajp13SocketConnector,这个类继承了SocketConnector类，覆盖了父类的newConnection方法，为的是创建Ajp13Connection对象而不是HttpConnection。使用Ajp13Parser来解析此协议，处理连接的逻辑都是一样的，只是AJP协议的想率高些，因为其采用的是二进制传输。
所以相比于http文本传输是有一定的优势的。

五、处理请求

前面介绍了 Jetty 可以基于 AJP 协议工作，在正常的企业级应用中，Jetty作为一个 Servlet 引擎都是基于 AJP 协议工作的，所以它前面必然有一个服务器，通常情况下与 Jboss 集成的可能性非常大，这里介绍一下如何与 Jboss集成。
Jboss 是基于 JMX 的架构，那么只要符合 JMX 规范的系统或框架都可以作为一个组件加到 Jboss 中，扩展 Jboss 的功能。Jetty 作为主要的 Servlet 引擎当然支持与 Jboss 集成。具体集成方式如下：

Jetty 作为一个独立的 Servlet 引擎集成到 Jboss 需要继承 Jboss 的AbstractWebContainer类，这个类实现的是模板模式，其中有一个抽象方法需要子类去实现，它是 getDeployer，可以指定创建 web 服务的Deployer。Jetty 工程中有个 jetty-jboss 模块，编译这个模块就会产生一个SAR 包，或者可以直接从官网下载一个 SAR 包。

六、与 Tomcat 的比较

1.基于何种组件

Jetty 的架构从前面的分析可知，它的所有组件都是基于 Handler 来实现，当然它也支持 JMX。但是主要的功能扩展都可以用 Handler 来实现。可以说Jetty 是面向 Handler 的架构，就像 Spring 是面向 Bean 的架构，iBATIS是面向 statement 一样，而 Tomcat 是以多级容器构建起来的，它们的架构设计必然都有一个“元神”，所有以这个“元神“构建的其它组件都是肉身。

2.设计模式的差别

从设计模板角度来看 Handler 的设计实际上就是一个责任链模式，接口类HandlerCollection 可以帮助开发者构建一个链，而另一个接口类ScopeHandler 可以帮助你控制这个链的访问顺序。另外一个用到的设计模板就是观察者模式，用这个设计模式控制了整个 Jetty 的生命周期，只要继承了LifeCycle接口，你的对象就可以交给 Jetty 来统一管理了。所以扩展 Jetty非常简单，也很容易让人理解，整体架构上的简单也带来了无比的好处，Jetty可以很容易被扩展和裁剪。

3.扩展相关性、程度

相比之下，Tomcat 要臃肿很多，Tomcat 的整体设计上很复杂，前面说了Tomcat 的核心是它的容器的设计，从 Server 到 Service 再到 engine 等container 容器。作为一个应用服务器这样设计无口厚非，容器的分层设计也是为了更好的扩展，这是这种扩展的方式是将应用服务器的内部结构暴露给外部使用者，使得如果想扩展 Tomcat，开发人员必须要首先了解 Tomcat 的整体设计结构，然后才能知道如何按照它的规范来做扩展。这样无形就增加了对Tomcat 的学习成本。不仅仅是容器，实际上 Tomcat 也有基于责任链的设计方式，像串联 Pipeline 的 Vavle 设计也是与 Jetty 的 Handler 类似的方式。要自己实现一个 Vavle 与写一个 Handler 的难度不相上下。表面上看，Tomcat 的功能要比 Jetty 强大，因为 Tomcat 已经帮你做了很多工作了，而 Jetty 只告诉，你能怎么做，如何做，有你去实现。

打个比方，就像小孩子学数学，Tomcat 告诉你 1+1=2，1+2=3，2+2=4 这个结果，然后你可以根据这个方式得出 1+1+2=4，你要计算其它数必须根据它给你的公式才能计算，而 Jetty 是告诉你加减乘除的算法规则，然后你就可以根据这个规则自己做运算了。所以你一旦掌握Jetty，Jetty 将变得异常强大。

4.性能

单纯比较 Tomcat 与 Jetty 的性能意义不是很大，只能说在某种使用场景下，它表现的各有差异。因为它们面向的使用场景不尽相同。从架构上来看 Tomcat在处理少数非常繁忙的连接上更有优势，也就是说连接的生命周期如果短的话，Tomcat 的总体性能更高。
而 Jetty 刚好相反，Jetty 可以同时处理大量连接而且可以长时间保持这些连接。例如像一些 web 聊天应用非常适合用 Jetty 做服务器，像淘宝的 web 旺旺就是用 Jetty 作为 Servlet 引擎。
另外由于 Jetty 的架构非常简单，作为服务器它可以按需加载组件，这样不需要的组件可以去掉，这样无形可以减少服务器本身的内存开销，处理一次请求也是可以减少产生的临时对象，这样性能也会提高。另外 Jetty 默认使用的是NIO 技术在处理 I/O 请求上更占优势，Tomcat 默认使用的是 BIO，在处理静态资源时，Tomcat 的性能不如 Jetty。

5.规范

作为一个标准的 Servlet 引擎，它们都支持标准的 Servlet 规范，还有 Java EE 的规范也都支持，由于 Tomcat 的使用的更加广泛，它对这些支持的更加全面一些，有很多特性 Tomcat 都直接集成进来了。但是 Jetty 的应变更加快速，这一方面是因为 Jetty 的开发社区更加活跃，另一方面也是因为 Jetty的修改更加简单，它只要把相应的组件替换就好了，而 Tomcat 的整体结构上要复杂很多，修改功能比较缓慢。所以 Tomcat 对最新的 Servlet 规范的支持总是要比人们预期的要晚。