Java 建议部署war文件与嵌入容器的可执行jar

java领域的当前趋势似乎是不再以war文件（或ear文件）的形式将java web应用程序部署到java servlet容器（或应用程序服务器），而是使用嵌入式servlet/HTTP服务器（如jetty）将应用程序打包为可执行jar。我的意思是，更新的框架正在影响新应用程序的开发和部署方式，而不是如何将应用程序交付给最终用户（因为，例如，我了解Jenkins为什么使用嵌入式容器，非常容易获取和使用）。采用可执行jar选项的框架示例： ，和（它不是在servlet容器上运行，而是嵌入了HTTP服务器）

我的问题是，在我们已经将应用程序（到目前为止主要是Struts2）部署到单个tomcat应用程序服务器的环境中，如果我们计划使用嵌入式容器方法，需要进行哪些更改、最佳实践或考虑事项？目前，我们有大约10个在单个tomcat服务器上运行的自主开发的应用程序，这些应用程序非常小 共享资源和在一台服务器上管理的能力很好。我们的应用程序不打算分发给最终用户，以便在其环境中运行。然而，如果我们决定利用一个更新的java框架，这种方法是否应该改变？云部署（如Heroku）的使用增加是否刺激了向可执行JAR的转变

---

如果您有过在单个应用服务器上以播放式部署方式管理多个应用程序而不是传统war文件部署方式管理多个应用程序的经验，请分享您的见解。

一个有趣的问题。这只是我对这个话题的看法，所以对一切都持保留态度。我偶尔会使用servlet容器和嵌入式服务器部署和管理应用程序。我确信使用servlet容器仍然有很多很好的理由，但我将试着只关注为什么它们在今天不那么流行

简短版本：Servlet容器非常适合在一台主机上管理多个应用程序，但对于仅管理一个应用程序似乎不是很有用。在云环境中，每个虚拟机一个应用程序似乎更可取，也更常见。现代框架希望与云兼容，因此转向嵌入式服务器

---

所以我认为云服务是放弃servlet容器的主要原因。就像servlet容器允许您管理应用程序一样，云服务允许您管理虚拟机、实例、数据存储等等。这听起来更复杂，但在云环境中，已经转向了单应用程序机器。这意味着您可以将整个机器视为应用程序。每个应用程序都在具有适当大小的计算机上运行。云实例可以随时弹出和消失，这对缩放非常有利。如果应用程序需要更多的资源，则可以创建更多的实例

另一方面，专用服务器通常功能强大，但大小固定，因此可以在一台机器上运行多个应用程序，以最大限度地利用资源。管理几十个应用程序——每个应用程序都有自己的配置、web服务器、路由和连接等——并不有趣，因此使用servlet容器可以帮助您保持一切可管理性和理智。然而，它更难扩展。云中的Servlet容器似乎不是很有用。它们必须针对每个微小的实例进行设置，而不会提供太多的价值，因为它们只管理单个应用程序

此外，云很酷，而非云的东西很无聊（如果我们仍然相信炒作的话）。许多框架在默认情况下都试图实现可伸缩性，以便能够轻松地部署到云中。嵌入式服务器部署和运行速度很快，因此看起来是一个合理的解决方案。Servlet容器通常仍然受支持，但需要更复杂的设置

其他几点：

• 嵌入式服务器可以针对框架进行优化，或者更好地与框架工具集成（例如play console）
• 并非所有云环境都具有可定制的机器映像。使用专用软件部署云应用程序比编写初始化脚本下载和设置servlet容器简单得多
• 我还没有找到一个Tomcat安装程序，它不会每隔几次重新部署你的应用程序就会出现perm gen space错误。当您几乎可以立即在暂存实例和生产实例之间切换而无需任何停机时，花更长的时间（重新）启动嵌入式服务器并不是问题
• 正如问题中已经提到的，最终用户只需运行应用程序就非常方便了
• 嵌入式服务器具有便携性，便于开发。今天，一切都是快速的，原型和MVP需要尽快创建和交付。没有人愿意花太多时间为每个开发人员建立一个环境

  ---

感谢您的回答，您提出了一些好的观点。云是驱动因素！在我们的情况下，拥有一台云服务器（Amazon Web服务模型，即基础设施即服务）比只部署应用程序（即谷歌应用程序引擎，即平台即服务），我会感觉更舒服，但我认为这是一种老派思想。因此，要点是：除非我们计划在一个平台上利用云作为一种服务方式，否则war部署是可行的，而不是在一台服务器上管理多个独立的JavaWeb应用程序。再次感谢您的输入。仅2CC：您可以在单个机器上运行多个JAR应用程序，其中一些轻量级HTTP服务器作为代理，即：NGIX，它还可以用于典型的Web流量，如定制的CDN、负载均衡器、防火墙等。因此，在规划大型业务时考虑使用它是合理的。