摘录网上一些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
保存更新后发现下载很慢，于是中断下载，准备切换下载源使用阿里的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文件内容
保存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中加入下列依赖即可。
用maven console可以查看 maven 下载日志，以防下载失败。
重新启动程序，ok
