tomcat jetty undertow 以及 mq的选择

最新推荐文章于 2024-05-08 22:05:21 发布

最爱白嫖 O(∩_∩)O

最新推荐文章于 2024-05-08 22:05:21 发布

阅读量429

点赞数

分类专栏： SpringBoot/Cloud

原文链接：https://editor.csdn.net/md?articleId=104634726

版权

SpringBoot/Cloud 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

常用jar包搜索地址：
阿里云中央仓库下的public仓库
maven 镜像仓库地址大全
springboot 启动容器切换
在该org.springframework.boot.autoconfigure.web.EmbeddedServletContainerAutoConfiguration类中已经配置好


	/** 
     * Nested configuration if Tomcat is being used. 
     */  
    @Configuration  
    @ConditionalOnClass({ Servlet.class, Tomcat.class })  
    @ConditionalOnMissingBean(value = EmbeddedServletContainerFactory.class, search = SearchStrategy.CURRENT)  
    public static class EmbeddedTomcat {  
  
        @Bean  
        public TomcatEmbeddedServletContainerFactory tomcatEmbeddedServletContainerFactory() {  
            return new TomcatEmbeddedServletContainerFactory();  
        }  
  
    }  
  
    /** 
     * Nested configuration if Jetty is being used. 
     */  
    @Configuration  
    @ConditionalOnClass({ Servlet.class, Server.class, Loader.class,  
            WebAppContext.class })  
    @ConditionalOnMissingBean(value = EmbeddedServletContainerFactory.class, search = SearchStrategy.CURRENT)  
    public static class EmbeddedJetty {  
  
        @Bean  
        public JettyEmbeddedServletContainerFactory jettyEmbeddedServletContainerFactory() {  
            return new JettyEmbeddedServletContainerFactory();  
        }  
  
    }  
  
    /** 
     * Nested configuration if Undertow is being used. 
     */  
    @Configuration  
    @ConditionalOnClass({ Servlet.class, Undertow.class, SslClientAuthMode.class })  
    @ConditionalOnMissingBean(value = EmbeddedServletContainerFactory.class, search = SearchStrategy.CURRENT)  
    public static class EmbeddedUndertow {  
  
        @Bean  
        public UndertowEmbeddedServletContainerFactory undertowEmbeddedServletContainerFactory() {  
            return new UndertowEmbeddedServletContainerFactory();  
        }

tomcat jetty undertow 容器比较

为什么很多 SpringBoot 开发者放弃了 Tomcat，选择了 Undertow?

SpingBoot中我们既可以使用Tomcat作为Http服务，也可以用Undertow来代替。Undertow在高并发业务场景中，性能优于Tomcat。所以，如果我们的系统是高并发请求，不妨使用一下Undertow，你会发现你的系统性能会得到很大的提升。并且Undertow新版本默认使用持久连接，这将会进一步提高它的并发吞吐能力。所以，如果是高并发的业务系统，Undertow是最佳选择。

Jetty和Tomcat性能对比

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和Tomcat性能比较

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更符合企业级环境。

mq的选择

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，比 RocketMQ、Kafka 低一个数量级	同 ActiveMQ	10 万级，支撑高吞吐	10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响			topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic	topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性	ms 级	微秒级，这是 RabbitMQ 的一大特点，延迟最低	ms 级	延迟在 ms 级以内
可用性	高，基于主从架构实现高可用	同 ActiveMQ	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据	基本不丢	经过参数优化配置，可以做到 0 丢失	同 RocketMQ
功能支持	MQ 领域的功能极其完备	基于 erlang 开发，并发能力很强，性能极好，延时很低	MQ 功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用

一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；
后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高；
不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache，但 GitHub 上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。
所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。
如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范