谁才是微服务赢家:Quarkus 与 Spring Boot

发布于 2022-4-27 20:31
浏览
0收藏

作者 |MicroStone
来源 | 今日头条

在容器时代(“Docker 时代”)Java 仍然处于领先地位,但哪个更好?Spring Boot 还是 Quarkus?谁才是微服务赢家:Quarkus 与 Spring Boot-开源基础软件社区

谁会最先进的?Spring Boot 或 Quarkus。

在容器时代(“ Docker 时代”),无论您是否在使用它,都不可否定java的活力。Java 在性能方面一直比较有优势,主要是因为代码和真实机器之间的抽象层,多平台的成本(一次编写,随处运行 - 还记得吗?),其中包含 JVM -between(JVM:模拟真实机器所做的软件机器)。

如今,使用微服务架构,也没有任何优势,为总是在同一个地方和平台上运行的东西(Docker 容器 - Linux) 环境构建多平台(解释)的东西。可移植性现在不那么重要了(可能比以往任何时候都重要),那些额外的抽象级别并不重要。

话虽如此,让我们对在Java中生成微服务的两种替代方案进行简单而原始的比较:非常知名的Spring Boot和不太知名的(尚未)Quarkus。

反对者

Quarkus是什么?谁才是微服务赢家:Quarkus 与 Spring Boot-开源基础软件社区

一套适用于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是什么?谁才是微服务赢家:Quarkus 与 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"

这将导致我们项目的结构,如下所示:谁才是微服务赢家:Quarkus 与 Spring Boot-开源基础软件社区

请注意,还创建了两个示例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 规范。

这是我们的“整个”应用程序:谁才是微服务赢家:Quarkus 与 Spring Boot-开源基础软件社区

这就是全部,使用下一个命令我们可以看到应用程序正在运行:

mvn clean compile quarkus:dev

在这种模式下,我们也开启了热部署,后台编译。让我们做一个简单的测试来看看:

curl -sw "\n\n" http://localhost:8080/echo/ualter | jq .​

谁才是微服务赢家:Quarkus 与 Spring Boot-开源基础软件社区

现在我们看到它正在工作,让我们创建 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有生成它的收据。谁才是微服务赢家:Quarkus 与 Spring Boot-开源基础软件社区

关于 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

战争谁才是微服务赢家:Quarkus 与 Spring Boot-开源基础软件社区

让我们启动两个容器,让它们启动并运行几次,然后比较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) 怎么样,一段时间后看看它的表现会很有趣,不是吗?

收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