java - 部署到 Web 容器、捆绑 Web 容器或嵌入 Web 容器

Question

我正在开发一个需要尽可能简单地为最终用户安装的应用程序。虽然最终用户可能是经验丰富的 Linux 用户(或销售工程师)，但他们对 Tomcat、Jetty 等并不真正了解，我认为他们也不应该了解。

所以我看到了 3 种部署应用程序的方法。我还应该声明，这是我必须部署的第一个具有 Web 界面的应用程序，因此我以前从未真正遇到过这个问题。

首先是将应用程序部署到现有的 Web 容器中。由于我们只部署到 Suse 或 RedHat，这似乎很容易做到。然而，我们并不赞同在一个 Web 容器中运行多个应用程序的想法。这使得仅删除一个应用程序变得更加困难。

下一个选项是仅捆绑 Tomcat 或 Jetty，并让启动/关闭脚本启动我们捆绑的 Web 容器。

或者第三，嵌入..这可能会提供与第二个选项相同的用户体验。

我很好奇其他人在遇到这个问题时会怎么做，以使其对最终用户而言尽可能简单易懂。

我几乎排除了部署到现有 Web 容器的可能性，因为我们经常喜欢设置每个应用程序的资源限制和 CPU 亲和性，我相信这会影响部署到 Web 容器/应用程序服务器中的所有应用程序，而不仅仅是特定的应用程序.

谢谢。

Answer 1

部署多个 war 文件(或在完整的 Java EE 应用程序服务器的情况下部署 ear 文件)是一个曾经是 promise 的想法，但在实践中并没有很好地发挥作用。

一个主要问题是，尽管取得了重大进展，但 EAR 的 WAR 的热重载仍然存在问题。内存泄漏、资源泄漏、类加载器问题……它们一直在发生。因此，最安全的重新部署方法是重新启动整个 servlet 容器或应用程序服务器，但这会关闭在其上运行的所有其他应用程序。

将多个应用程序部署到单个 AS 的第二个问题是它们之间只是一个薄薄的隔离层。应用程序可以从其他应用程序访问 JNDI 中的资源。这对于协作应用程序可能不是问题，但对于可能相互敌对的应用程序来说确实是个问题。

一般来说，servlet 容器并不能替代多任务、隔离的操作系统。

随着像 Xen 这样廉价而高效的虚拟化产品的出现，每个 servlet 容器只有一个应用程序(实际上是捆绑它们)并将它们部署到 Xen 客户端似乎是一个更好的选择。

这样做的另一个好处是，它提供了一种更简单的途径来升级您的应用程序所依赖的库。如果您将 Tomcat 6 的固定安装视为部署平台，那么单个应用程序不能仅从 Tomcat 7 升级到 Servlet 3.0，因为这会影响在同一 Tomcat 上运行的所有其他应用程序。这对于像 JBoss AS 这样的完整 Java EE 堆栈来说更为重要，因为它们捆绑了更多的库。

在实践中，这通常意味着使用运行多个应用程序的固定 Tomcat，您永远无法升级您的应用程序以利用 Tomcat 提供的更新的库/api，因为总会有一些其他应用程序出于某种原因或其他原因无法升级。这很快就会变成一场噩梦。