前段时间， RAM 和磁盘空间是稀缺资源。那时，广泛的策略是将不同的应用程序托管到相同的平台上。那是应用服务器的黄金时代。目前趋向廉价资源的趋势会使其在短期或长期内过时。然而，技术趋势可能会使它重新受到青睐。

当基础架构资源昂贵时，拥有应用服务器是很好的选择，并且跨应用程序共享这些应用服务器会显着降低成本，另一方面，它需要深入了解共享相同资源的每个应用程序的负载以及可以部署在兼容的相同应用程序服务器应用程序上的熟练系统管理员。对于过去来说，是否需要单独运行一个应用程序，因为它管理不善造成资源浪费？当基础架构成本下降时，懒惰和对风险的厌恶优先于它们，并且在应用程序服务器上托管单个应用程序已成为常态。那时，下一个合乎逻辑的步骤就是考虑为什么仍然需要应用程序服务器作为专用组件。看来使用 Spring 的人也得出了同样的结论，对于Spring Boot应用程序来说，默认模式是打包可执行JAR – 也称为胖JAR。这些应用程序可以运行为 Java -jar fat.jar 因此，有言云：

我也没有在这里完全鼓吹Jar方式，因为我相信它很容易丢弃大多数 Ops 团队在应用程序服务器管理方面的专业知识。然而，关于Fat JAR的一个引人注目的观点是，由于引导技术从一开始就负责应用程序管理，它可以以任何想要的方式处理负载类。例如，在开发工具中，Spring Boot提供了一个基于两个类加载器的机制，一个用于库，另一个用于类，这样就可以在不重新启动整个JVM的情况下更改和重新加载类 – 这是一个非常快速的反馈循环，推动代码更迭改变。

它错误地认为应用服务器提供商仍然坚持传统方式 。Wildlfy，TomEE和其他应用服务器实现者可以配置为包装Fat JAR，虽然有一个巨大的差异：没有什么像Spring Dev Tools，所以当代码更改时，仍然需要重新启动整个应用服务器。关于这些变化的更快速反馈的唯一选择是在较低级别工作，例如JRebel整个团队的许可证。但是，仍然有一个使用WAR归档的原因，这就是 Docker 。通过提供一个通用的应用服务器Docker镜像作为基础镜像，只需要在其上添加一个WAR，从而使得WAR镜像非常轻便。然而使用JAR方法无法实现。

请注意，它不是Spring Boot vs JavaEE，但主要是JAR和WAR，因为Spring Boot完全能够打包任一格式，而许多应用服务器提供商也是如此。正如我上面指出的那样，唯一缺少的部分是稍后重新加载类，而不是在发生更改时重新启动整个JVM – 但我相信它会在某个时刻发生。

在WAR和JAR方法之间进行选择非常依赖于公司在开发期间是否重视更快速的反馈周期或更优化和可管理的Docker镜像。