微服务框架之争--Spring Boot和Quarkus

最新推荐文章于 2024-08-19 00:55:31 发布

2401_85393711

最新推荐文章于 2024-08-19 00:55:31 发布

阅读量346

点赞数 4

分类专栏：资料公粽号文章标签：微服务 spring boot 网络

本文链接：https://blog.csdn.net/2401_85393711/article/details/140192663

版权

资料公粽号专栏收录该内容

14 篇文章 0 订阅

订阅专栏

关于其他指标，结论并不是那么显而易见。因此，我们需要更深入地了解一下。

CPU

我们看到 JVM 版本在预热阶段开始时消耗更多的 CPU。之后CPU使用率趋于稳定，所有版本的消耗相对均等。

以下是 JVM 和 Native 版本中 Quarkus 的 CPU 消耗：

JVM 版的 Quarkus ↑↑↑

Native 版的 Quarkus ↑↑↑

内存

内存就更复杂了。首先，很明显，两个框架的 JVM 版本都为Heap（堆）预留了更多内存。尽管如此，Quarkus 从一开始就预留了较少的内存，启动期间的内存利用率也是如此。

然后，查看测试期间的利用率，我们可以观察到Native版本似乎不像 JVM 版本那样有效或频繁地回收内存。可以通过调整一些参数来改善这一点，在这个比较中，我们使用了默认参数，并没有对 GC、JVM 选项或任何其他参数进行更改。

让我们看一下内存使用图：

Spring Boot JVM ↑↑↑

Quarkus JVM ↑↑↑

Spring Boot 原生 ↑↑↑

Quarkus 原生 ↑↑↑

在测试期间尽管Quarkus出现了更高的峰值，但确实消耗的内存资源更少。

响应时间

最后，关于响应时间和峰值使用的线程数，Spring Boot 似乎略微具有优势。它能够使用更少的线程处理相同的负载，同时还具有更好的响应时间。

Spring Boot Native 版本在这种情况下表现出更好的性能。但是让我们看看每个版本的响应时间分布：

Spring Boot JVM ↑↑↑

尽管有更多异常值，但 Spring Boot JVM 版本随着时间的推移取得了最好的进展，这很可能是由于 JIT 编译器优化。

Quarkus JVM ↑↑↑

Spring Boot 原生 ↑↑↑

Quarkus 原生 ↑↑↑

Quarkus 在低资源利用率方面表现出强大的实力。然而，至少在这个实验中，Spring Boot 在吞吐量和响应能力方面与Quarkus旗鼓相当。

这两个框架都能够处理所有请求而没有任何错误。不仅如此，他们的表现也十分相似，并没有太大的差距。

总而言之

考虑到所有因素，在实现 Java 应用程序时，这两个框架都是很好的选择。

Native程序速度快且资源消耗低，是无服务器、短期（short-living）应用和资源消耗敏感环境的绝佳选择。

另一方面，JVM 应用程序似乎有更多的开销，但随着时间的推移具有出色的稳定性和高吞吐量，非常适合健壮、长寿命的应用程序。

测试程序的代码和用于测试它们的脚本可以在 GitHub 上找到。

从 Spring 转换到 Quarkus

随着K8s的兴起，对原生应用支持良好的Quarkus框架也越来越受到关注很多开发人员在考虑从 Spring 转换到 Quarkus。然而，开发人员在开始评估新的框架时通常必须搁置他们现有的知识。幸运的是， Quarkus 不一样，因为它是由一群在 Java 技术方面具有深厚专业知识的工程师创建的。这包括 Spring API 兼容性，创建Quarkus的工程师同时也是在 Red Hat Runtime 上为 Spring Boot 提供支持的工程师。

我是 Spring 开发者，为什么要选Quarkus？

