使用 Fat Jars 优于 Container 的优势答案

【问题标题】：Advantages of using Fat Jars over Containers使用 Fat Jars 优于 Container 的优势
【发布时间】：2020-05-29 13:32:31
【问题描述】：

我想知道这两者之间的区别，以及根据行业标准，目前使用得更多的是哪一个。我尝试在网上查找资源，但关于 Fat Jars 的内容非常少，而且两者之间几乎没有任何对比。

【问题讨论】：

通常你会构建一个 fat jar 并在容器中使用它。
您能否详细说明为什么会这样？为什么我不能只使用一个胖罐，因为据我所知它可以独立部署？

标签： java docker deployment jar containers

【解决方案1】：

乍一看似乎没什么大不了的。原因在于 Java 打包系统非常成熟，并且经过多年的发展壮大。许多其他生态系统并没有从中受益，但可以从打包到容器映像中受益匪浅。但容器不仅仅是包装。包装几乎可以被认为是它的副作用。

其中，使用容器而不是简单的 Fat JARS 的一些好处是：

简化的基础架构

对于围绕微服务构建的大型（或中型）企业，可能并非所有人都使用相同的语言和工具。容器提供了一种以相同方式部署所有这些不同事物的可预测方式，因此它极大地简化了基础架构，从而显着降低了公司成本。这在部署到云中时变得更加重要，尤其是在多云提供商的场景中，在这种情况下，由 Kubernetes 等软件提供的容器编排可以毫不费力地提供很大帮助。

一致性

容器相对于常规 JAR 的另一个好处是跨环境的一致性。例如，假设您将 JAR 部署到 DEV（运行 Java 8）中，然后部署到 PROD（运行 Java 10）中。由于某种原因，JVM 的行为不同，可能是因为默认垃圾收集器或其他原因，导致您的程序在两种环境中的行为不同。当您通过容器镜像部署时，相同的镜像将在不同的环境中使用，因此将始终使用相同的 Java 版本，从而减少出错的可能性。

资源隔离

另一个好处是资源隔离。容器可以确保您的应用程序仅“看到”预定数量的内存和 CPU。实际上，Java 10 在这方面有一些改进，您可以阅读更多关于它的信息here。

希望这可以为这个问题提供更好的观点。

【讨论】：

能否详细说明资源隔离点？查看预定数量的内存和 CPU 有何帮助？
另外，如果您可以详细说明“提供以相同方式部署所有这些不同事物的可预测方式”。你的意思是说无论容器包含什么，它们都以相同的方式部署？
从基础架构管理的角度来看，CPU 使用率会有所帮助，例如，在同一主机上运行多个容器的情况下，可以确保它们不会互相窃取 CPU。更多详情here.
关于可预测性，使用 Java、Node.JS、Go 或其他任何东西编写微服务都没有关系，因为运行它的方式总是通过 docker run（在以 Docker 容器为例）。这对大公司来说是一个优势，因为它为招聘开辟了新的可能性。他们不必只雇用 Java 专家或强迫每个人学习 Java，他们可能会为特定工作使用正确的工具。只要每个团队都有一个容器镜像，所有团队的部署过程都可以完全相同。
当然，这里不是天堂。容器是有成本的，一旦开始支持容器，就需要容器管理（Kubernetes 之类的工具），更多基础设施工具需要学习。它并不总是支付。例如，如果一切都是 Java 并且每个人都对此感到满意，并且部署过程已经到位并且工作正常，那么您可能最好保留它。与往常一样，这是一种权衡。

【解决方案2】：

根据您的需要，您可以使用独立的胖罐或容器内的胖罐。我要说的关键是两者之间没有对峙，实际上它们是互补的。

Fat jar 是包装 java 应用程序的主要方式，因此可以轻松容器化。

当然，您也可以单独使用胖罐子。

容器化的优点：

您可以利用容器的统一工具。即，您设置了 docker，您可以运行任何容器 - 无论是带有 fat jar 的 java 还是 node.js 或其他任何容器。
您可以利用各种容器编排系统（docker compose、docker swarm、kubernetes 等） - 这意味着您可以使用统一工具进行运行状况检查、监控、滚动更新等。
您无需担心系统上的 JRE/JDK 版本等问题。

当您可能仍想独立使用时：

如果您拥有以 Java 为中心的架构并围绕它建立了流程，那么从这种架构转变为现代容器编排的成本会很高。
当您在实例上使用 java 作为主要脚本（或应用程序）平台并且根本不想要任何容器开销时。

【讨论】：