docker|谁才是微服务王者：Quarkus 与 Spring Boot( 二 ) spring|Java|jvm

://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 应用程序显然是赢家，它是迄今为止启动速度最快的应用程序。
内存占用现在，让我们检查一下内存的情况。检查每个容器应用程序在启动时需要消耗多少内存，以使自己启动并运行，准备好接收请求。