部署WAR文件还是“fat” JAR文件？

Question

我注意到很多项目（如DropWizard、Grails等）开始采用“fat” JAR 的概念（使用内嵌的Web服务器，如Jetty或Tomcat），而不是传统的WAR部署。这两种方法都涉及一个单独的JVM进程（即使部署了多个WAR到Tomcat，它们也属于同一个JVM进程）。

在什么情况下，哪种部署方法比另一种更可取？

- AdjustingForInflation

---

传统的WAR-to-Tomcat对于内部应用程序（由内部用户/员工使用）来说是可以的，这些应用程序实际上没有扩展/配置管理需求。但是，一旦您有一个需要面向公众的组件（Web应用程序或REST服务等），您需要按照其自己的速度扩展该组件，并且您需要（好吧，应该）自动配置该组件所在节点的配置（请参见Ansible/Chef/Puppet/Salt等）。在包含不同WAR文件组合的异构节点上实现扩展和CM自动化几乎是不可能的... - smeeb

例如：如果您有10个Tomcat节点和30个WAR文件（代表30个不同的组件），那么为了实现自动化CM，您需要定义节点的类型（DB节点、应用程序节点、微服务节点、缓存节点等），并将相同的子集部署到每个节点类型的30个组件中。但是，您将面临扩展问题，因为在每个Tomcat实例上共享的组件不可避免地具有不同的扩展要求。因此，归根结底就是：您正在部署什么，以及它的要求是什么？ - smeeb

内部组件作为WAR-to-Tomcat是很好的。Web规模的组件需要同质性，而这只能通过所谓的fat JARs来实现。 - smeeb

Answer 1

以下是一些理由：

JAR的优点:

1. 易于构建和部署。
2. 嵌入式服务器例如Jetty很容易操作。
3. 应用程序易于用户启动,并且它们也可以在个人计算机上运行，因为它们很轻巧。
4. 相比于管理Web服务器，启动和停止应用程序所需的知识较少。

WAR或EAR的优点：

1. 服务器可以同时为多个Web应用程序提供部署、重启、安全等功能。
2. 也许一个单独的部署团队可以处理应用程序的启动和停止。
3. 如果你的上级喜欢遵循规则，他们会很高兴发现你没有违反它们。

话虽如此，你总是可以提供2到3种类型的可执行文件以满足所有需求。任何构建工具都可以轻松做到这一点。

- wavicle

Answer 2

分发内嵌Web服务器的应用程序可实现独立设置，只需调用 java -jar application.jar 即可运行。然而，可能有些用户想要控制使用哪个Web服务器，或者想要将多个应用程序部署到单个Web服务器中（例如为了避免端口冲突，特别是端口80和8080）。在这种情况下，“大” jar 文件可能会导致问题，或者至少会有一些不必要的代码，从而增加内存占用。我认为最好的方法是提供两个构件：一个“大” jar 文件，用于更容易地进行独立设置，以及一个仅包含应用程序的 war/ear 文件，供那些希望在自己的容器中部署应用程序的用户使用。

- Thomas

Answer 3

我考虑用户的角度。你可以将这个自包含jar文件封装在.exe或.dmg中，并只需安装它，而无需了解如何部署的其他说明。此外，由于您仅为特定服务器执行部署，因此可以利用该特定服务器的优势。

- Eugene