共计 4352 个字符，预计需要花费 11 分钟才能阅读完成。
在容器时代（“Docker 时代”）Java 依然处于领先地位，但哪个更好？Spring Boot 还是 Quarkus？
谁会最先进的？Spring Boot 或 Quarkus。
在容器时代（“Docker 时代”），无论您是否在应用它，都不可否定 java 的生机。Java 在性能方面始终比拟有劣势，次要是因为代码和实在机器之间的形象层，多平台的老本（一次编写，随处运行 – 还记得吗？），其中蕴含 JVM -between（JVM：模仿实在机器所做的软件机器）。
现在，应用微服务架构，也没有任何劣势，为总是在同一个中央战争台上运行的货色(Docker 容器 – Linux) 环境构建多平台（解释）的货色。可移植性当初不那么重要了（可能比以往任何时候都重要），那些额定的形象级别并不重要。
话虽如此，让咱们对在 Java 中生成微服务的两种代替计划进行简略而原始的比拟：十分出名的 Spring Boot 和不太出名的（尚未）Quarkus。
反对者
Quarkus 是什么？
一套实用于 GraalVM 和 HotSpot 的开源技术 ，用于编写 Java 应用程序。它提供（官网是这么说的）超快的启动工夫和更低的内存占用。这使其成为容器和无服务器工作负载的现实抉择。它应用 Eclipse 微配置文件（JAX-RS、CDI、JSON-P），这是 Java EE 的一个子集来构建微服务。
GraalVM 是一个通用的多语言虚拟机（JavaScript、Python、Ruby、R、Java、Scala、Kotlin）。 GraalVM （特地是 Substrate VM）使提前（AOT）编译成为可能，将字节码转换为本地机器码，从而生成能够本地执行的二进制文件。
请记住，并非所有性能都能够在本机执行中应用，AOT 编译有其局限性。留神这句话（援用 GraalVM 团队）：
咱们运行须要一个关闭世界假如的激进动态剖析，这意味着在运行时可拜访的所有类和所有字节码必须在构建时已知。
因而，例如，反射和 Java 本机接口 (JNI) 将不起作用，至多是开箱即用的（须要一些额定的工作）。您能够在本机 Java 限度文档中找到限度列表。
Spring Boot 是什么？
这是真的吗？好吧，我只想说一句（请跳过），一句话：Spring Boot 构建在 Spring Framework 事实上，是一个开源框架，它提供了一种更简略的形式来构建、配置和运行基于 Web 的 Java 应用程序. 使其成为微服务的良好候选者。
战斗准备——创立 Docker 镜像
Quarkus 镜像
让咱们创立 Quarkus 应用程序，以便稍后将其包装在 Docker 映像中。基本上，咱们将做与 Quarkus 入门 教程雷同的事件。
应用 Quarkus maven 原型创立我的项目：
mvn io.quarkus:quarkus-maven-plugin:1.0.0.CR2:create
-DprojectGroupId=ujr.combat.quarkus
-DprojectArtifactId=quarkus-echo
-DclassName="ujr.combat.quarkus.EchoResource"
-Dpath="/echo"这将导致咱们我的项目的构造，如下所示：
请留神，还创立了两个示例Dockerfile (src/main/docker)：一个用于一般JVM App Image，另一个用于Native App Image。
在生成的代码中，咱们只须要更改一件事，增加上面的依赖项，因为咱们要生成 JSON 内容。
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-resteasy-jsonb</artifactId>
</dependency>Quarkus 在整个 RESTEasy 我的项目实现中应用 JAX-RS 标准。
这是咱们的“整个”应用程序：
这就是全副，应用下一个命令咱们能够看到应用程序正在运行：
mvn clean compile quarkus:dev在这种模式下，咱们也开启了热部署，后盾编译。让咱们做一个简略的测试来看看：
curl -sw "\n\n" http://localhost:8080/echo/ualter | jq .
当初咱们看到它正在工作，让咱们创立 Docker 映像。从这里下载 GraalVM：https\
://github.com/graalvm/graalvm-ce-builds/releases。
重要的！ 不要下载最新版本 19.3.0，它与 Quarkus 1.0 不兼容，兴许 Quarkus 1.1 会。当初应该工作的版本是 GraalVM 19.2.1，失去这个。
配置其环境变量的主门路：
## At macOS will be: export
GRAALVM_HOME=/Users/ualter/Developer/quarkus/graalvm-ce-java8-19.2.1/Contents/Home/而后在你的环境中装置 GraalVM 的 Native Image：
$GRAALVM_HOME/bin/gu install native-image让咱们为以后平台生成本机版本（在这种状况下，将为 macOS 生成本机可执行文件）。
mvn package -Pnative**\
quarkus-echo-1.0-SNAPSHOT-runner ** 如果一切正常，咱们能够在 ./target 文件夹中找到一个名为的文件。这是您的应用程序的可执行二进制文件，您只需运行以下命令即可启动它 \
./target/quarkus-echo-1.0-SNAPSHOT-runner：无需应用 JVM（一般：java -cp app:lib/ :etc App.jar*），它是一个本机可执行二进制文件。
让咱们为咱们的应用程序生成一个 Native Docker Image。该命令将创立一个 Native 镜像，即带有 Linux 原生可执行应用程序的 Docker 镜像。默认状况下，本机可执行的文件是基于以后平台 (macOS) 创立的，因为咱们晓得生成的可执行文件与容器 (Linux) 的平台不同，咱们将批示 Maven 构建从在容器内，生成原生 docker 镜像：
mvn package -Pnative -Dquarkus.native.container-build=true此时，肯定要有一个 Docker 容器运行时，一个工作环境。
该文件将是一个 64 位 Linux 可执行文件，因而很天然，这个二进制文件无奈在咱们的 macOS 上运行，它是为咱们的 docker 容器映像构建的。所以，继续前进 …… 让咱们去生成 docker 图像 ……
docker build -t ujr/quarkus-echo -f src/main/docker/Dockerfile.native .
## Testing it...
docker run -i --name quarkus-echo --rm -p 8081:8081 ujr/quarkus-echo附带阐明，对于 Docker 映像大小：
最终的 docker 镜像是 115MB，然而你能够应用distroless 镜像版本 来制作一个很小的 Docker 镜像。Distroless 映像仅蕴含您的应用程序及其运行时依赖项，其余所有内容（包管理器、shell 或规范 Linux 发行版中常见的一般程序）都将被删除。咱们应用程序的 Distroless 映像大小为42.3MB。该文件 \
./src/main/docker/Dockerfile.native-distroless 有生成它的收据。
对于 Distroless Images：“将运行时容器中的内容严格限度为应用程序所需的内容是 Google 和其余在生产环境中应用容器多年的科技巨头采纳的 最佳实际”
spring boot 镜像
到此，想必大家都晓得如何制作一个一般的 Spring Boot Docker 镜像了，咱们就略过细节吧？只是一个重要的察看，代码是完全相同的。更好的说法是，简直雷同，因为咱们应用的是 Spring 框架注解，当然。这是惟一的区别。您能够查看提供的源代码中的每个细节（上面的链接）。
mvn install dockerfile:build
## Testing it...
docker run --name springboot-echo --rm -p 8082:8082 ujr/springboot-echo比照
让咱们启动两个容器，让它们启动并运行几次，而后比拟 Startup Time 和Memory Footprint。
在这个过程中，每个容器都被创立和销毁 10 次。起初，剖析了它们的启动工夫及其内存占用。上面显示的数字是基于所有这些测试的均匀后果。
启动工夫
显然，当波及到可扩展性 和无服务器架构 时，这方面可能会施展重要作用。
对于 Serverless 架构，在此模型中，通常一个长期容器将由事件触发以执行工作 / 性能。在云环境中，价格通常基于执行次数，而不是之前购买的一些计算容量。因而，这里的 冷启动 可能会影响这种类型的解决方案，因为容器（通常）只会在执行其工作时才处于活动状态。
在可扩展性中，很显著，如果须要忽然向外扩大，启动工夫将定义容器齐全筹备好（启动并运行）以响应出现的加载场景所需的工夫。
场景有多 忽然 （须要和疾速）， 长时间冷启动 的状况可能更糟。
让咱们看看它们在启动工夫方面的体现：
好吧，您可能曾经留神到它是在启动工夫图中插入的另一个测试选项。实际上，它与 Quarkus 应用程序完全相同，但应用 JVM Docker 映像（应用 Dockerfile.jvm）生成。正如咱们所看到的，即便是应用 Docker Image 和 JVM Quarkus 应用程序的应用程序也比 Spring Boot 具备更快的启动工夫。
毋庸置疑，Quarkus Native 应用程序显然是赢家，它是迄今为止启动速度最快的应用程序。
内存占用
当初，让咱们检查一下内存的状况。查看每个容器应用程序在启动时须要耗费多少内存，以使本人启动并运行，筹备好接管申请。
论断
总之，这就是咱们在 Linux Ubuntu 中看到的后果：
看起来 Quarkus 博得了这两轮较量（启动工夫和内存脚印），以显著的劣势战败了对手 SpringBoot。
这可能会让咱们感到纳闷……兴许是时候思考一些真正的测试、教训，并尝试应用 Quarkus。咱们应该看看它在现实生活中的体现如何，它如何适宜咱们的业务场景，以及最有用的中央。
然而，咱们不要遗记毛病，正如咱们在下面看到的，JVM 的某些性能在本机可执行二进制文件中（还 / 很容易）无奈工作。无论如何，兴许是时候给 Quarkus 一个证实本人的机会了，特地是如果冷启动问题始终困扰着你。在环境中应用一两个装备 Quarkus 的 Pod (K8s) 怎么样，一段时间后看看它的体现会很乏味，不是吗？