越来越明显的是，容器化，尤其是 Kubernetes，正在迫使人们重新评估 Java ，用于开发云原生应用程序。 Kubernetes 是一种高度动态的共享基础设施。由于集群中托管的应用程序数量的增长以及对应用程序生命周期变化的响应能力的提高（例如重新部署和向上/向下扩展），基础设施的投入变得更加划算。传统的 Java 云原生运行时在现有的栈上增加了新的分层，而没有真正重新考虑底层。这导致更大的内存消耗和更慢的启动时间，以至于现在很多公司为了从 Kubernetes 集群的大量投资中获得更多价值，愿意放弃他们深厚的 Java 专业知识，为 Go 和 Node.js 重新培养人才和开发工具。

传统云原生 Java 栈 ↑↑↑

这正是 Quarkus 解决的问题。 Quarkus 针对内存使用率和快速启动时间进行了优化。与其他云原生 Java 栈相比，在 JVM 上运行的 Quarkus 应用可以在相同数量的RAM中提供近两倍的应用程序实例，并且当打包为原生二进制文件时，实例数量增加了 7 倍。这不仅仅是使用 SubstrateVM（GraalVM 的一个特性）简单地编译为原生二进制文件。 Quarkus 专为 Kubernetes 的基础设施优化了传统的 “高度动态”框架，从而降低了内存利用率并加快了初始启动速度，结果是运行时效率的显着提高。这些经过优化且文档齐全的框架称为“扩展”，由同类最佳的标准 API 组成。

运行时效率 ↑↑↑

Quarkus 栈 ↑↑↑

我司为什么要从 Spring Boot 迁移到 Quarkus？

以我们公司为例，我司的旧系统基于 Spring 和 Tomcat。当我们维护和部署时，这个传统的框架给我们带来了一些困扰，基于以下原因我们决定迁移到Quarkus：

内存和 CPU 消耗：对于正在执行的操作，Spring 和 Tomcat 框架在应用的主要目的之外使用了过多的资源。
预热时间：Spring 应用程序可能需要 10-20 秒的时间才能启动，之后应用程序才可以开始预热。
无用的代码：作为开发人员，我们都讨厌样板代码（boilerplate code）。
测试：Quarkus 让编写单元测试和集成测试变得非常容易。只需在那里打一个@QuarkusTest 注释，它实际上会启动整个应用程序以运行您的测试。
横向扩展（Scale-out） vs. 纵向扩展（Scale-up）：每个应用程序越小（资源方面），我们可以添加的越多。在这里横向可扩展性胜出。
学习曲线：Quarkus 的在线文档非常简单易懂。

Spring 开发者可以活用哪些现有知识？

Quarkus 的 Spring API 兼容性包括 Spring DI、Spring Web 和 Spring Data JPA。同时也在计划其他 Spring API，如 Spring Security 和 Spring Config。在 JVM 上运行时，Quarkus 应用程序几乎可以利用任何 Java 库。只要不使用 Java 反射，这些Java库就可以编译为原生。例如，受 Spring 开发人员欢迎的 Lombok 库就可以原生编译。需要明确的是，Quarkus 中的 Spring API 兼容性并非为了作为一个完整的 Spring 平台来重新托管现有的 Spring 应用程序。目的是为了让基于 Quarkus 开发新应用程序成为一种自然的入门体验。结合预先优化的扩展，Quarkus 为微服务开发提供了大量的功能。很多开发人员已成功将 Spring 应用程序迁移到 Quarkus。

Spring 框架本质上是高度动态的。为了解决这个问题，Quarkus的Spring 兼容性扩展将 Spring API 映射到现有扩展中的 API，这些扩展已经针对快速启动、降低内存利用率和原生编译进行了优化，例如 RestEasy 和 CDI。此外，Quarkus的Spring 兼容性扩展不使用 Spring 应用程序上下文。由于这些原因，尝试使用额外的 Spring 库可能不会奏效。

Quarkus Spring Web Example

import java.util.List;

import java.util.Optional;

import org.springframework.web.bind.annotation.*;

@RestController

@RequestMapping(“/person”)

public class PersonController {

@GetMapping(path = “/greet/{id}”, produces = “text/plain”)

public String greetPerson(@PathVariable(name = “id”) long id) {

String name=“”;

// …

return name;