1)Jetty更轻量级。这是相对Tomcat而言的。因为Tomcat除了遵循Java Servlet规范以外,自身还扩展了大量JEE特性以知足企业级应用的需求,因此Tomcat是较重量级的,并且配置较Jetty亦复杂许多。但对于大量普通互联网应用而言,并不须要用到Tomcat其余高级特性,因此在这种状况下,使用Tomcat是很浪费资源的。这种劣势放在分布式环境下,更是明显。换成Jetty,每一个应用服务器省下那几兆内存,对于大的分布式环境则是节省大量资源。并且,Jetty的轻量级也使其在处理高并发细粒度请求的场景下显得更快速高效。
2)Jetty更灵活,体如今其可插拔性和可扩展性,更易于开发者对Jetty自己进行二次开发,定制一个适合自身需求的Web Server。
相比之下,重量级的Tomcat本来便支持过多特性,要对其瘦身的成本远大于丰富Jetty的成本。用本身的理解,即增肥容易减肥难。
3)然而,当支持大规模企业级应用时,Jetty也许便须要扩展,在这场景下Tomcat即是更优的。
总结:Jetty更知足公有云的分布式环境的需求,而Tomcat更符合企业级环境。
GAE放弃了Tomcat,选择了Jetty,正是由于Jetty的体积和灵活性,Google能够更好地定制一个足够小的Java Web Server为其GAE服务。
而Tomcat为知足更多的企业级需求,增长了JEE特性,在服务企业级应用时,它的支持优于Jetty。然而,即便Tomcat性能略优于Jetty,但对于大多非企业级应用而言,配复杂体积庞大的Tomcat显得过于重量级。正由于这个,实验室的云平台实现即是把云平台自己的门户网站放在Tomcat内,而云台托管的Java Web应该是部署在Jetty内的。java
相同点:web
Tomcat和Jetty都是一种Servlet引擎,他们都支持标准的servlet规范和JavaEE的规范。spring
不一样点:tomcat
Jetty的架构比Tomcat的更为简单bash
Jetty的架构是基于Handler来实现的,主要的扩展功能均可以用Handler来实现,扩展简单。服务器
Tomcat的架构是基于容器设计的,进行扩展是须要了解Tomcat的总体设计结构,不易扩展。架构
Jetty和Tomcat性能方面差别不大并发
Jetty能够同时处理大量链接并且能够长时间保持链接,适合于web聊天应用等等。分布式
Jetty的架构简单,所以做为服务器,Jetty能够按需加载组件,减小不须要的组件,减小了服务器内存开销,从而提升服务器性能。spring-boot
Jetty默认采用NIO结束在处理I/O请求上更占优点,在处理静态资源时,性能较高
Tomcat适合处理少数很是繁忙的连接,也就是说连接生命周期短的话,Tomcat的整体性能更高。
Tomcat默认采用BIO处理I/O请求,在处理静态资源时,性能较差。
Jetty的应用更加快速,修改简单,对新的Servlet规范的支持较好。
Tomcat目前应用比较普遍,对JavaEE和Servlet的支持更加全面,不少特性会直接集成进来。
<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>复制代码
2.在Application.java 类中注册jetty容器
@Bean
public EmbeddedServletContainerFactory servletContainer() {
JettyEmbeddedServletContainerFactory factory =
new JettyEmbeddedServletContainerFactory();
return factory;
}复制代码