省流
运维喊话：有时间把Tomcat切成Jetty/Underflow
但
如果不是性能敏感到百分之几的地步，没必要切，会徒增全员学习成本问题排查成本。
如果不是微服务特别小，内存CPU单实例给的抠搜，没必要切。一般就是b域m域的后台系统没必要切。
如果有长连接诉求，单独讨论新服务
为什么
从原理上看
网络上易找图
Jetty架构设计之Connector、Handler组件_handler和warapper类-CSDN博客
-
tomcat
-
请求打过来，受理，线程池分发，受理结束返回
-
jetty
-
请求打过来，受理，线程池分发，受理结束返回，殊途同归的逻辑。
-
实际上：
- 不管是Jetty还是Tomcat都殊途同归的实现方式，只是原始需求产生的时代不同，进而设计上存在差异，但差异也不大
- 如：tomcat偏向全能web服务器，所以重量级的设计了容器模型，设计了；而Jetty产生就是为应对个网络服务器能力，所以jetty自身很轻，只管提供一个抽象模型，你想要什么往里填Handler；
- 如：不管你是Jetty还是Tomcat，在有了JAVA NIO基础（channel/buffer/selector那套)，都可以提供对应的模式实现非阻塞调用提升性能，这不是谁家独有的。
- 如：不管你是Jetty还是tomcat，设计上都是要有接收网络请求的，受理分发的，结果返回的。这么套基础流程。同样只是因为tomcat产生的需求就“重”，才会有线程池是否共享，几个连接器，这种没营养的八股问题。
- 如：Tomcat产生的年代还没有容器化云云云这种东西，所以设计一个web服务器会自带容器模式，这是否有些倒果为因了，倒不如说是tomcat演进到现在的容器化；Jetty则轻装上阵只需要专注于网络请求受理。
所以你觉得性能会差很多吗？
-
性能必然有差异，毕竟代码设计也会从编辑到运行期编译轻微影响性能，一个重量级的web容器，一个轻量级的脚手架。
-
什么方法调用链层次，自身管理创建的对象多少，但很轻微啦
- 因为JIT运行时编译，会做一堆优化，什么八股：标量替换，方法内联，机器码替换，栈上分配（可以又水一个基础八股重读文章了）
-
性能差异小
-
资源吃的还少？
那么什么时候确实该切换为Jetty
- 从特性出发，轻，职责单一，对应的就是现状的微服务云云云趋势
- 一个微服务如果足够小，容器核心给多少内存也给的少，这个背景下tomcat重量所带来的内存/CPU损耗占比被放大了，是需要切换jetty的
