从Spring Boot迁移到Quarkus后的启动性能复盘

Spring Boot 以其成熟的生态和开箱即用的体验，成了无数团队的首选。但当业务规模增长、服务实例越铺越多时，“启动慢”和“内存贵”这两座大山，就真切地压在了每个凌晨三点还在等 pod 拉起的运维同学身上。最近我们团队做了一个大胆的决定：把几个核心的 CRUD 微服务从 Spring Boot 2.7 迁移到 Quarkus 3.2。现在跑了一个多月，是时候做一次冷静、不带滤镜的复盘了。

启动数据：不是微调，是降维打击

先说最直观的数字。在同样的 2C4G 的容器规格下，原来 Spring Boot 应用冷启动到端口就绪，平均耗时 12.8 秒，这还是开了 `spring-boot-thin-launcher` 之后的结果。迁移到 Quarkus 后，JVM 模式跑在 `quarkus run` 下，首次启动降到 2.1 秒；如果打成原生可执行文件，0.38 秒直接监听端口。这不是性能优化，这是物种更迭。

更夸张的是内存。Spring Boot 基础空跑常驻堆外 + 堆内加起来轻松吃掉 700MB，而 Quarkus 原生镜像在同样跑一个带数据库连接池、Redis 和 Kafka 生产者的服务，RSS 只有 180MB 左右。这部分省下来的资源，直接让我们的测试环境从原来 8 节点缩到 3 节点，K8s 集群的调度压力和成本肉眼可见地降了。

Per-Request 性能：有得有失，但没翻车

很多人以为 Quarkus 只是启动快，其实它在运行时也做了大量优化。由于构建期完成了类路径扫描、配置注入和字节码增强，请求路径上的反射调用大幅减少。我们用同一个业务接口（查订单列表 + 关联用户 + 返回 JSON）做了压测，Quarkus 原生模式的吞吐量是 Spring Boot 的 1.6 倍，P99 延迟从 85ms 降到了 62ms。

但注意，这里有个坑：Quarkus 的增强是“构建期”的，所以它默认假设你的类不会动态变化。如果你之前写习惯了 Spring Boot 那种“一切皆可反射、运行时随意改 Bean”的代码，迁过来会撞得头破血流。比如我们有个老模块用 `Reflections` 库动态扫描所有带了某个自定义注解的类，在 Quarkus 下直接扫不到——因为原生镜像没有索引这些类。最后只能改成构建期的 `quarkus.index-dependency` 显式注册，或者直接加上 `@RegisterForReflection`。

开发体验：热重载真香，但别指望无缝迁移

Quarkus 的 dev mode 比 Spring Boot DevTools 快一个数量级。改完 Java 代码，几乎是一秒内自动编译并热重载，不像 Spring Boot 要重启整个上下文。这极大改善了本地迭代节奏，配合 Continuous Testing 甚至能做到改一行代码就跑完相关单测，这种反馈闭环用惯了根本回不去。

但迁移过程绝对没有官方文档写得那么轻松。Spring 强大的生态注解，比如 `@Transactional`、`@Cacheable`、`@Async`，Quarkus 里都有对应扩展（如 `@Transactional` 可以直接用，但 `@Async` 需要换成 Mutiny 的 `@RunOnVirtualThread` 或 `@Blocking` 模型），语义不同，写起来总觉得在拧着劲。我们有一个老服务用了 Spring Data JPA 的 `@Query` 复杂投机查询，改成 Quarkus 的 Hibernate ORM Panache 后，虽然接口写法类似，但延迟加载（lazy loading）在原生模式下的行为差异让几个开发差点把键盘摔了。

架构之外的冷思考

这次复盘的最终结论是：Quarkus 不是什么银弹，但它填补了 Java 在云原生时代的一个巨大短板——冷启动和内存占用。如果你做的是 FaaS（函数即服务）、Serverless 短生命周期任务、或者是自动扩缩容时对扩容速度极度敏感的 Web 服务，Quarkus 的收益是压倒性的。但如果你是典型的单体应用、模块之间有大量动态代理和反射依赖，且团队已经深度绑定了 Spring 全家桶的 API 抽象，贸然迁移反而会退化成一个“用 Hibernate 和 RESTEasy 重新写一遍”的重构项目，性价比极低。

对我们而言，迁移后最明显的感受不只是云资源账单变低了，而是发布迭代时不再有那种“需要等 root 就绪才能跑 readiness 探针”的紧张感。每一次代码提交到服务真正可用，时间从以分钟计变成了以秒计。这种体验上的转变，或许才是 Quarkus 给团队带来的最宝贵的东西。