摘录网上一些Jetty相关的介绍便于快速了解Jetty。
Jetty 目前的是一个比较被看好的 Servlet 引擎,它的架构比较简单,也是一个可扩展性和非常灵活的应用服务器,它有一个基本数据模型,这个数据模型就是 Handler,所有可以被扩展的组件都可以作为一个 Handler,添加到 Server 中,Jetty 就是帮你管理这些 Handler。
Jetty 作为一个独立的 Servlet 引擎可以独立提供 Web 服务,但是它也可以与其他 Web 应用服务器集成,所以它可以提供基于两种协议工作,一个是 HTTP,一个是 AJP 协议。
如果将 Jetty 集成到 Jboss 或者 Apache,那么就可以让 Jetty 基于 AJP 模式工作
Jetty 创建接受连接环境需要三个步骤:
- 创建一个队列线程池,用于处理每个建立连接产生的任务,这个线程池可以由用户来指定,这个和 Tomcat 是类似的。
- 创建 ServerSocket,用于准备接受客户端的 socket 请求,以及客户端用来包装这个 socket 的一些辅助类。
- 创建一个或多个监听线程,用来监听访问端口是否有连接进来。
相比 Tomcat 创建建立连接的环境,Jetty 的逻辑更加简单,牵涉到的类更少,执行的代码量也更少了。Jetty 的入口是 Server 类,Server 类启动完成了,就代表 Jetty 能为你提供服务了。它到底能提供哪些服务,就要看 Server 类启动时都调用了哪些组件的 start 方法。
基于 AJP 工作
通常一个 web 服务站点的后端服务器不是将 Java 的应用服务器直接暴露给服务访问者,而是在应用服务器,如 Jboss 的前面在加一个 web 服务器,如 Apache 或者 nginx,我想这个原因大家应该很容易理解,如做日志分析、负载均衡、权限控制、防止恶意请求以及静态资源预加载等等。
这种架构下 servlet 引擎就不需要解析和封装返回的 HTTP 协议,因为 HTTP 协议的解析工作已经在 Apache 或 Nginx 服务器上完成了,Jboss 只要基于更加简单的 AJP 协议工作就行了,这样能加快请求的响应速度。
在正常的企业级应用中,Jetty 作为一个 Servlet 引擎都是基于 AJP 协议工作的。
https://www.ibm.com/developerworks/cn/java/j-lo-jetty/
更多的介绍集成可以自己网上搜索。
与Tomcat的比较
Jetty更轻量级。这是相对Tomcat而言的。
单纯比较 Tomcat 与 Jetty 的性能意义不是很大,只能说在某种使用场景下,它表现的各有差异。因为它们面向的使用场景不尽相同。从架构上来看 Tomcat 在处理少数非常繁忙的连接上更有优势,也就是说连接的生命周期如果短的话,Tomcat 的总体性能更高。
而 Jetty 刚好相反,Jetty 可以同时处理大量连接而且可以长时间保持这些连接。例如像一些 web 聊天应用非常适合用 Jetty 做服务器,像淘宝的 web 旺旺就是用 Jetty 作为 Servlet 引擎。
另外由于 Jetty 的架构非常简单,作为服务器它可以按需加载组件,这样不需要的组件可以去掉,这样无形可以减少服务器本身的内存开销,处理一次请求也是可以减少产生的临时对象,这样性能也会提高。另外 Jetty 默认使用的是 NIO 技术在处理 I/O 请求上更占优势,Tomcat 默认使用的是 BIO,在处理静态资源时,Tomcat 的性能不如 Jetty。
作为一个标准的 Servlet 引擎,它们都支持标准的 Servlet 规范,还有 Java EE 的规范也都支持,由于 Tomcat 的使用的更加广泛,它对这些支持的更加全面一些,有很多特性 Tomcat 都直接集成进来了。但是 Jetty 的应变更加快速。
Jetty更满足公有云的分布式环境的需求,而Tomcat更符合企业级环境。
Google 应用系统引擎最初是以 Apache Tomcat 作为其 webserver/servlet 容器的,但最终将切换到 Jetty 上。Google选择Jetty的关键原因是它的体积和灵活性。 在云计算里,体积的因素是很重要,如果你运行几万个Jetty的实例(Google就是这样干的),每个server省1兆,那就会省10几个G的内存(或能够给其他应用提供更多的内存)。
Jetty 被设计成了可插拔和可扩展的特性,这样Google就可以高度的自定义它。 他们在其中替换了他们自己的HTTP connector,Google认证,以及他们自己的session集群。也真是奇怪,这个特性对于云计算来说是非常出色的,但同时也让Jetty非常适合嵌入小的设备中,例如手机和机顶盒。
相同点:
- Tomcat和Jetty都是一种Servlet引擎,他们都支持标准的servlet规范和JavaEE的规范。
不同点:
-
-
-
架构比较
Jetty的架构比Tomcat的更为简单
Jetty的架构是基于Handler来实现的,主要的扩展功能都可以用Handler来实现,扩展简单。
Tomcat的架构是基于容器设计的,进行扩展是需要了解Tomcat的整体设计结构,不易扩展。 -
性能比较
Jetty和Tomcat性能方面差异不大
Jetty可以同时处理大量连接而且可以长时间保持连接,适合于web聊天应用等等。
Jetty的架构简单,因此作为服务器,Jetty可以按需加载组件,减少不需要的组件,减少了服务器内存开销,从而提高服务器性能。
Jetty默认采用NIO结束在处理I/O请求上更占优势,在处理静态资源时,性能较高 -
少数非常繁忙;Tomcat适合处理少数非常繁忙的链接,也就是说链接生命周期短的话,Tomcat的总体性能更高。
Tomcat默认采用BIO处理I/O请求,在处理静态资源时,性能较差。 -
其它比较
Jetty的应用更加快速,修改简单,对新的Servlet规范的支持较好。
Tomcat目前应用比较广泛,对JavaEE和Servlet的支持更加全面,很多特性会直接集成进来。
-
-
Springboot默认集成的是Tomcat ,如果想换成Jetty容器,首先则需要把默认的Tomcat容器去除,然后引入Jetty依赖:
修改pom.xml
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jetty</artifactId> </dependency>
保存更新后发现下载很慢,于是中断下载,准备切换下载源使用阿里的maven镜像。
先查看build path中 libraries下面maven依赖管理下载的文件存放位置,发现很多jetty相关文件未下载成功。
先找到maven的本地setting.xml
在Maven中提供了一个settings.xml文件来定义Maven的全局环境信息。这个文件会存在于Maven的安装目录的conf子目录下面,或者是用户家目录的.m2子目录下面。我们可以通过这个文件来定义本地仓库、远程仓库和联网使用的代理信息等。
其实相对于多用户的PC机而言,在Maven安装目录的conf子目录下面的settings.xml才是真正的全局的配置。而用户家目录的.m2子目录下面的settings.xml的配置只是针对当前用户的。当这两个文件同时存在的时候,那么对于相同的配置信息用户家目录下面的settings.xml中定义的会覆盖Maven安装目录下面的settings.xml中的定义。用户家目录下的settings.xml文件一般是不存在的,但是Maven允许我们在这里定义我们自己的settings.xml,如果需要在这里定义我们自己的settings.xml的时候就可以把Maven安装目录下面的settings.xml文件拷贝到用户家目录的.m2目录下,然后改成自己想要的样子。
settings文件内容
<?xml version="1.0" encoding="UTF-8"?> <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <mirrors> <!--阿里云仓库 --> <mirror> <id>alimaven</id> <mirrorOf>central</mirrorOf> <name>aliyun maven</name> <url>http://maven.aliyun.com/nexus/content/repositories/central/</url> </mirror> <!--中央仓库1 --> <mirror> <id>repo1</id> <mirrorOf>central</mirrorOf> <name>Human Readable Name for this Mirror.</name> <url>http://repo1.maven.org/maven2/</url> </mirror> <!-- 中央仓库2 --> <mirror> <id>repo2</id> <mirrorOf>central</mirrorOf> <name>Human Readable Name for this Mirror.</name> <url>http://repo2.maven.org/maven2/</url> </mirror> </mirrors> </settings>
保存update maven
启动程序之后却出现错误提示。 Unable to start embedded container; nested exception is java.lang.NoClassDefFoundError: org/apache/juli/logging/LogFactory
此处踩坑花了不少时间去找原因:为什么jetty会引用tomcat里的jar包。
多方查找原因是缺少了jar包,jetty9.0之后开始依赖了tomcat-juli ,我用的jetty版本时9.4.6 。网上搜索 tomcat-juli maven
http://mvnrepository.com/artifact/org.apache.tomcat/tomcat-juli/8.5.20
只需要在pom中加入下列依赖即可。
<dependency> <groupId>org.apache.tomcat</groupId> <artifactId>tomcat-juli</artifactId> <version>8.5.20</version> </dependency>
用maven console可以查看 maven 下载日志,以防下载失败。
重新启动程序,ok