为什么选择Tomcat而不是Java EE兼容的应用服务器？

Question

为什么选择Tomcat而不是Java EE兼容的应用服务器？

jakarta-eetomcat

39

Java EE应用服务器提供了Tomcat的所有功能，那么为什么要使用Tomcat（而不是官方的GlassFish等）？

特别是当需要使用Java EE功能，如JPA、JAX-RS、JSF等时，应用程序需要打包更多的库，而符合EE规范的应用程序服务器则已经在安装过程中提供了这些库，因此更加方便。

- kgautron

25

倒计时等待春季迷群到来 :-) - fvu

7

如果我理解正确的话，销售人员通常会说：“为什么要使用笨重的JEE，当你可以使用Tomcat + Spring完成同样的工作甚至更多。” - fvu

1

@fvu，有些人就像鹦鹉一样，但是（有时）确实有一个真正的好理由不使用应用服务器。虽然我喜欢Spring。 - Miguel Ping

7

FYI，现在有一款Java EE认证版本的Apache Tomcat，叫做Apache TomEE。 - David Blevins

2

@fvu，春天的粉丝们已经到了:p - Miguel Ping

显示剩余3条评论

7个回答

6

很少有人使用纯Tomcat，他们总是添加大量额外的东西，比如Web框架、ORM、DI框架等等。

你可以使用Spring来完成这个任务，但最终结果会非常庞大、臃肿，并且你将不得不编写大量的XML代码。

现代Java EE 6实现非常轻量化（如TomEE和Resin仅25MB），并包含你所需的一切（Web、持久化、DI）。所谓的Web Profile不包含任何你很少需要的东西。现代Java EE 6服务器启动只需要一两秒钟，与裸Tomcat相同，但它们实际上提供了你每天所需的工具。

- Mike Braun

3

关于Spring - Spring是模块化的，您可以从中选择确切需要的部分（例如spring-core，spring-jdbc，spring-mvc）等等... - Yair Zaslavsky

1

此外，我认为现今的存储容量足够，如果你将精心挑选的 spring-core、spring-jdbc、spring-mvc 和其他 Spring 框架的 jar 文件放置于一起，所需的存储开销并不算大。 - Yair Zaslavsky

10

Spring让你承担了构建堆栈的责任，这不是可选的。许多必要的部分（例如Hibernate或Transactions）甚至不在Spring中，因此您需要到其他地方寻找。使用Java EE，您可以在两个非常好的标准配置文件（Web和Full）之间进行选择，或者如果您确实想要构建自己的堆栈。Java EE中的所有内容都是模块化的。JSF、CDI、EJB等等都可以单独添加到Tomcat或Jetty中。 - Mike Braun

5

现在你可以使用Spring进行Java配置，因此你不需要创建大量的XML文件。 :) 只是说一下... 干杯！ - Disper

@Disper 很高兴听到 Spring 在这方面跟随 Java EE 的引领 ;) - Mike Braun

5

大多数Java EE应用服务器很臃肿，带有许多不需要的功能，并且具有非常慢的开发/测试周期（只需查看Java Rebel的生产力报告即可）。如果您确实需要一些Java EE功能，则应使用它，但在大多数情况下，您可以使用tomcat或任何其他轻量级servlet容器来获得相同的基本功能（基本上是servlet容器，您可以将大多数Java EE技术放在其顶部，例如轻量级ejb容器等）。

此外，请记住，您可以在应用程序服务器之外使用JPA、JSF、JAX-RS。

简而言之，Java EE应用服务器显然很慢，不能实时重新加载类，并强制进行非常烦人的代码/部署/测试周期（考虑在您的Java代码中测试某些更改需要20秒至8分钟左右的时间）。大多数人只需要基本功能（基本上是servlet容器）。

这是2011年关于重新部署时间的报告：http://zeroturnaround.com/java-ee-productivity-report-2011/#redeploy_times

- Miguel Ping

7

FYI，如今几乎所有Java EE服务器的最新版本的平均启动时间为[1-3秒]（http://antoniogoncalves.org/2011/10/20/o-java-ee-6-application-servers-where-art-thou/）。 - David Blevins

1

@DavidBlevins 这是不正确的。这可能只是一个新安装的宣传时间。以下是来自jrebel团队（2011年）的准确报告：http://zeroturnaround.com/java-ee-productivity-report-2011/#redeploy_times - Miguel Ping

2

