jvm/jre不能被重用。您可能会觉得在应用服务器环境中运行会更好。与在jsse上运行相比，docker将有更高的开销
与此相比，只运行docker的优势越来越小。
一些优势可能是：
测试
在不同的jre版本上快速测试代码
自动化测试。使用dockerfile，您的ci/cd管道可以检出代码、编译代码、旋转docker映像、运行测试并输出junit格式的测试报告。
具有一致的环境（依赖注入（如jks、config等）、操作系统版本、jre等）
按配置的环境。
您不必花时间安装os、jre等，这是您选择的源代码管理系统中的一个配置文件。
这使得灾难恢复更加容易
迁移得到简化（部分）
在编排好的环境中运行paas的优点（例如仅使用kubernetes、openshift或类似的工具）是（除了基本docker之外）：
可能做金丝雀部署
在同一台或多台机器上进行路由、扩展和负载平衡，以根据机器优化使用情况（有些操作的jre性能会滞后于某些最佳点）

一个胖jar文件和一个打包包一样好，可以使用maven build捆绑所有依赖项
它没有它能得到的那么好。
你的应用程序可能有很多依赖项：spring、tomcat等等。在任何企业应用程序中，最终工件的大小将由99%的依赖项和1%的代码组成。这些依赖关系可能很少更改，只有当您添加一些功能或决定升级版本时，而您的代码更改非常频繁。
胖jar意味着每次部署时，每次推送到repo主机（例如nexus）时，都是在浪费时间上载或下载每次99%相同的内容。它只是一个愚蠢的压缩文件。
docker是一种更聪明的格式。它有层的概念，因此您可以（并且被鼓励）将一个层用于依赖项，将另一个层用于代码。这意味着如果依赖层没有改变，就不必再次部署它，或者在部署中再次更新它。
因此，您可以拥有更快的ci构建，从而减少repo主机中的磁盘空间，并且可以更快地安装。您还可以使用这些层更容易地验证您的假设，即只有业务代码发生了更改。

如果您有一个使用已建立的技术的工作部署系统，那么您绝对应该继续使用它，即使有更新和更闪亮的东西。javaapp服务器空间已经非常成熟和成熟，如果您有一个纯jvm应用程序和一个工作设置，那么即使docker容器现在已经存在，也不要离开这个设置。
正如您所注意到的，docker映像包含jvm、应用程序服务器、库依赖项和应用程序。如果您有多个映像，它们是正确分层的，并且这些细节完全匹配，那么它们就可以被共享，但是还有一种非常现实的可能性，即一个映像的jvm或基本linux发行版的补丁版本比另一个略新。总的来说，我认为docker生态系统广泛地假设应用程序“只”使用几十兆字节的磁盘或内存并不是很大的开销；这与经典的java生态系统有很大区别，在传统的java生态系统中，多个应用程序将在单个进程内的单个共享jvm上运行。

# This base image will be shared between derived images; _if_ the

# version/build matches exactly

FROM tomcat:10-jdk11

# These libraries will be shared between derived images; _if_ the

# _exact_ set of files match _exactly_, and Tomcat is also shared

COPY target/libs/*.jar /usr/local/tomcat/lib

# This jar file presumably won't be shared

COPY target/myapp.jar /usr/local/tomcat/webapps

如果您需要将非jvm服务合并到整个系统中，我会开始研究容器。如果您有一个java组件、一个节点组件和一个python组件，并且它们都通过http进行通信，那么docker将使它们也都以相同的方式进行部署，而哪一部分使用哪种语言并不重要。尝试留在jvm生态系统中（如果java/kotlin/groovy/scala等jvm本机语言不能满足您的需要，那么可以使用jruby或jython等基于jvm的语言实现）对于您描述当前设置的方式是有意义的。