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

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) 怎么样，一段时间后看看它的表现会很有趣，不是吗？