Quarkus vs Spring：性能、开发者体验和生产权衡：第1部分

Source: Dev.to

背景

自从 Spring Boot 出现以来，它就成为了 Java Web 开发者的事实标准后端框架，这要归功于它对开发者友好的生态系统、自动配置的魔法以及开箱即用的启动方式（Spring starter）。

在云时代，出现了其他若干框架，例如 Micronaut 和 Quarkus。本文聚焦于 Quarkus，探讨它与 Spring Boot 的区别、为何云采纳促使公司重新思考框架选择，以及 Spring 对 Quarkus 的回应是什么。

Spring Boot 内部实现

Spring 在自动配置时大量使用反射，以提供出色的开发者体验。通过 stereotype、组件扫描、使用 @Bean 为容器外的类声明 bean 的配置文件、Spring Data JPA 接口等，均通过反射实现自动配置。Spring 在运行时创建代理来搭建 Spring 容器，这导致内存占用高且应用启动速度较慢。

为了说明这一点，考虑一下在使用 Spring 时可能遇到的典型 BeanCreationException（参见官方 Javadoc）。该异常发生在 Spring 尝试在启动时创建应用上下文、解析所有依赖并在各自作用域中实例化 bean 时。它表明 Spring bean 是在应用上下文初始化期间运行时创建的。

对云部署的影响

组织正转向微服务架构以提升可靠性和可扩展性。系统被部署到云环境，以降低相较于本地基础设施的成本，并利用大量即用即配的选项来满足各种使用场景。

根据领域驱动设计原则，一个单体被拆分为多个微服务。每个微服务通常会运行多个副本实例，每个实例都有自己的计算和内存资源。想象一下在云上运行数百甚至上千个微服务的系统；每个 pod 都会消耗内存和计算资源，导致云费用飙升。

现在再考虑一种平均 快约 10 倍、内存使用 只有 1/10 的替代方案。成本节约是显著的，尽管可能会在开发者体验上有所折中。这正是 Quarkus 所承诺的价值。

展望

我们已经简要审视了 Spring 的内部工作原理以及它在与云环境集成时面临的挑战。下一部分，我们将探讨 Quarkus 如何应对这些云挑战，以及 Spring 团队正在采取哪些措施来缓解这些问题。