Java 部署到web容器、捆绑web容器或嵌入web容器

我正在开发一个应用程序，需要尽可能简单地为最终用户安装。虽然最终用户可能是经验丰富的Linux用户（或销售工程师），但他们对Tomcat、Jetty等一无所知，我认为他们也不应该这样做

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

首先是将应用程序部署到现有的web容器中。由于我们只部署到Suse或RedHat，这似乎很容易做到。然而，我们并不热衷于在一个web容器中运行多个应用程序。这使得只下载一个应用程序变得更加困难

下一个选项是捆绑Tomcat或Jetty，让启动/关闭脚本启动捆绑的web容器

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

我很好奇，当其他人面对这个问题时，他们会做些什么，以使最终用户尽可能做到万无一失

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

谢谢。

看一下

它可以部署到现有的web容器中，也可以简单地使用“java-jarhudson.war”运行。对于Windows，如果以管理员权限运行，则可以将自身注册为服务

---

在我看来，将web应用程序和servlet容器（Tomcat或Jetty）一起分发并不是不常见的选择。您获得的好处是：完全控制web应用程序的配置，最终用户不关心配置细节。然而，缺点之一是增加了安装包的大小。

部署多个war文件（如果是完整的JavaEE应用程序服务器，则部署ear文件）是一个曾经是一个承诺的想法，但在实践中没有得到很好的实施

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

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

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

由于Xen等廉价高效的虚拟化产品的可用性，每个servlet容器只有一个应用程序（实际上，将它们捆绑起来）并将其部署到Xen客户端似乎是一个更好的选择

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

---

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

谢谢你的回答。似乎捆绑（或在某些情况下嵌入）是前进的方向。您提到的许多不利因素也可能是有利因素，这取决于具体情况。如果您想要100%的隔离，那么您所说的是正确的，但在许多情况下，目的是有目的地共享。是的，如果您的“应用程序”不是真正的单个应用程序，而是更像协作的应用程序模块，那么您确实可能想要共享资源。在某种程度上，部署多个EAR或WAR的能力可以被视为单个应用程序中的一个额外层次。对于在同一硬件上托管多个JVM，您建议的最小占地面积是多少？这取决于您的设置。单个操作系统上的多个JVM为您节省了额外操作系统的一些内存开销，但您可能会在配置每个Tomcat或JBoss AS等以使用不同的端口集时遇到更多问题。但现在的内存非常便宜，所以在入门级服务器上安装8GB内存的成本几乎不比2GB贵。如果您托管8个XEN客户端，那么每个XEN客户端将有1GB的内存，每个JVM将有768MB的内存。如果您的应用程序真的很简单，那么每个JVM可能会低至64 MB，每个XEN客户端可能会低至128 MB。这将允许您在一台服务器上运行大约64个应用程序。