在Java空间中，当前似乎有一种趋势，是从以war文件（或ear文件）的形式从将Java Web应用程序部署到Java servlet容器（或应用程序服务器）转移，而不是将应用程序打包为具有以下内容的可执行jar：嵌入式码头servlet / HTTP服务器，如码头。我的意思是，更新颖的框架影响着新应用程序的开发和部署方式，而不是将应用程序交付给最终用户的方式（例如，我知道Jenkins为什么使用嵌入式容器，非常容易抓取和使用） ）。采用可执行jar选项的框架示例： Dropwizard，Spring Boot和Play （它不是在servlet容器上运行，而是嵌入了HTTP服务器）。
我的问题是，在一个我们已经将我们的应用程序（到目前为止主要是Struts2）部署到单个tomcat应用程序服务器的环境中，如果我们计划使用嵌入式容器方法，则需要做出哪些更改，最佳实践或注意事项？ ？当前，我们在单个tomcat服务器上运行大约10个本地应用程序，对于这些较小的应用程序，共享资源并在一台服务器上进行管理的能力非常好。我们的应用程序并非旨在分发给最终用户以在其环境中运行。但是，如果我们决定使用更新的Java框架，那么这种方法是否应该改变？越来越多地使用云部署（例如Heroku）是否促使向可执行jar的转变？
如果您曾经在单一应用程序服务器上以Play部署方式管理传统的war文件部署多个应用程序的经验，请分享您的见解。
一个有趣的问题。这只是我对主题的看法，因此，一切都吃一盐。我偶尔使用servlet容器和嵌入式服务器来部署和管理应用程序。我敢肯定，使用servlet容器还有很多很好的理由，但我将尝试着重介绍为什么它们在今天不那么受欢迎。
简短版：Servlet容器非常适合在单个主机上管理多个应用程序，但似乎对仅管理一个应用程序不是很有用。在云环境中，每个虚拟机一个应用程序似乎更可取，并且更为常见。现代框架希望与云兼容，因此要转向嵌入式服务器。
因此，我认为云服务是放弃servlet容器的主要原因。就像servlet容器使您可以管理应用程序一样，云服务使您可以管理虚拟机，实例，数据存储等。这听起来更复杂，但是在云环境下，已经转向了单应用程序计算机。这意味着你经常可以把整机像它 的 应用程序。每个应用程序都在具有适当大小的计算机上运行。云实例可以随时弹出并消失，这对于扩展很有用。如果应用程序需要更多资源，则可以创建更多实例。
另一方面，专用服务器通常功能强大但大小固定，因此您可以在一台计算机上运行多个应用程序以最大程度地利用资源。管理数十个应用程序（每个应用程序都有自己的配置，Web服务器，路由和连接等）并不是一件容易的事，因此使用Servlet容器可以帮助您使所有内容保持可管理性并保持理智。但是，很难扩展。云中的Servlet容器似乎不太有用。必须为每个微型实例设置它们，而不能提供太多价值，因为它们仅管理单个应用程序。
另外，云很酷，非云技术很无聊（如果我们仍然相信炒作的话）。许多框架默认都尝试可扩展，以便可以轻松地将它们部署到云中。嵌入式服务器的部署和运行速度很快，因此它们似乎是一个合理的解决方案。通常仍支持Servlet容器，但需要更复杂的设置。
其他一些要点：
