建议部署War文件与带有嵌入式容器的可执行jar

在Java空间中，当前趋势是从以war文件（或ear文件）的形式从将Java Web应用程序部署到Java Servlet容器（或应用程序服务器）转移，而不是将应用程序打包为具有嵌入式servlet / HTTP服务器（如码头）。我的意思是，更新颖的框架影响着新应用程序的开发和部署方式，而不是将应用程序交付给最终用户的方式（例如，我明白了为什么Jenkins使用嵌入式容器，非常容易抓取和使用） ）。采用可执行jar选项的框架示例： Dropwizard，Spring Boot和Play （它不是在servlet容器上运行，而是嵌入了HTTP服务器）。

我的问题是，在一个我们已经将我们的应用程序（到目前为止主要是Struts2）部署到单个tomcat应用程序服务器的环境中，如果我们计划使用嵌入式容器方法，则需要进行哪些更改，最佳实践或注意事项？ ？当前，我们在单个tomcat服务器上运行大约10个本地应用程序，对于这些较小的应用程序，共享资源并在一台服务器上进行管理的能力非常好。我们的应用程序并非旨在分发给最终用户以在其环境中运行。但是，如果我们决定使用更新的Java框架，那么这种方法是否应该改变？越来越多地使用云部署（例如Heroku）是否会促使向可执行jar的转变？

如果您曾经在单一应用程序服务器上以Play部署方式管理传统的War File部署中的多个应用程序，那么请分享您的见解。

一个有趣的问题。这只是我对主题的看法，因此，请带一点盐。我偶尔使用servlet容器和嵌入式服务器来部署和管理应用程序。我敢肯定，使用servlet容器还有很多很好的理由，但是我将尝试着重介绍为什么它们在今天不那么受欢迎。

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

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

另一方面，专用服务器通常功能强大但大小固定，因此您可以在一台计算机上运行多个应用程序以最大程度地利用资源。管理数十个应用程序（每个应用程序都有自己的配置，Web服务器，路由和连接等）并不是一件容易的事，因此使用Servlet容器可以帮助您使所有内容保持可管理性并保持理智。不过，很难扩展。云中的Servlet容器似乎不太有用。必须为每个微型实例设置它们，而不能提供太多价值，因为它们仅管理单个应用程序。

此外，云很酷，非云技术很无聊（如果我们仍然相信炒作的话）。许多框架默认都尝试可伸缩，以便可以轻松地将它们部署到云中。嵌入式服务器的部署和运行速度很快，因此它们似乎是一个合理的解决方案。通常仍支持Servlet容器，但需要更复杂的设置。

其他一些要点：

• 嵌入式服务器可以针对框架进行优化，也可以与框架工具更好地集成（例如播放控制台）。
• 并非所有云环境都附带可自定义的机器映像。与其编写初始化脚本来下载和设置servlet容器，不如使用专用软件进行云应用程序部署要简单得多。
• 我还没有找到一个Tomcat设置，它在您每次重新部署应用程序时都不会因perm gen空间错误引起您的注意。当您几乎可以立即在登台实例和生产实例之间进行切换而不会造成任何停机时，花一点时间来（重新）启动嵌入式服务器是没有问题的。
• 正如问题中已经提到的，对于最终用户而言，仅运行应用程序非常方便。
• 嵌入式服务器是便携式的，便于开发。如今，一切都很快，需要尽快创建和交付原型和MVP。没有人愿意花太多时间为每个开发人员设置环境。