部署 WAR 还是“胖”JAR？

Posted 2023-02-18

【中文标题】部署 WAR 还是“胖”JAR？

【英文标题】：Deploy WAR or "fat" JAR?

【发布时间】：2014-05-30 03:51:18

【问题描述】：

我注意到很多项目（DropWizard、Grails 等）开始接受“胖”JAR（使用像 Jetty 或 Tomcat 这样的嵌入式 Web 服务器）的概念，而不是传统的 WAR 部署。两种方法都涉及单个 JVM 进程（即，无论向 Tomcat 部署多少 WAR，都是同一个 JVM 进程）。

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

【问题讨论】：

传统的 WARs-to-Tomcat 适用于没有真正具有扩展/配置管理需求的内部应用程序（由内部用户/员工使用）。第二个您有一个需要面向公众的组件（Web 应用程序或 REST 服务等），您需要以自己的速度扩展该组件，并且您需要（嗯，应该）自动化组件所在节点的配置（参见 Ansible/Chef/Puppet/Salt/etc.）。在包含不同 WAR 文件组合的异构节点上实现扩展和 CM 自动化几乎是不可能的......

...例如：如果您有 10 个 Tomcat 节点和 30 个 WAR 文件（代表 30 个不同的组件），那么要实现自动化 CM，您需要定义节点的 types （数据库节点、应用程序节点、微服务节点、缓存节点等）并将 30 个组件的相同子集部署到每个节点类型。但是你会遇到扩展问题，因为每个 Tomcat 实例上共享的组件不可避免地会有不同的扩展要求。所以它归结为：你在部署什么，它的要求是什么？

内部组件与 WAR-to-Tomcat 一样好。 Web 规模的组件需要同质化，而这只能通过这些所谓的胖 JAR 来干净地实现。

【参考方案1】：

以下是一些原因：

支持 JAR：

易于构建和部署。 Jetty 等嵌入式服务器易于操作。 应用程序对于用户来说很容易启动，并且它们也可以在他们的个人计算机上运行，​​因为它们是轻量级的。 与管理 Web 服务器相比，启动和停止应用程序所需的知识更少。

支持 WAR 或 EAR：

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

话虽如此，您始终可以提供 2 或 3 种类型的可执行文件来满足所有需求。任何构建工具都可以轻松完成。

【参考方案2】：

使用嵌入式网络服务器分发应用程序允许通过调用java -jar application.jar 进行独立设置和运行。

但是，可能有些用户想要控制使用哪个 Web 服务器或想要将多个应用程序部署到单个 Web 服务器中（例如，为了防止端口冲突，尤其是与端口 80 和 8080 的冲突）。在这种情况下，一个“胖”的 jar 可能会导致问题，或者至少会导致一些不需要的代码，从而导致更大的内存占用。

恕我直言，对于这两种情况，最好的方法是提供两个工件：一个用于（更容易）独立设置的“胖”jar，以及一个适用于希望在自己的容器中部署应用程序的应用程序的 war/ear。

【参考方案3】：

我正在考虑用户视角。您可以在 .exe 或 .dmg 中包装这个自包含 jar，然后直接安装它，而无需额外说明如何部署。此外，由于您只为特定服务器进行部署，因此您可以利用该特定服务器