我完全同意这是事实 -- 当 Arquillian 被创建时，它实际上是使用 OpenEJB 进行演示的，因为 JBoss 太慢了。自从 JBoss 7 以来，他们现在使用 JBoss 进行演示。如果那个 JRebel 报告中包含服务器版本将会很好。 - David Blevins

2

这里是我们（JRebel团队）一直在测量的服务器启动时间的更多信息：http://dow.ngra.de/2010/12/14/jee-oss-container-startup-times-apples-vs-oranges/ 实际上，对于大多数现代应用服务器（如Tomcat或Glassfish），服务器启动时间并不是主要问题。即使是WebSphere在启动时也非常快（请参见Liberty Profile版本）。问题在于应用程序和框架元数据需要很长时间才能初始化（欢迎注解式编程模型）。 - Anton Arhipov

4

在我的电脑上，Jboss EAP 6 的启动时间为0.8秒。使用 JSF、EJB、CDI 和 JPA 的应用程序需要2秒。相似的 Spring 3.1 应用程序需要近10秒，现在谁更轻量级呢？ - Mike Braun

显示剩余2条评论

3

如 @Miguel Ping 所解释的那样，应用服务器包含开发人员不需要的功能。例如，许多开发人员不需要消息传递代码，因此他们不需要 JMS jars。其他开发人员可能不需要集群，因此他们不需要集群代码等等。由于今天大多数 UI 都面向 Web，Servlet 容器成为应用服务器必须提供的一个至关重要的组件，因此许多开发人员决定只使用 Servlet 容器（即 Tomcat）。在这种情况下，许多开发人员使用 Spring 框架来提供他们所拥有的纯 Java EE 功能的替代品（或与 Java EE 集成 - Spring 也可以在应用服务器顶部运行）。“Spring-core” 是轻量级的，并且主要提供依赖注入/控制反转容器（替换了 Java EE 的 EJB 容器）。您可以添加 Spring 框架的其他模块，以为您的应用程序提供更多功能。而在许多应用服务器中（EJB 3.0 及以下版本），应用服务器正在加载整个堆栈，这也会影响应用服务器的启动时间（从个人经验来看，这非常令人恼火）。

话虽如此，EJB 3.1 现在包含配置文件，例如 - web 配置文件，它从 Java EE 规范加载更少的部分。此外，Jboss 在 JBoss AS 7 中引入了并行部署机制，该机制分析应用程序内的依赖关系，并对独立组件执行并行部署。例如，在 oVirt 开源项目中，我们将简单部署虚拟化环境的启动时间从超过1分钟减少到大约3秒钟。
我不知道其他 EJB 3.1 应用服务器是否存在这样的机制，然而，正如前面提到的，您可以很容易地定义配置文件或使用已经存在的配置文件，例如 web 配置文件（EJB lite）以减少启动时间。

总之，在过去，人们主要使用 Tomcat 来减少启动时间和减少加载的模块数量。Spring 提供了一种模块化的 Java EE 开发替代方案，并可与 Tomcat 一起使用。如今，随着 EJB 3.1 的出现，Java EE 也已经采用了模块化，并且有一些应用服务器（如 JBoss AS 7）通过在部署期间进行各种优化来将启动时间缩短到几秒钟。

- Yair Zaslavsky

这并不是真的；Java EE 应用服务器，特别是 Web Profile 版本，包含了每个（Web）应用程序所需的所有功能。另一方面，Tomcat 非常简洁，没有现代应用程序可以仅在 Tomcat 上运行而不使用其他任何东西。 - Mike Braun

6

你的帖子有点不连贯。正确的说法不是“EJB 3.1 应用服务器”，而是“Java EE 应用服务器”。EJB 只是 Java EE 的一部分。接着，你说应用服务器包含开发人员不需要的东西，并且只有一个 Servlet 容器就足够了，然后又开始谈到 Spring 是 Java EE 中某些功能的替代品（因此那些功能显然是需要的）。 - Mike Braun

3

请注意，磁盘上被JMS占用的几个位不会影响启动时间或内存使用；所有现代Java EE应用服务器只会加载实际需要的内容。毫无疑问，在Spring中也有许多并非每个应用程序都会使用的类（在我看来，Spring中这种类有很多）。 - Mike Braun

5

