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

Question

java领域目前似乎有一种趋势，即不再以war文件(或ear文件)的形式将java web应用程序部署到java servlet容器(或应用程序服务器)中，而是将应用程序打包为具有嵌入式servlet/HTTP服务器(如jetty )的可执行jar。我的意思是，更新的框架正在影响新应用程序的开发和部署方式，而不是如何将应用程序交付给最终用户(因为，例如，我知道Jenkins为什么使用嵌入式容器，非常容易抓取和使用)。采用可执行jar选项的框架示例：Dropwizard、Spring Boot和Play (它不在servlet容器上运行，但HTTP服务器是嵌入式的)。

我的问题是，在我们已经将我们的应用程序(到目前为止主要是Struts2)部署到单个tomcat应用程序服务器的环境中，如果我们计划使用嵌入式容器方法，需要进行哪些更改、最佳实践或考虑因素？目前，我们在一台tomcat服务器上运行了大约10个自主开发的应用程序，对于这些小型应用程序来说，能够在一台服务器上共享资源和进行管理是很好的。我们的应用程序不打算分发给最终用户在其环境中运行。然而，如果我们决定利用一个较新的java框架，那么这种方法应该改变吗？向可执行jars的转变是由云部署(例如Heroku)的不断增加所推动的吗？

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

Answer 1

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

简而言之: Servlet容器对于在单个主机上管理多个应用程序非常有用，但对于仅管理单个应用程序似乎没有多大用处。在云环境中，每个虚拟机只有一个应用程序似乎更可取，也更常见。现代框架希望与云兼容，因此转向嵌入式服务器。

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

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

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

其他一些要点：

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