Jetty和Tomcat

最近在学习Gitee里面的Star项目，发现有些项目已经开始使用Jetty，大致查了一下发现，Google已经放弃了Tomcat，把一些服务迁移到了Jetty上，对于这个黑马，我挺感兴趣的，所以把它的大致情况也整理分享下：

Jetty是什么，背后是哪家公司提供技术支持？（部分解释来自其官网）
如果我们在网上搜索会发现，其实Jetty的全称是Eclipse Jetty，它是Eclipse提供的Web服务器和javax.servlet容器，以及对HTTP / 2，WebSocket，OSGi，JMX，JNDI，JAAS和许多其他集成的支持。这些组件是开源的，可用于商业用途和分发。

Eclipse Jetty用于开发和生产中的各种项目和产品。Jetty可以轻松嵌入到设备，工具，框架，应用程序服务器和集群中。有关Jetty的更多用途，请参阅Jetty Powered页面。

目前推荐使用的版本是Jetty 9，可以在Jetty下载页面上获得。 另外还有Jetty 8和Jetty 7的最新维护版本，

Jetty项目自2009年以来一直在Eclipse基金会托管。在此之前，Jetty的早期版本部分或完全存在于Codehaus和Sourceforge的Jetty项目中。其特征及应用大致说明如下：

具体的下载地址是： https://www.eclipse.org/jetty/download.html

关于Jetty在Windows下的安装部署可详细访问以下CDSN伙伴的网站，再次不做赘余介绍：

https://blog.csdn.net/Angelia620/article/details/84636090

 

Jetty和Tomcat的对比说明：
Jetty更轻量级。这是相对Tomcat而言的。 
由于Tomcat除了遵循Java Servlet规范之外，自身还扩展了大量JEE特性以满足企业级应用的需求，所以Tomcat是较重量级的，而且配置较Jetty亦复杂许多。但对于大量普通互联网应用而言，并不需要用到Tomcat其他高级特性，所以在这种情况下，使用Tomcat是很浪费资源的。这种劣势放在分布式环境下，更是明显。换成Jetty，每个应用服务器省下那几兆内存，对于大的分布式环境则是节省大量资源。而且，Jetty的轻量级也使其在处理高并发细粒度请求的场景下显得更快速高效。

jetty更灵活，体现在其可插拔性和可扩展性，更易于开发者对Jetty本身进行二次开发，定制一个适合自身需求的Web Server。相比之下，重量级的Tomcat原本便支持过多特性，要对其瘦身的成本远大于丰富Jetty的成本。用自己的理解，即增肥容易减肥难。

然而，当支持大规模企业级应用时，Jetty也必须要扩展，在这场景下Tomcat便是更优的。

相同点：
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的支持更加全面，很多特性会直接集成进来

Jetty的特性及适用场景说明：
 
根据Jetty的特性分析，我们可以发现，Jetty在互联网企业，分布式环境下，在处理高并发细粒度请求的场景下，更加灵活、高效，同时支持做二次开发，可组件进行灵活的重构或增减

在对于大规模企业级应用时，因Jetty需要进行扩展，而Tomcat则可拿来即用，更方便些。但在云计算等云化服务越来越盛行的时代，相信Jetty会有更加广阔的应用场景，同时其开源、简单、灵活的特性，也会为其更加广泛的应用铺路，小而美，比大而全，会更具有竞争优势

 

建议：

所以赶快学起来吧，当前阶段可以根据实际需要，自由选择，以业务场景为主要衡量目标