从这个帖子中可以看出，有很多人在恶意传播未曾使用过应用服务器(AS)或从未开发过非玩具应用程序的恐惧、不确定性和疑虑(FUD)。例如，Glassfish只在需要时加载堆栈的组件。例如，只有当您部署了包含EJB的内容时，EJB容器才会启动。同样地，只有在部署了使用JMS的内容时，JMS才会启动。Glassfish 3.1.2的纯启动时间(即没有部署应用程序的启动时间)仅需毫秒级别(在Windows 7，JDK 7 64位虚拟机下)。 - NBW

点赞！我注意到使用花哨、昂贵的应用服务器最常见的原因是人们喜欢在简历上写上它。 - wavicle

显示剩余2条评论

3

Tomcat是一个精心编写的轻量级Servlet容器，为大量JVM Web应用程序提供所需的一切。它在生产环境中作为直接面向浏览器的Web服务器运行良好。对于许多人来说，Java EE包含了太多东西，超出了构建稳定有用应用程序所需的范围。这种类型的人寻找具有更少而不是更多功能，并将稳定编写的代码视为重要。软件选择的世界是一个市场，Tomcat在其中的一部分市场上表现得非常好。就像在任何市场中一样，您需要查看替代方案并选择满足您需求的产品。Tomcat只是众多替代品之一。

本文http://www.people.hbs.edu/cbaldwin/DR2/LaMantia-Cai-MacCormack-Rusnak%20WICSA2008.pdf中有关设计结构矩阵的有趣观点涉及到Tomcat。他们将其与一个未命名的竞争对手进行比较，并发现它设计得很好。如果您有兴趣分析自己的代码，我所知道的唯一DSM实现是IntelliJ企业版，但他们确实提供了几周的免费试用。

个人而言，我认为在支持软件中简洁是一种美德，而Servlet容器是支持软件，而不是您应用程序的一部分。

- Michael Dillon

0

他们认为自己选择轻量级，但实际上他们的应用程序最终会比使用Java EE Web Profile更加沉重。如果他们选择Spring，他们的部署很可能会非常大，构建和服务器启动时间更慢。开发人员的生产力会下降... 如果您希望应用程序尽可能简单和轻量级，请选择支持Web Profile的Java EE服务器。

- John Hogan

0

在大多数情况下，关于应用服务器选择（如Tomcat vs. JBoss等AS）的决策将根据小型IT部门的管理/开发团队的经验和知识进行，并且我认为这是政治问题而非技术问题。此外，大多数部署在Tomcat上的项目通常是具有少量集成概念和复杂性的Web应用程序。对于这样的项目，通常会使用轻量级容器和框架（如Spring、Struts）。但是，如果项目变得更加复杂和分布式，则像可扩展性、监控、高可用性（例如JBoss的@HASingletons）等属性就会出现。然后，将您的普通Tomcat配备第三方框架以获得所有AS功能可能会非常痛苦，并且大多数时候您将面临运行所有这些内容的挑战。

- Erhan Bagdemir

我将回答在云平台（如Amazon Web Services）中使用Tomcat时的一些关注点。通过使用更多资源，可以实现可扩展性（垂直扩展或水平扩展）。例如，在AWS中，可以通过自动缩放Tomcat实例来实现。监控是一个广泛的领域，如果我们谈论JVM监控，可以使用工具来实现。高可用性可以通过故障转移来实现，对于在AWS上的Tomcat应用程序，可以通过Route 53中的简单健康检查来实现。没有任何东西阻止企业应用程序在Tomcat上准备投入生产。 - StackOverFlow User

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- David Blevins · Accepted Answer

我们心中的疑问，也是我们创建 TomEE 的全部原因是，为什么人们必须要做出选择呢？

整个“Tomcat或JavaEE”的问题已经陈旧不堪。

10年过去了，人们仍然争论哪个更好，为什么。事实是：

在Java EE 6中，我们(JCP)创建了Web Profile，正式承认了需要使用一组有限技术的较小运行时环境。

很好，我们已经完成了一半，但人们仍在争论“Tomcat 或 JavaEE”。解决方案很明显，Tomcat需要被Java EE认证。于是Web Profile就应运而生，恰好可以做到这一点。

2011年，我们(Apache)开始进行Apache Tomcat的认证工作。该认证在JavaOne 2011上宣布为Apache TomEE。最终版本于4月份发布。

太棒了，现在我们做到了。

新的现状

有一个更轻量级的JavaEE版本
有一个经过JavaEE认证的Tomcat版本

所有这些都发生在过去的两年中。情况已经改变了。

如果您想要 Tomcat 和 JavaEE，现在可以同时拥有它们。