从「Supersonic Subatomic Java」到 Build-Time Augmentation一篇讲透 Quarkus 的设计哲学、内核机制与生产落地。一、为什么还需要 QuarkusJava 的云原生欠账传统 Java 企业栈Servlet Spring Boot 重量级应用服务器是为长生命周期单体应用设计的启动一次跑几个月JIT 预热后吞吐极高。但 Kubernetes / Serverless / Scale-to-Zero 的世界有三个新约束启动要快Pod 扩容、Lambda 冷启动按毫秒计费内存要小RSS 占用直接决定节点密度和云账单镜像要小、依赖要少容器分层、CVE 面、拉取耗时都受影响Spring Boot 在 JVM 模式下依然要干这些事扫 classpath、解析注解建 BeanDefinition、织入 AOP 代理反射创建实例、绑定配置初始化 DataSource / Web Server / MQ 连接这些工作在每次启动都重做一遍。Quarkus 的核心赌注是——把上面 80% 的工作挪到构建期Build Time运行时只跑已经烤好的蛋糕而不是每次现做。Quarkus 官方定位Kubernetes Native Java Stack为 GraalVM 和 HotSpot 量身定制。二、Quarkus 是什么不是另一个 SpringQuarkus 是一个构建期增强Augmentation 运行时极简引导的全栈 Java 框架由 Red Hat 发起现已归入 Commonhaus FoundationApache 2.0 协议开源。它的技术拼图层选型编程模型Jakarta CDI-LiteArC、JAX-RSRESTEasy、MicroProfile响应式核心Vert.x Mutiny数据层Hibernate ORM / Panache、Agroal 连接池构建机制自研 Augmentation 引擎 Gizmo 字节码生成原生编译GraalVM Native ImageAOT配置MicroProfile Config统一application.properties扩展生态800 官方/社区 ExtensionsKafka、OIDC、OTel、AWS、LangChain4j 等关键点Quarkus 不排斥标准反而重度依赖 Jakarta EE / MicroProfile 标准让你用看起来像 EE的注解写代码但跑起来像 Go。三、核心原理Build-Time Augmentation两阶段模型这是 Quarkus 区别于 Spring/Micronaut 的最底层设计。3.1 传统框架的单阶段模型编译 → 打包 jar → 启动 JVM → 运行时扫描/反射/建代理 → 服务可用代价启动慢、反射元数据常驻内存、GraalVM 难以做封闭世界分析。3.2 Quarkus 的两阶段模型阶段一构建期 Augmentation关键所有 Extension 拿到Jandex索引注解/类关系已建好解析ApplicationScoped、Path、Entity、application.properties在编译期算出哪些 Bean 存在、注入关系是什么、JAX-RS 路由表、Hibernate 映射、Health 端点用Gizmo 直接生成字节码Recorder 模式把启动时要做的事写成普通 Java 调用指令死代码、未用 Bean、多余反射入口全部消除阶段二运行时 Bootstrap加载生成的引导类直接new出已确定好的对象图不再扫包、不再反射建代理在 Native 模式下这部分连 JVM 都不需要是 GraalVM 闭世界里的纯机器码用 Quarkus 团队的话说Do the work once, not at each start.ArCQuarkus 的 DI 容器在构建期就把依赖图解析完运行时 ArC 核心只有 Weld 的约 7% 类数/体积且构建期就能报出UnsatisfiedResolutionException不会等到生产启动才炸。四、依赖注入ArC 与 CDI-LiteQuarkus 的 DI 不是 Spring IoC也不是完整 Weld而是ArC——一个面向构建期的 CDI 2.0/4.1 子集实现。ApplicationScoped public class OrderService { final TaxService taxService; OrderService(TaxService taxService) { // 单构造器Inject 可省 this.taxService taxService; } ConfigProperty(name order.fee, defaultValue 5.0) double fee; public double total(double amount) { return amount amount * taxService.rate() fee; } } Path(/orders) public class OrderResource { Inject OrderService service; // 字段注入也行但构造器更 Native 友好 GET Produces(MediaType.TEXT_PLAIN) public String hi() { return ok: service.total(100); } }与 Spring 的差异要点作用域注解来自 JakartaApplicationScoped带代理推荐、Singleton无代理急切、RequestScoped、Dependent类型安全解析靠类型Qualifier不靠 beanName构建期校验循环依赖、缺 Bean、歧义注入在mvn compile就失败Native 友好规则注入字段别用private避免反射用包私有或构造器注入五、命令式 响应式同一套模型Quarkus 的线程模型不逼你全响应式默认 RESTEasy Classic 走Vert.x EventLoop Worker 线程写普通String hello()就是命令式阻塞代码但底层是非阻塞 HTTP想响应式返回UniTMutiny即可接管事件循环GET Path(/async) public UniString async() { return Uni.createFrom().item(done).onItem().delayIt().by(Duration.ofMillis(10)); }Hibernate Reactive、Reactive MessagingKafka/MQTT/AMQP全部接同一套 Mutiny 管线。命令式与响应式可以混编在同一个 Bean 里这是 Quarkus 对比 Spring WebFlux全家桶切换很舒服的一点。六、原生镜像GraalVM 不是附件是一等公民./mvnw package -Dnative # 或 quarkus build --native构建产物是一个独立可执行文件Linux 下常见 20–80MB启动时间典型10–50msRSS 常驻30–80MB而同功能 Spring Boot JVM 模式启动秒级、RSS 200MB。Native 模式的代价与解法反射/动态代理必须构建期可知 → 用RegisterForReflection或让 Extension 自动注册Quarkus 大部分库已处理Classpath 扫描失效 → 本来 Quarkus 就不靠运行时扫描构建慢 → Native 编译要几分钟因此日常开发用 JVMDev 模式CI 出原生镜像JNI/动态加载受限 → 用 Quarkus 官方扩展替代裸库经验法则Serverless / 边缘 / 短生命周期微服务优先 Native长连接网关、批处理、重 JIT 吞吐场景用 JVM 模式Quarkus JVM 也比传统 Spring 省 30–50% 内存。七、开发者体验Dev Mode 是隐藏大招./mvnw quarkus:dev启动后保存 Java 文件 → 浏览器刷新即生效不用重启Augmentation 增量执行Continuous Testing改代码后台自动跑受影响测试Dev Services检测到用 PostgreSQL 就自动起一个容器 DB用 Kafka 就自动起 Redpanda不用写 docker-compose统一application.properties支持%dev%test%prodprofile这套内循环inner loop把改代码—看结果的延迟从「编译重启 10s」压到「亚秒级」是很多团队迁 Quarkus 后回头率高的原因。八、Kubernetes 原生到什么程度加一个扩展就行quarkus extension add quarkus-kubernetes quarkus-container-image-docker构建时直接产出kubernetes.ymlDeployment/Service/Route自动加liveness/readiness/startupprobe对接/q/health/*读取quarkus.kubernetes.replicas等配置生成资源顺带打容器镜像配置示例quarkus.kubernetes.replicas3 quarkus.container-image.groupacme quarkus.container-image.tag1.0.0 quarkus.kubernetes.liveness-probe.initial-delay10不需要手写一大堆 YAML也不需要 Spring 那套k8s-maven-plugin外挂。九、与 Spring Boot 的实话实说对比维度Quarkus (Native)Quarkus (JVM)Spring Boot 3 (JVM)Spring Boot (Native)启动时间10–50ms0.5–1s2–6s0.1–0.3sRSS 内存30–80MB80–150MB250–500MB80–150MB镜像体积50–150MB80–120MB200–400MB75–110MB生态广度中800扩展中极强强老 Spring 代码迁移需改写部分用quarkus-spring-*兼容层原生原生长稳高吞吐略逊 JIT接近 Spring最优接近 SpringServerless 适配★★★★★★★★★★★★★★★结论很直接新项目 K8s/Serverless/成本敏感 → Quarkus Native 首选存量 Spring 单体 / 复杂事务域模型 / 招聘市场优先 → Spring Boot 仍是理性选择Quarkus 通过quarkus-spring-di/web/data/security提供迁移兼容层但不是 100% 透明十、一个最小可运行示例REST Config Healthpom.xml关键扩展quarkus-resteasy-reactive、quarkus-config-yaml、quarkus-smallrye-healthpackage app; import jakarta.inject.Inject; import jakarta.ws.rs.GET; import jakarta.ws.rs.Path; import jakarta.ws.rs.Produces; import jakarta.ws.rs.core.MediaType; import org.eclipse.microprofile.config.inject.ConfigProperty; Path(/hi) public class HiResource { ConfigProperty(name app.msg, defaultValue hello quarkus) String msg; Inject Clock clock; GET Produces(MediaType.TEXT_PLAIN) public String hi() { return msg clock.now(); } } ApplicationScoped class Clock { public String now() { return java.time.Instant.now().toString(); } }application.propertiesapp.msgSupersonic Subatomic Java quarkus.http.port8080 quarkus.native.resources.includes*跑起来./mvnw quarkus:dev # 开发热重载 ./mvnw package # JVM 包 ./mvnw package -Dnative # 原生可执行/q/health/live与/q/health/ready开箱即用直接配给 K8s probe。十一、什么时候选 Quarkus什么时候别选选 Quarkus微服务数多、Pod 密度敏感、Scale-to-Zero 场景AWS Lambda / Cloud Run / 边缘容器新绿色项目团队愿意接受 Jakarta 注解体系需要 GraalVM Native 但又不想手搓反射配置暂不选 Quarkus深度依赖 Spring 特有生态Spring Batch、Spring Integration、某些国产中间件 SDK 只认 Spring团队 50 人全是 Spring 背景、且没有性能痛点业务是长连接、重计算、JIT 预热后吃吞吐的网关/规则引擎十二、结语Quarkus 的本质Quarkus 不是更快的 Spring而是把 Java 框架的时机模型重写了一遍——别人在运行时做的扫描、反射、建图、织入它在构建时做完并烤进字节码别人为灵活性保留的动态性它用标准注解 扩展机制在编译期锁定。于是 Java 在容器里第一次获得了和 Go/Rust 同台较量的启动曲线却没丢掉 JVM 生态和类型安全。在 2026 年的 Java 云原生选项里Quarkus 已经不是实验品而是和 Spring Boot、Micronaut 并列的一线选手。理解它的关键不在某个QuarkusTest注解怎么用而在Build Time is the new Runtime 这一句。
