Java 云原生生产运行指南：镜像、容器、Kubernetes、Native Image 与交付治理

核验与阅读口径：本文核验日期为 2026-05-15。版本基线为 JDK 26 GA / 26.0.1 update line、JDK 25 LTS 与 JDK 27 EA。JPMS 与 jlink 以 JDK 9 之后的模块系统为基础；GraalVM Native Image、Spring Boot Native、Buildpacks、Jib、Kubernetes、Serverless、distroless、SBOM、签名与 attestation 都属于快变生态。本文只给出架构判断、生产边界和最小示例形状；具体插件版本、镜像名、Kubernetes API 字段、云厂商参数、Native Image 参数和默认行为必须以项目锁定版本与官方文档为准。任何启动时间、镜像大小、内存占用和冷启动收益都必须绑定工作负载、硬件、JDK/GraalVM 版本、构建参数和压测证据，不能当作通用承诺。

摘要

这篇文章回答一个核心问题：在容器、Kubernetes、Serverless、Native Image、供应链安全和自动化交付已经成为常态的生产环境中，Java 架构师应该怎样运行 Java 服务，而不是把云原生理解为“写一个 Dockerfile，再贴一段 YAML”。Java 云原生的关键不是把 JAR 放进容器，而是把运行时、镜像、资源、发布、观测、诊断、回滚和安全证据串成一条可运营的链路。

旧式 Java 部署往往关注应用包、JVM 参数和主机环境。云原生部署把边界拆得更细：基础镜像是谁维护的，JDK/JRE/jlink/runtime image 如何选择，容器内 heap、Metaspace、direct memory、thread stack、code cache、native memory 如何预算，Kubernetes requests/limits、探针、滚动发布、优雅停机如何配合 JVM，Native Image 何时值得使用，Serverless 的冷启动和并发模型是否适合业务，CI/CD 如何生成 SBOM、签名、扫描、attestation 和回滚证据。

本文不会把大量 Dockerfile、YAML、Groovy、GitHub Actions、GitLab CI、Jenkinsfile 当成正文深度。配置示例只保留关键片段，默认服务于理解。读者应该在不展开任何长配置的情况下，理解 Java 云原生生产运行的核心判断：先明确运行责任边界，再做镜像与运行时选择；先做容器内存预算，再调 JVM 参数；先设计 Kubernetes 故障路径，再复制 YAML；先用证据判断 Native Image 和 Serverless 是否合适，再追求冷启动数字；先建立供应链和回滚证据，再讨论发布速度。

关键词：Java，云原生，Kubernetes，容器，GraalVM Native Image，jlink，JPMS，Serverless，SBOM，供应链安全，JVM 内存，冷启动，回滚，故障诊断

1. Java 云原生的核心问题：不是能不能容器化，而是谁负责运行边界

本章回答的问题是：Java 云原生到底改变了什么。读完这一章，读者应该能把 JVM、容器、镜像仓库、Kubernetes、Service Mesh、Serverless、CI/CD、供应链安全和运维平台各自负责的边界说清楚。生产边界是：容器只是包装形式，真正决定稳定性的，是运行时责任是否被拆清楚、证据是否可追踪、故障是否可定位、版本是否可回滚。

很多团队第一次做 Java 容器化时，只把 java -jar app.jar 放进 Dockerfile，然后把原来的主机 JVM 参数搬到容器里。这种做法能运行，但不等于云原生。云原生运行模型要求应用把自身行为交给平台观察和调度：健康检查告诉平台何时接流量，优雅停机告诉平台何时摘流量，资源 requests/limits 告诉调度器如何放置 Pod，镜像 digest 告诉发布系统运行了哪个制品，SBOM 告诉安全团队制品包含哪些依赖，trace 和 metrics 告诉运维团队故障发生在哪一段，回滚记录告诉事故时能否退回上一版本。

Java 的特殊性在于它有一个复杂运行时。容器里跑的不是一个简单二进制，而是 JVM、类加载、JIT、GC、线程、native library、证书、时区、字体、本地化资源、DNS、文件系统、反射、动态代理、JNI、JFR、日志和应用框架的组合。容器限制的是进程可见资源，但 JVM 内部还要把这些资源分给 heap、Metaspace、direct buffer、thread stack、code cache、GC 结构和 native 分配。只设置 -Xmx 不代表内存安全，只写 resources.limits.memory 也不代表 JVM 会按业务预期运行。

因此，Java 云原生架构评审首先应该问责任边界，而不是问工具名。镜像策略负责最小可运行环境和补丁模型；JVM 参数负责运行时预算和诊断能力；Kubernetes 负责调度、探针、重启、滚动发布和资源隔离；Service Mesh 负责部分流量治理和 mTLS，但不替代应用级超时和连接池；CI/CD 负责构建、扫描、签名、发布和回滚证据；应用负责暴露健康状态、优雅停机、配置读取、日志和业务降级；运维平台负责监控、告警、容量和事故复盘。任何一层职责错位，都会在生产中表现为难以解释的 OOM、探针误杀、冷启动慢、发布卡死、DNS 抖动、证书失败、镜像漏洞或回滚困难。

责任层	应负责什么	不应替代什么	常见错位
JVM 与应用	内存预算、GC/JFR、优雅停机、健康端点、业务降级	Kubernetes 调度和镜像扫描	只调 -Xmx，不看 native memory
镜像与运行时	JDK/JRE/jlink/runtime、证书、时区、字体、动态库	应用配置和业务权限	镜像很小但缺 CA 或字体
Kubernetes	requests/limits、探针、滚动发布、重启、调度	应用内部超时、连接池和事务	探针误杀或滚动发布不可用
Serverless	事件触发、弹性、冷启动模型、计费边界	长连接服务和复杂本地状态	把持续高并发服务硬迁函数
CI/CD 与供应链	SBOM、扫描、签名、attestation、部署证据、回滚	运行时诊断和业务验收	只构建成功，没有可追溯证据
运维平台	指标、日志、trace、告警、容量和事故复盘	应用 owner 的业务判断	告警能响但无法定位根因

这篇文章的主线是：Java 云原生不是配置清单集合，而是一套生产运行判断。后续章节会按运行时策略、镜像、容器资源、Kubernetes、Native Image、Serverless、供应链和故障诊断逐步展开。

1.1 从单体主机心智切换到平台契约心智

传统主机部署常把“运行环境”视为一台相对稳定的机器：运维安装 JDK，应用团队上传包，启动脚本写 JVM 参数，机器上有 shell、日志目录、证书、字体、时区和诊断工具。云原生把这件事拆成多个契约：镜像提供文件系统和运行时，容器限制进程资源，Kubernetes 决定调度和生命周期，Service/Ingress 决定流量进入，ConfigMap/Secret 决定配置来源，CI/CD 决定制品来源，观测系统决定证据，安全系统决定准入。任何一个契约不清楚，都会在事故中变成盲区。

这种心智变化对 Java 尤其重要。过去在主机上临时安装字体、补证书、改时区、手动拷贝本地库、临时加 JVM 参数，都可能被当成“运维小修”。到了云原生环境，这些都必须进入镜像、配置、部署和审计证据。否则下一次扩容、重建、迁移节点或回滚时，手工改动会消失。云原生要求 Java 团队把运行环境当成代码和制品的一部分管理，而不是把它当作机器上的背景条件。

平台契约心智还要求应用主动暴露状态。应用不能只在日志里说“启动完成”，而要通过 readiness 告诉平台何时接流量；不能只依赖进程退出，而要通过 liveness 表达是否卡死；不能只在内部捕获错误，而要用指标和 trace 说明错误发生在哪一段；不能只在 CI 中构建成功，而要提供镜像 digest、SBOM 和部署证据。平台不是万能运维，它只能基于应用暴露的契约做正确调度。

1.2 Java 云原生成熟度的五个层级

Java 云原生可以按成熟度分成五层。第一层是“可容器化”：应用能在容器里启动，能暴露端口，能接入基本日志。这一层只能说明迁移开始，不能说明生产可靠。第二层是“可调度”：应用有资源 requests/limits、健康检查、配置注入和滚动发布，可以被 Kubernetes 管理。第三层是“可观测”：应用能提供 JVM、容器、业务和平台指标，trace 能串联请求，故障能分层定位。第四层是“可治理”：镜像、依赖、SBOM、签名、配置、密钥、漏洞和回滚都有证据链。第五层是“可演进”：运行时策略、Native Image、Serverless、jlink、基础镜像和平台模板能按服务画像演进，而不是一次迁移后冻结。

很多团队以为自己已经完成云原生，其实只到第一层或第二层。能在 Kubernetes 里跑，不代表能稳定运行；能自动扩容，不代表下游能承受；能生成镜像，不代表供应链可追溯；能快速启动，不代表可诊断；能通过探针，不代表业务准备好。成熟度评估能帮助团队避免把“部署形式改变”误认为“运行能力升级”。

每一层都有可验证证据。可容器化要有镜像和启动 smoke；可调度要有资源、探针和滚动发布结果；可观测要有指标、日志、trace 和告警；可治理要有 SBOM、扫描、签名、digest、配置版本和回滚演练；可演进要有服务画像、运行时选择记录、性能基线和升级计划。没有证据的成熟度只是口号。

1.3 三类 Java 云原生服务的不同优先级

第一类是在线交易型服务，例如订单、支付、库存、登录、报价和核心 API。它们的优先级是低尾延迟、强可观测、稳定连接池、灰度发布和可回滚。对这类服务，Kubernetes Deployment、JVM 长生命周期、清晰的资源预算和成熟的 GC/JFR 诊断通常比追求极限镜像大小更重要。Native Image 或 Serverless 可以评估，但必须证明 p99、错误率、功能兼容和回滚能力。交易型服务最怕“启动很快但出错难查”。

第二类是后台处理型服务，例如消息消费者、批处理、报表、异步通知、文档转换和离线导入。它们的优先级是幂等、checkpoint、重试、资源峰值、队列堆积和失败恢复。对这类服务，Kubernetes Job/CronJob、Deployment worker、Serverless 函数都可能合适。选择依据不是框架，而是任务时长、重试语义、数据量、下游容量和成本。后台任务最怕“平台自动重试但业务不幂等”。

第三类是弹性边缘型服务，例如低频 API、Webhook、文件处理、轻量推理前处理、CLI 和工具型服务。它们的优先级是冷启动、镜像拉取、成本、最小运行面和供应链安全。Native Image、jlink、Serverless、distroless 可能更有价值。但即使是这类服务，也不能忽略证书、DNS、字体、资源文件、日志和回滚。边缘型服务最怕“平时没人管，出错时没有诊断入口”。

这三类服务可以共享平台能力，但不应共享同一组默认值。平台团队如果只给一个标准模板，会让交易型服务承担冷启动风险，让后台任务承担不必要的低延迟成本，让边缘型服务背负过重运行时。服务画像就是为了解决这种差异。

2. 运行时与镜像策略：JDK、JRE、jlink、distroless 与补丁模型

本章回答的问题是：Java 服务应该选择什么运行时和镜像形态。读完这一章，读者应该能区分完整 JDK、JRE 风格运行时、jlink 自定义运行时、distroless、UBI micro、Alpine/musl、Native Image 和 buildpack 产物的适用边界。生产边界是：镜像越小不一定越安全，启动越快不一定越可运维，运行时越裁剪越需要补丁、诊断和兼容性证据。

完整 JDK 镜像适合开发、构建、诊断和某些需要运行时工具的生产场景。它包含 jcmd、jfr、jstack、jmap 等工具，事故排查方便，但镜像更大、攻击面更广、补丁管理更重。运行时 JRE 风格镜像更适合普通生产服务，保留运行 Java 应用所需组件，但减少构建工具。jlink 自定义运行时进一步按模块裁剪，只包含应用需要的 JDK 模块，适合对镜像大小、启动、漏洞面和发布制品可控性有要求的场景。distroless 或 UBI micro 这类基础镜像进一步减少 shell 和包管理器，但诊断能力也会下降。Alpine/musl 可能带来更小镜像，但 Java、JNI、DNS、字体、glibc 兼容性和 native library 行为必须逐项验证。Native Image 则把 Java 应用 AOT 编译成原生可执行文件，改变的不只是镜像大小，而是运行模型、动态特性、构建过程和故障诊断方式。

镜像策略还要看补丁模型。一个极小镜像如果没有清晰的安全更新来源，长期风险可能比标准发行版更高。distroless 的价值在于减少运行时内容，但它仍然需要基础镜像维护、digest 锁定、漏洞扫描和定期重建。UBI 系列适合需要商业支持和企业合规口径的组织。Buildpacks 能把运行时、依赖分层、SBOM 和重建流程标准化，适合平台团队统一治理；Jib 适合 Java 构建直接生成分层镜像，减少 Dockerfile 手写错误；手写 Dockerfile 适合需要细粒度控制的团队，但也最容易留下证书、用户权限、时区、字体和层缓存问题。

JPMS 与 jlink 在云原生中的位置应该被重新定位。它们不是整篇文章的主角，而是运行时策略的一种工具。JPMS 通过模块边界让依赖更显式，jlink 可以构建自定义运行时，减少运行时体积和暴露面。但迁移到模块化并不适合所有应用，尤其是大量依赖反射、动态代理、自动扫描、插件机制或传统框架的系统。对这些系统，强行模块化可能增加维护成本。更现实的做法是先用 jdeps 观察依赖，再在服务边界清晰、依赖稳定、收益明确的服务上尝试 jlink，而不是把整个企业应用一次性改成强模块。

运行时/镜像形态	适合场景	主要收益	主要风险	生产证据
完整 JDK 镜像	诊断友好、内部平台、复杂排查	工具完整、兼容性好	镜像大、漏洞面广	扫描结果、工具使用策略
JRE 风格镜像	普通生产服务	运行够用、体积适中	诊断工具不足	事故排查替代方案
jlink 运行时	依赖稳定、模块可分析服务	体积小、模块清晰	缺模块、反射/服务加载问题	jdeps 报告、集成测试
distroless/UBI micro	安全治理和最小基础镜像	攻击面小、补丁口径清晰	shell 缺失、诊断难	debug 镜像、回滚镜像
Alpine/musl	极小镜像和特定平台	体积小	glibc/JNI/DNS/字体兼容性	native 依赖测试
Native Image	冷启动、低 RSS、Serverless/CLI	启动快、镜像小	动态特性和诊断变化	native 集成测试、元数据
Buildpacks/Jib	平台化镜像治理	分层、SBOM、自动化	默认策略不透明	构建证据、镜像 digest

下面的命令是“最小诊断片段”，不是完整构建脚本。场景是在考虑 jlink 前分析应用需要哪些 JDK 模块；原因是避免凭感觉裁剪运行时；观察点是模块列表要进入 CI 证据；生产边界是动态反射、服务加载和框架插件仍需集成测试验证。

jdeps --print-module-deps --ignore-missing-deps target/app.jar
jlink --add-modules java.base,java.logging,java.sql --output build/runtime

镜像策略的结论是：不要用“最小”替代“可运营”。最小镜像要有补丁来源、debug 路径、诊断策略和回滚镜像；自定义运行时要有模块分析、依赖测试和版本证据；Native Image 要有动态特性清单和 native 集成测试。下一章进入容器资源预算，因为镜像能启动只是第一步，容器内能稳定运行才是生产问题。

2.1 运行时选择要从服务画像开始

运行时选择不能脱离服务画像。一个面向外部用户的低延迟 API、一个内部批处理任务、一个事件驱动函数、一个报表生成服务、一个依赖 JNI 的图像处理服务、一个纯 CPU 计算服务、一个高 I/O 的网关服务，对运行时的要求完全不同。低延迟 API 更关注 p95/p99、连接池、GC、探针和滚动发布；批处理更关注吞吐、内存峰值和失败重试；函数更关注冷启动、幂等和超时；报表服务更关注字体、时区、本地化和 native 资源；JNI 服务更关注基础镜像、动态库、ABI 和架构。只有先给服务画像分类，JDK、jlink、distroless、Native Image 和 Serverless 的选择才有依据。

服务画像至少应包含六类信息。第一是流量形态：稳定常驻、波峰明显、低频触发、批量任务还是长任务。第二是资源形态：CPU 密集、内存密集、I/O 密集、连接密集还是启动密集。第三是依赖形态：是否依赖反射、动态代理、JNI、字体、时区、证书、外部命令、文件系统和本地库。第四是诊断要求：生产事故时是否需要 jcmd、JFR、heap dump、thread dump、core dump 或 shell。第五是合规要求：基础镜像来源、漏洞修复、商业支持、SBOM 和供应链证据。第六是回滚要求：能否保留 JVM/native 双轨，能否快速回退镜像，是否存在不可逆 schema 或配置变更。

如果服务画像不清，团队很容易被单点指标诱导。例如看到 Native Image 冷启动快，就把一个长期运行、高动态、依赖大量反射的复杂 Spring 服务迁过去；看到 distroless 镜像小，就把需要现场诊断和字体渲染的服务放进去；看到 jlink 镜像体积小，就忽略了模块缺失导致的运行时路径失败。云原生不是追求一个“最优镜像”，而是为每类服务选择可解释、可测试、可回滚的运行时。

2.2 jlink 的工程价值在依赖可见性，不只是镜像瘦身

很多文章介绍 jlink 时会强调镜像体积变小，但生产中更重要的收益是依赖可见性。jdeps 能帮助团队看见应用依赖哪些 JDK 模块，jlink 能把这些模块固化到运行时里。这让安全扫描和运行时边界更清楚：一个服务不需要 java.desktop，就不应该因为基础镜像完整而隐式携带它；一个服务需要 java.naming 或 java.sql，就应该在运行时清单里显式出现。依赖可见性让平台团队知道“这个服务为什么需要这些模块”，也让漏洞响应更准确。

但 jlink 不适合作为所有服务的强制门槛。传统 Spring 应用、复杂 ORM、反射扫描、插件机制、ServiceLoader、动态代理和第三方库，可能让模块分析变得不完整。某些依赖在编译或启动时看不到，只有特定业务路径才会触发。此时如果只根据一次 jdeps 输出裁剪运行时，很可能上线后才发现缺模块。正确做法是把 jdeps 作为观察工具，把 jlink 作为候选优化工具，把端到端测试作为验证工具。

jlink 迁移可以分阶段。第一阶段只记录模块依赖，不改变运行时；第二阶段在测试环境构建自定义运行时，跑完整集成测试和业务 smoke；第三阶段只对依赖简单、启动收益明确、诊断替代方案充分的服务灰度；第四阶段才考虑平台化模板。不要把 jlink 迁移和业务功能发布混在一起。运行时裁剪属于基础设施变更，应该有单独回滚路径。

2.3 极小镜像必须配套 debug 策略

distroless、scratch、UBI micro 和 Native Image 镜像能减少攻击面，但也会减少排查工具。没有 shell、没有包管理器、没有 curl、没有 ps、没有字体、没有 CA 工具，事故时排查会变难。生产团队不能等到事故发生才发现“镜像里什么都没有”。极小镜像必须配套 debug 策略，例如使用可替换 debug 镜像、ephemeral containers、节点级工具、sidecar 诊断、JFR 输出、应用自诊断端点、结构化日志和远程 profiling 策略。

debug 策略还要考虑权限。给生产 Pod 注入 debug 容器，可能等同于获得容器网络和文件系统访问能力。谁可以注入，何时可以注入，是否需要审批，操作是否留痕，能访问哪些命名空间和 Secret，都要纳入安全策略。极小镜像减少攻击面，但 debug 权限如果管理不好，会从另一个方向扩大风险。

一个成熟做法是把运行镜像和诊断镜像分开。运行镜像保持最小；诊断镜像包含必要工具，但只能通过受控流程临时使用。应用还要暴露足够的诊断信号，例如健康状态、版本、配置摘要、JFR 开关、指标和 trace。这样既能保持生产镜像简洁，又不牺牲事故处理能力。

2.4 基础镜像选择要绑定组织补丁能力

基础镜像不是纯技术选型，它绑定组织补丁能力。一个团队如果没有能力持续跟踪 distroless、Alpine、Debian、Ubuntu、UBI、Temurin、Liberica、Amazon Corretto 或其他发行版的安全更新，就不应该随意切换基础镜像。镜像越多样，补丁治理越复杂。平台团队通常需要收敛基础镜像集合，建立标准镜像、扫描规则、重建周期和例外流程。

补丁能力包括三件事。第一，知道哪些服务使用了哪个基础镜像和 digest；第二，基础镜像更新后能自动或半自动重建业务镜像；第三，更新后能通过测试和灰度进入生产。很多漏洞响应卡在第二步：知道有漏洞，但不知道哪些镜像受影响，或者重建后无法证明行为一致。SBOM 和 digest 解决的是可见性，自动化重建和回归测试解决的是响应能力。

基础镜像还影响合规口径。某些企业要求使用有商业支持的发行版，某些企业更看重最小攻击面，某些企业有内部镜像仓库和安全基线，某些企业需要 FIPS、国密或特定证书链。Java 团队不能只按个人偏好选择镜像。镜像策略应进入平台标准，并允许特定服务基于证据申请例外。

2.5 镜像分层要服务发布效率和风险隔离

Java 镜像分层的价值不只是缓存构建。它还能隔离风险。基础层包含 OS 和运行时，框架层包含第三方依赖，应用层包含业务代码，配置层由运行时注入。业务代码频繁变化，基础镜像和依赖相对稳定。分层合理时，镜像拉取更快，扫描结果更清楚，回滚更可解释。分层混乱时，任何小改动都可能重建整个镜像，漏洞扫描和缓存都变差。

Spring Boot layered jar、Jib、Buildpacks 都在试图解决分层问题，但方式不同。Jib 适合从 Java 构建系统直接生成镜像；Buildpacks 更适合平台化标准构建和 SBOM；手写 Dockerfile 适合特殊控制但容易出错。选择哪一种，不应只看开发者习惯，而要看平台治理：谁维护模板，如何升级基础镜像，如何生成 SBOM，如何签名，如何调试，如何处理例外。

分层还要避免把密钥和环境配置打进镜像。镜像应该是环境无关制品，配置和密钥通过平台注入。把生产配置写入镜像会破坏制品晋级，也会让镜像泄露风险上升。云原生交付的一个基本原则是同一个镜像 digest 可以经过多个环境，只由受控配置决定行为差异。

3. 容器资源治理：heap、非 heap、线程、direct memory、CPU 与 cgroup

本章回答的问题是：Java 服务在容器里到底该怎样做资源预算。读完这一章，读者应该能区分 Java OutOfMemoryError、容器 OOMKilled、native memory 泄漏、direct memory 增长、Metaspace 增长、线程栈消耗和 CPU throttling。生产边界是：容器 limit 不是 JVM 自动安全边界，-Xmx 不是总内存预算，requests/limits 也不是容量模型。

容器内存至少要分成七类。第一类是 Java heap，由对象分配和 GC 管理；第二类是 Metaspace，用于类元数据，受类加载、框架、动态代理、热部署和插件影响；第三类是 direct memory，例如 Netty、NIO、数据库驱动、压缩、序列化和 native buffer；第四类是 thread stack，每个线程都有栈，虚拟线程也不是完全没有调度和栈对象成本；第五类是 code cache，JIT 编译后的代码需要空间；第六类是 GC 和 JVM native structures；第七类是 native library、glibc/musl、TLS、字体、DNS、压缩库、图像库和应用本地分配。容器 limit 限制进程总 RSS，而不是只限制 heap。

-Xmx 设置过高会挤压非 heap 和 native 空间，导致容器 OOMKill；设置过低则可能造成频繁 GC、吞吐下降或分配失败。MaxRAMPercentage 等容器感知参数可以帮助 JVM 根据容器内存估算 heap，但它仍然是估算，不是业务容量规划。生产服务应基于压测和观测确定 heap、Metaspace、direct memory、线程数、code cache、native memory 和安全余量。尤其是 Netty、gRPC、压缩、大量 TLS、图像/字体处理、JNI、数据库驱动和 off-heap cache 的服务，不能只看 heap。

CPU 也有类似问题。Kubernetes CPU limit 可能带来 throttling，导致延迟抖动、GC 周期变化、JIT 编译变慢和请求堆积。Java 服务看起来 CPU 使用率不高，但 cgroup throttling 可能已经影响 p99。requests 影响调度和资源保证，limits 影响上限和节流。对延迟敏感服务，盲目设置很低 CPU limit 可能比让服务共享节点更糟。对批处理服务，CPU limit 又能保护集群公平性。架构师要根据服务类型、延迟目标、节点资源和扩缩容策略做判断。

资源	典型来源	主要症状	诊断证据	治理动作
Heap	对象分配、缓存、集合	GC 频繁、Java OOM	GC log、JFR、heap dump	调 heap、修对象生命周期、限缓存
Metaspace	类加载、代理、插件	Metaspace OOM、RSS 增长	NMT、class count、JFR	限插件、修类加载泄漏
Direct memory	Netty/NIO/驱动	RSS 高、heap 正常	NMT、Netty metrics	限 direct memory、修 buffer 释放
Thread stack	平台线程、线程池	RSS 高、上下文切换	thread dump、线程数	限线程池、虚拟线程评估
Code cache	JIT 编译	编译停止、性能下降	code cache metrics、JFR	调整 code cache 或降低动态代码
Native library	JNI、TLS、字体、压缩	容器 OOMKill、crash	NMT、core dump、容器事件	依赖审计、隔离、回滚
CPU quota	cgroup limit	p99 抖动、吞吐不稳	throttling metrics、JFR	调 requests/limits、扩容

下面片段是“最小配置形状”，不是通用推荐值。场景是给容器内 Java 服务预留非 heap 空间；原因是避免 -Xmx 抢占全部容器内存；观察点是 heap 百分比要和 native/direct/thread 预算一起压测；生产边界是不同 JDK、框架、工作负载和容器 limit 下必须重新验证。

JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=65 -XX:+ExitOnOutOfMemoryError -XX:StartFlightRecording=settings=profile,dumponexit=true"

资源治理的诊断路径应该从症状开始。如果 Pod 被 OOMKilled，而应用没有 Java OOM 堆栈，优先看容器事件、RSS、NMT、direct memory、线程数和 native library；如果 Java heap OOM，优先看 heap dump、GC log、对象保留路径和缓存策略；如果响应慢但 CPU 不高，检查 throttling、连接池等待、GC pause、下游延迟和 thread dump；如果启动慢，拆分镜像拉取、类加载、JIT、Spring 初始化、数据库连接、探针接入和缓存预热。不要把所有问题都归因到 JVM 参数。

本章结论是：Java 容器资源治理必须从总内存和总 CPU 视角出发。下一章讨论 Kubernetes，因为资源预算需要和 Pod 调度、探针、滚动发布和优雅停机配合。

3.1 内存预算要写成公式化清单，而不是只写 -Xmx

Java 容器内存预算可以用一句话概括：容器 limit 必须大于 heap、Metaspace、direct memory、thread stack、code cache、JVM native、native library、诊断余量和安全余量之和。这个公式不需要在文章里变成复杂数学，但团队必须按它做容量评审。只要某一项缺失，压测环境可能没问题，生产流量和依赖路径一变就会触发 OOMKill。

实践中可以先给出预算表。比如 1Gi 容器内存，不应直接设置 -Xmx900m。要预留 Metaspace、direct buffer、线程栈、JIT code cache、GC 结构、TLS 和 native library。如果服务使用 Netty、gRPC、压缩、图片处理、PDF、JNI 或本地数据库驱动，direct/native 预算要更保守。如果服务线程池很多，线程栈预算要更保守。如果服务依赖大量动态代理和类加载，Metaspace 预算要更保守。预算表的数值来自压测和观测，不来自模板。

内存预算还要和伸缩策略绑定。单 Pod 内存越大，节点装箱密度越低；单 Pod 内存越小，GC 和 native 余量越紧。扩容更多小 Pod 能提升隔离和弹性，但也会增加连接数、启动波峰和镜像拉取压力。少量大 Pod 可能更高效，但滚动发布和故障影响面更大。Java 服务的 Pod 尺寸不是单纯 JVM 参数问题，而是节点容量、下游连接、发布策略和业务 SLO 的综合决策。

3.2 连接池和线程池是容器资源的一部分

容器资源治理不能只看 JVM 内部。数据库连接池、HTTP 客户端连接池、消息消费者并发、线程池、队列长度和 bulkhead 都会把 Pod 资源选择放大到下游系统。一个 Pod 连接池 50，看起来不大；如果 HPA 扩到 40 个 Pod，就是 2000 个连接。滚动发布时新旧 Pod 并存，连接峰值可能更高。Serverless 或快速弹性场景中，这种放大会更明显。

因此，连接池预算要和 Pod 副本数、HPA 上限、滚动发布 maxSurge、下游容量和故障重试一起设计。下游数据库、缓存、搜索、消息队列和第三方 API 都需要容量上限。Java 服务的容器资源不是孤立值，而是参与分布式容量模型。很多“Java 在 Kubernetes 里不稳定”的问题，实际是连接池和弹性策略没有被一起设计。

线程池也类似。传统 Java 服务可能习惯设置较大线程池，但容器 CPU quota 变小后，大量线程会带来上下文切换、锁竞争、内存栈和队列堆积。虚拟线程能降低阻塞等待的线程成本，但不会扩大数据库和下游容量。对 CPU 密集任务，更多线程只会争抢 CPU。对 I/O 密集任务，线程和连接池要一起限流。云原生资源治理必须从“线程数”提升到“资源预算和下游保护”。

3.3 CPU throttling 是尾延迟问题，不只是吞吐问题

Kubernetes CPU limit 触发 throttling 时，应用可能表现为 p99 抖动、请求超时、GC 变慢、JIT 编译延迟、线程调度不稳定，而不是简单的 CPU 使用率高。很多监控只显示容器 CPU 使用率，没有显示 throttling 时间，导致团队误判为应用逻辑慢或 GC 问题。对延迟敏感 Java 服务，CPU throttling 是必须观测的指标。

是否设置 CPU limit 要看组织策略和服务类型。有些平台建议对延迟敏感服务只设置 requests，不设置严格 CPU limit，让节点调度和资源隔离处理公平性；有些组织为了多租户隔离必须设置 limit。无论哪种策略，都要用真实压测和 throttling 指标验证。不能简单复制“500m/1Gi”的模板。

CPU 预算还影响 GC 和 JIT。低 CPU 配额下，GC 线程、编译线程和应用线程竞争更明显；容器启动期如果 CPU 太低，Spring 初始化、类加载和 JIT warmup 都会变慢，进而影响 startup probe。对 Native Image，启动期 CPU 压力可能较低，但业务路径仍要看峰值。CPU 不是单一指标，而是运行时调度能力。

3.4 可观测性必须覆盖 JVM、容器和平台三层

Java 云原生可观测性至少有三层。第一层是 JVM：heap、GC、Metaspace、direct memory、线程、类加载、JFR、JIT、异常和应用指标。第二层是容器：RSS、CPU throttling、OOMKill、文件系统、网络、进程退出码。第三层是平台：Pod 事件、探针、HPA、节点压力、Service、Ingress、DNS、镜像拉取、滚动发布。只看任何一层都会漏掉问题。

指标还要能关联。一次 p99 抖动应能同时看到请求 trace、GC pause、CPU throttling、连接池等待、Pod 重启、下游延迟和发布版本。一次 OOMKill 应能关联容器 RSS、heap、NMT、direct memory、线程数和镜像版本。一次发布失败应能关联 rollout、readiness、配置 diff、镜像 digest 和应用日志。没有关联，监控只是数据堆叠。

Java 服务应默认开启足够的诊断能力，但不能把敏感数据写进日志。JFR 可以作为生产诊断工具，但要管理文件大小、采样开销、导出路径和访问权限。heap dump 可能包含敏感数据，不能随意落盘或上传。thread dump 可能包含业务参数。云原生可观测性必须同时考虑诊断价值和数据安全。

3.5 多服务容量模型要从下游瓶颈反推

单个 Java 服务的资源配置必须放进系统容量模型。假设一个订单服务有 20 个 Pod，每个 Pod 数据库连接池 30，理论最大连接就是 600；如果滚动发布 maxSurge 允许多出 25%，连接峰值可能到 750；如果 HPA 上限是 60，连接峰值可能到 1800。下游数据库是否能承受，连接池是否会排队，线程是否会阻塞，超时是否会触发重试，都是架构问题。不能只看单 Pod 压测通过。

容量模型还要考虑故障。下游变慢时，请求会在连接池、线程池和队列中堆积；重试会放大流量；HPA 看到 CPU 或延迟变化可能扩容；扩容又增加连接；最终故障扩散。Java 服务应使用超时、bulkhead、限流、熔断和背压保护下游。Kubernetes 扩容不是下游保护机制，它只能增加调用方实例，不能增加数据库容量。

在云原生环境中，容量评审应至少包含：每 Pod 并发、线程池、连接池、队列长度、请求超时、重试策略、HPA 上限、滚动发布峰值、下游容量、降级策略和压测证据。没有这些信息，resources 配置只是局部优化。

3.6 JVM 参数要按目标分组管理

JVM 参数常被复制成一长串，但生产治理应按目标分组。第一组是内存预算，如 heap、direct memory、Metaspace、code cache。第二组是故障退出，如 OOM 时退出、生成 dump、记录 JFR。第三组是 GC 策略，如收集器选择、pause 目标和日志。第四组是诊断，如 JFR、NMT、错误文件、heap dump 路径。第五组是安全和兼容性，如强封装开放、TLS、编码、时区。不同组有不同 owner 和验证方式。

按目标分组有两个好处。首先，变更评审更清楚。调大 heap 是容量变更，开启 JFR 是诊断变更，打开 --add-opens 是兼容性和安全变更，切换 GC 是性能变更。其次，回滚更容易。一次发布如果同时改业务代码、GC、heap、镜像和探针，事故时很难定位。JVM 参数应尽量和业务代码解耦发布，或者至少在变更记录里明确。

参数还要避免过期。很多旧参数在新 JDK 中已经废弃、改名或行为变化。云原生 Java 应用升级 JDK 时，必须扫描 JVM 参数，确认仍然有效。无效参数可能导致启动失败，也可能只是被忽略，从而让团队误以为某个保护仍然存在。

4. Kubernetes 生产边界：requests/limits、探针、优雅停机、配置、证书、DNS 与发布

本章回答的问题是：Java 服务在 Kubernetes 中哪些配置决定生产稳定性。读完这一章，读者应该能设计 requests/limits、readiness/liveness/startup probes、graceful shutdown、ConfigMap/Secret、滚动发布、HPA、DNS、证书和调试路径。生产边界是：Kubernetes YAML 不是复制粘贴资产，而是平台与应用之间的运行契约。

requests 决定调度和资源保证，limits 决定上限和隔离。Java 服务通常不适合只按 heap 设置 memory limit，也不适合完全不设资源边界。requests 应反映稳定运行所需资源，limits 应考虑突发、native memory、GC 和诊断余量。CPU requests 太低会导致节点拥塞时服务抢不到 CPU，limits 太低会导致 throttling。对延迟敏感 Java 服务，CPU limit 需要非常谨慎；对批任务和后台任务，可以用 limit 控制资源公平性。

探针是 Kubernetes 和应用之间的生命信号，但探针误用会造成生产事故。readiness 表示是否可以接流量，liveness 表示进程是否需要重启，startup 表示启动期是否还在初始化。Java 服务启动可能包含类加载、Spring 容器、JIT、数据库连接、缓存预热、配置加载和迁移检查。没有 startup probe 时，liveness 可能在启动慢时误杀服务；readiness 如果只检查进程存活，会让尚未准备好的服务接流量；liveness 如果检查下游依赖，可能因为数据库短暂抖动重启所有应用实例，放大故障。

优雅停机同样关键。Kubernetes 删除 Pod 时会发送 SIGTERM，然后等待 termination grace period。Java 应用需要停止接收新请求、等待 in-flight 请求完成、关闭连接池、提交 offset、刷新日志、停止后台任务、释放锁和写审计。如果应用没有 readiness 下线、preStop、graceful shutdown 和合理超时，滚动发布会导致请求中断或重复处理。对消息消费者、批处理和长任务服务，停机协议比 HTTP 服务更复杂。

配置和密钥也不只是 YAML。ConfigMap 适合非敏感配置，Secret 适合敏感配置，但它们的更新语义、挂载方式、环境变量读取和应用刷新机制不同。密钥进入环境变量后可能被进程转储或调试工具看到；挂载文件需要应用或 sidecar 监听变化；配置热更新需要版本和回滚策略。云原生并没有消除配置管理，只是把配置变成平台对象。

证书、DNS、时区、字体和本地化资源是 Java 镜像常见坑。极小镜像可能缺 CA 证书，导致 HTTPS 调用失败；DNS 配置或 JVM 缓存策略不当，会在服务发现变化时继续访问旧地址；缺时区数据会影响时间展示和调度；缺字体会影响 PDF、图片和报表；缺 locale 会影响日期、数字和排序；缺 native library 会让某些依赖只在生产镜像中失败。生产镜像测试不能只跑健康检查，还要覆盖这些运行时资源。

滚动发布要和探针、资源和连接池配合。maxUnavailable、maxSurge、readiness 延迟、preStop 时间、连接池 draining、HPA 扩缩容、Service Mesh drain、数据库连接数和下游限流共同决定发布是否平滑。一个服务有 10 个 Pod，每个 Pod 的连接池是 50，滚动发布时可能短时间打开更多连接；如果数据库最大连接数没有预算，发布本身就能打挂下游。发布策略必须考虑整体系统，而不是只看单个 Deployment。

下面的 YAML 是“最小片段形状”，不是完整生产清单。场景是表达 Java 服务的资源、探针和优雅停机契约；原因是让平台调度、流量接入和停机流程有明确边界；观察点是 startup/readiness/liveness 的语义不同；生产边界是端口、路径、阈值、资源值和 grace period 必须按应用启动曲线与压测结果确定。

resources:
  requests:
    cpu: "500m"
    memory: "768Mi"
  limits:
    memory: "1Gi"
startupProbe:
  httpGet:
    path: /actuator/health/startup
    port: 8080
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
terminationGracePeriodSeconds: 45

Kubernetes 故障诊断应从平台事件和应用证据同时开始。Pod 重启先看 kubectl describe pod、exit code、OOMKilled、探针失败原因和节点压力；应用慢先看 trace、连接池、GC、CPU throttling、下游延迟和 HPA；发布失败先看 rollout history、readiness、镜像拉取、配置版本和事件；DNS 或证书问题先看镜像 CA、JVM truststore、CoreDNS、网络策略和目标服务证书。只看应用日志往往不够。

本章结论是：Kubernetes 配置是运行契约，不是部署样板。下一章讨论 Native Image，因为它改变了 JVM 运行模型，也改变了 Kubernetes 和 Serverless 中的启动、内存和诊断方式。

4.1 探针要表达应用状态，而不是平台愿望

探针设计的关键是语义。startup probe 表示“还在启动，请不要用 liveness 杀我”；readiness 表示“我可以接收新流量”；liveness 表示“我已经卡死，需要重启”。这三个语义不能混用。很多团队把同一个 /health 同时用于三种探针，结果启动慢时被杀、下游短暂故障时被杀、正在优雅停机时仍接流量。探针不是平台愿望，而是应用状态契约。

readiness 应包含应用是否能处理当前请求的必要条件，但不要包含所有外部系统的瞬时健康。比如数据库完全不可用时 readiness 失败可能合理，因为服务确实不能处理请求；但某个非关键下游短暂抖动，不一定应该让服务从流量池中摘除。liveness 更应谨慎，不应依赖数据库、缓存或第三方 API，否则下游故障会触发应用集体重启。startup probe 应覆盖 Java 启动曲线，特别是 Spring 初始化、缓存预热、数据库迁移检查和 Native Image/JVM 差异。

探针还要与发布策略配合。readiness 延迟过短，会让新 Pod 未完全预热就接流量；readiness 延迟过长，会让滚动发布变慢；liveness 阈值过严，会在 GC、CPU throttling 或短暂抖动时误杀；failureThreshold 过大，又会让真正卡死的 Pod 长时间留在集群。正确阈值来自启动曲线和压测，不来自模板。

4.2 优雅停机要覆盖 HTTP、消息和后台任务

很多 Java 服务只考虑 HTTP 请求的优雅停机，但生产中还有消息消费者、定时任务、异步线程池、批处理、缓存刷新、文件上传、审计写入和 trace flush。Kubernetes 发送 SIGTERM 后，应用要先停止接收新流量，再等待 in-flight 请求和后台任务完成，最后关闭连接池和资源。如果消息消费者不停止拉取，Pod 可能在终止期继续处理新消息；如果审计和日志没有 flush，高风险动作可能缺记录；如果连接池没有关闭，下游可能看到异常连接断开。

优雅停机还要处理超时和幂等。不是所有任务都能在 termination grace period 内完成。长任务应该设计 checkpoint、续跑或转移，而不是依赖 Pod 永远不被终止。写操作在停机期间可能执行一半，需要事务和幂等保护。消息处理需要确认 offset 或 ack 策略。HTTP 请求需要明确超时和取消传播。优雅停机本质上是分布式一致性和用户体验问题，不只是一个 Spring Boot 参数。

发布演练应该包含停机演练。随机删除 Pod、滚动发布、节点 drain、配置变更和 HPA 缩容都应验证是否丢请求、重复处理、长时间 5xx 或审计缺失。很多团队只在事故中第一次测试优雅停机，这是不可接受的。

4.3 配置、Secret 和证书更新要有版本语义

云原生平台让配置和密钥更容易注入，但不代表配置治理更简单。ConfigMap 和 Secret 的更新是否自动生效，取决于挂载方式、环境变量读取、应用刷新机制和部署策略。环境变量通常需要重启 Pod 才生效，挂载文件可能会更新但应用未必重新读取，配置中心可能支持热更新但需要版本和回滚。没有版本语义，团队很难知道线上服务到底使用哪一版配置。

证书和密钥更新尤其敏感。证书过期可能导致全链路 TLS 失败；CA truststore 缺失可能只在某个外部调用路径触发；Secret 轮换可能导致旧连接仍使用旧凭证；多副本滚动更新时，新旧凭证可能同时存在。Java 应用还涉及 JVM truststore、操作系统 CA、框架配置和客户端连接池。证书更新应该有演练，而不是等过期告警。

配置变更也要有审批和审计。JVM 参数、连接池、探针阈值、HPA 上限、feature flag、下游地址、模型路由、缓存开关都可能改变系统行为。把这些变更直接 kubectl edit 到生产，会绕过 CI/CD 证据链。云原生治理要求配置和代码一样可审查、可回滚、可追踪。

4.4 滚动发布要计算容量缺口

滚动发布不是 Kubernetes 自动完成的魔法。它会改变可用 Pod 数、新旧版本比例、连接池总数、缓存命中、JIT warmup、Native Image 启动、探针通过时间和下游负载。发布期间系统容量可能低于稳态，也可能因为 maxSurge 高于稳态连接数。容量评估要考虑发布窗口，而不是只看发布前后的稳定状态。

对 Java 服务，发布期还可能出现预热问题。新 Pod 刚 readiness 成功，不代表 JIT 已经 warm、缓存已加载、连接池已稳定、类加载路径已覆盖。Native Image 启动快，但也需要连接和缓存准备。readiness 可以设计成只在关键依赖可用后成功，但不要过度依赖下游。复杂系统可以用渐进流量、预热请求、服务网格权重或灰度策略减小冲击。

回滚也要计算容量。回滚旧版本时，旧镜像是否还在仓库，旧配置是否还在，数据库 schema 是否兼容，旧证书是否有效，旧服务是否能读新消息格式，旧 Native Image 是否仍可运行。没有这些证据，所谓回滚可能只是另一次发布。

4.5 HPA 不是容量规划的替代品

HPA 能根据 CPU、自定义指标或外部指标扩缩容，但它不是容量规划的替代品。HPA 有采样周期、扩容速度、缩容稳定窗口和指标延迟。Java 服务启动慢、readiness 慢或冷启动重时，HPA 扩容到可接流量之间存在时间差。突发流量可能在新 Pod 准备好之前已经打满旧 Pod。对低延迟服务，需要提前容量、预测扩容或队列削峰，而不是完全依赖 HPA。

HPA 指标也要谨慎。CPU 适合 CPU 密集服务，但 I/O 服务可能 CPU 不高却延迟很高；请求数适合网关类服务，但不反映下游等待；队列长度适合异步消费者，但需要处理消费速率和重试；自定义业务指标最准确，但建设成本更高。错误指标会导致错误扩容。例如数据库慢导致请求堆积，如果 HPA 扩更多 Pod，可能进一步打垮数据库。

HPA 上限必须和下游容量绑定。没有上限或上限过高，会让服务在故障时无限扩调用方；上限过低，又可能无法应对正常波峰。HPA 策略应进入容量评审，并和连接池、限流、熔断、降级一起设计。

4.6 Service Mesh 不能替代应用级边界

Service Mesh 可以提供 mTLS、流量路由、重试、超时、熔断、观测和灰度能力，但它不能理解 Java 应用的业务状态。Mesh 可以重试 HTTP 请求，但不知道这个请求是否幂等；可以切流量，但不知道新版本是否已完成缓存预热；可以做超时，但不知道业务事务是否需要补偿；可以记录指标，但不知道哪些异常是可降级业务错误。应用级边界仍然必须存在。

Mesh 重试尤其要谨慎。对只读查询，有限重试可能有帮助；对写操作，Mesh 层盲目重试可能造成重复提交。Java 应用应通过幂等键、业务状态和错误分类控制重试。平台层重试和应用层重试还可能叠加，造成重试风暴。架构评审应明确哪一层负责重试、最大次数、退避策略和幂等要求。

Mesh 也不能替代 JVM 和容器观测。它能看到网络层延迟和错误，但看不到 heap、GC、direct memory、线程、类加载、JIT、应用队列和业务状态。Java 云原生观测要把 Mesh 指标和应用指标结合，而不是二选一。

5. GraalVM Native Image：收益、closed-world 边界、动态特性、诊断与回滚

本章回答的问题是：什么时候应该为 Java 服务选择 Native Image。读完这一章，读者应该能判断 Native Image 适合冷启动、低 RSS、CLI、Serverless、边缘服务还是不适合高动态、大量反射、插件化、复杂调试和峰值吞吐依赖 JIT 的场景。生产边界是：Native Image 不是“更快的 JVM”，而是不同运行模型；它的收益和代价都要用证据验证。

Native Image 通过 ahead-of-time 编译把 Java 应用和需要的运行时部分构建成原生可执行文件。它通常带来更快启动和更低常驻内存，对 Serverless、短生命周期任务、CLI、边缘服务和快速扩缩容服务有吸引力。但它也采用 closed-world 假设：构建时要知道可达代码、反射、资源、动态代理、JNI、序列化和初始化策略。运行时动态性越强，配置和测试成本越高。JVM 的 JIT 能根据真实运行 profile 优化热点代码，Native Image 则需要提前构建，峰值吞吐、诊断方式、启动收益和内存表现都可能因工作负载不同而变化。

Spring Boot 与 GraalVM Native Image 的生态已经比早期成熟很多，但成熟不等于无成本。反射、动态代理、资源文件、类初始化、Netty/OpenSSL、数据库驱动、日志、验证框架、JSON 序列化、ORM、AOP、JNA/JNI、字体、证书和本地库仍需要测试。很多问题不是编译阶段暴露，而是运行某条业务路径时才出现，例如某个 JSON 类型没有反射元数据、某个资源文件未打包、某个类在 build time 初始化导致生产环境值固化、某个 native library 在目标镜像中找不到。

Native Image 的选择应从业务目标开始。如果目标是降低 Serverless 冷启动、减少大量小实例 RSS、提升 CLI 启动体验或缩短弹性扩容到可接流量的时间，它值得评估。如果目标是提升长期运行高吞吐服务的峰值性能，必须用服务级压测比较 JVM warmup 后表现、p99、CPU、内存和 GC/JIT 行为。Native Image 可能更快启动，但未必更高峰值吞吐；JVM 可能启动慢，但长期运行优化更强。不要用单个 Hello World 冷启动数字决定生产架构。

判断维度	Native Image 倾向适合	JVM 倾向适合	必要证据
启动时间	Serverless、CLI、短任务、快速扩容	长生命周期服务	冷启动分段数据
RSS	多实例、小内存环境	内存充足、JIT 收益大	容器 RSS 与峰值
动态特性	反射少、依赖清晰	插件化、反射/AOP/动态代理重	native 集成测试
峰值吞吐	需实测	JIT profile 可能更强	服务级压测
诊断	简化运行面	JFR/JIT/heap 工具更成熟	事故排查方案
构建成本	可接受长构建与元数据	快速开发迭代	CI 时间与缓存
回滚	有双轨镜像	只维护 JVM 路径	JVM/native 双制品

下面 JSON 是“元数据形状示例”，不是直接可复制配置。场景是提示 Native Image 需要显式处理反射；原因是 closed-world 构建无法自动推断所有动态访问；观察点是配置必须和真实业务路径测试绑定；生产边界是框架自动生成的元数据也要在项目版本上验证。

[
  {
    "name": "com.example.api.OrderDto",
    "allDeclaredConstructors": true,
    "allDeclaredMethods": true
  }
]

Native Image 的发布策略最好是双轨。至少在早期，JVM 镜像和 native 镜像应该都能构建，并通过同一套接口测试、契约测试、启动测试、业务 smoke、观测检查和回滚演练。native 镜像如果线上出现某类动态特性缺失，团队应能快速切回 JVM 镜像。不要把 Native Image 改造成单向迁移，除非业务已经充分验证。

Native Image 诊断要提前准备。原生崩溃、类初始化、资源缺失、反射元数据、JNI、SSL、DNS、字体、本地库路径、容器基础镜像差异，都可能成为问题来源。JVM 时代可以用很多运行时工具；native 时代要更多依赖构建报告、日志、core dump、符号、框架诊断、native smoke 和端到端测试。诊断能力下降时，发布风险会上升。

5.1 Native Image 与 Kubernetes 的交互也要验证

Native Image 启动快，但 Kubernetes 中的整体可用时间还包括镜像拉取、容器创建、配置挂载、证书加载、网络就绪、探针通过和服务发现。一个 native 可执行文件本身启动 50ms，不代表 Pod 50ms 可接流量。尤其在镜像较大、节点镜像缓存缺失、Secret/ConfigMap 多、Sidecar 注入、服务网格启动或外部连接预热时，Pod 可用时间可能主要花在平台阶段。

Native Image 的内存也要按容器总 RSS 看。它通常降低 heap 和运行时开销，但仍可能使用 native memory、线程栈、TLS、DNS、字体、本地库和应用缓存。某些服务从 JVM 迁到 native 后，heap 指标不再是主要观察点，团队需要调整监控面板。否则看起来 JVM 指标少了，实际 RSS 或业务延迟问题仍然存在。

Kubernetes 探针也要重新校准。Native Image 启动更快，startup probe 可以更短，但业务依赖预热不一定更快；JVM 应用 readiness 成功前可能已有 JIT warmup，native 应用则可能更早接流量但业务缓存尚未就绪。探针阈值必须按真实镜像和真实部署路径测量，而不是从 JVM 配置直接继承。

5.2 Native Image 不应掩盖应用设计问题

有些服务启动慢，是因为启动时做了过多事情：扫描大量类、加载全部配置、预热所有缓存、连接所有下游、执行迁移、读取大文件、同步调用外部系统。Native Image 可以减少运行时启动成本，但不能解决所有设计问题。如果启动慢主要来自外部依赖和业务初始化，native 收益会有限。更好的做法可能是延迟非关键初始化、拆分服务、异步预热、缓存结果或优化框架配置。

同样，Native Image 不能解决错误的连接池、错误的探针、错误的内存预算、缺失的回滚和不完整的观测。它是一种运行时优化，不是云原生治理替代品。把治理问题包装成 native 迁移，会让系统更难排查。

5.3 Native Image 评估要以业务路径为单位

Native Image 的评估不能只跑启动命令或 Hello World。真正的评估单位应该是业务路径：HTTP 请求、数据库查询、JSON 序列化、消息消费、定时任务、文件处理、TLS 调用、认证授权、缓存访问、日志输出、指标导出、异常路径、国际化、字体渲染、反射调用、代理调用和 JNI 路径。只要某条路径在 native 镜像中没有被测试，就不能假设它可用。

业务路径评估要包含正向和失败路径。正向路径证明功能能跑；失败路径证明错误能被正确处理。例如数据库连接失败时是否能返回正确错误，证书错误是否能记录清楚，JSON 解析失败是否暴露缺元数据，反射路径失败是否在测试中发现，资源文件缺失是否有明确异常。生产事故通常发生在非主路径，native 测试如果只覆盖 happy path，风险很高。

评估报告还要记录 JVM 与 Native Image 的对比。启动时间、RSS、p95/p99、CPU、吞吐、构建时间、镜像大小、诊断能力、功能兼容性和回滚策略都要列出来。只有这样才能判断 native 是否值得引入。一个启动快 800ms 但构建慢很多、诊断困难、功能风险高的服务，未必值得迁移；一个每分钟启动大量实例的函数，则可能非常值得。

5.4 构建元数据要和依赖升级一起维护

Native Image 的反射、资源、代理、JNI 和序列化元数据不是一次性配置。依赖升级、框架升级、业务类型变化、序列化字段变化、AOP 切面变化、验证注解变化、数据库驱动变化，都可能改变可达路径。元数据必须进入代码评审和 CI。只要升级依赖，就应跑 native 构建和 native 集成测试。

框架自动生成元数据能减少工作量，但不能替代验证。自动生成依赖框架版本、插件版本和代码路径。某些动态路径仍可能需要手工提示。团队应把“native 可运行”作为制品属性，而不是假设所有 JVM 应用都能自然变成 native。制品如果声称支持 native，就必须有 native 专属测试和发布证据。

元数据还要避免过度开放。为了让 native 编译通过，把所有类都加入反射配置，可能让镜像变大、构建变慢、攻击面扩大，也掩盖真实依赖关系。正确做法是最小化元数据，并用测试证明业务路径覆盖充分。

5.5 Native Image 的诊断与回滚要前置设计

Native Image 事故排查和 JVM 不同。JIT、GC、heap dump、JFR、动态 attach 和某些运行时工具的行为会变化。团队需要在上线前定义 native 事故怎么排查：日志包含哪些版本和构建信息，如何获取 core dump，是否保留符号，如何定位资源缺失，如何确认类初始化问题，如何比较 JVM 和 native 行为。没有诊断方案，native 只能在低风险场景中使用。

回滚策略也要明确。早期建议保留 JVM 和 native 双制品，灰度比较，并能按流量切回 JVM。对 Serverless 或 CLI，如果只有 native 制品，也应保留上一版 native digest 和配置。回滚不只是镜像切换，还要考虑配置、数据库、缓存、消息格式和外部服务契约。Native Image 改变运行模型，回滚演练必须覆盖真实调用路径。

本章结论是：Native Image 是强有力的运行时选择，但不是默认更优。下一章讨论 Serverless，因为 Native Image、jlink、镜像和冷启动都常在 Serverless 场景中被一起讨论。

6. Serverless 与冷启动：函数、Cloud Run、SnapStart、CRaC/Leyden 口径与适配边界

本章回答的问题是：Java 服务什么时候适合 Serverless。读完这一章，读者应该能区分函数计算、容器化 Serverless、Knative/Cloud Run 风格服务、快照恢复、Native Image 和传统 Kubernetes 服务的边界。生产边界是：Serverless 不是免费弹性，冷启动不是唯一指标，持续高并发、长连接、本地状态、复杂依赖和严格尾延迟都可能让 Serverless 变得不合适。

Serverless 的价值在于事件驱动、自动弹性、按需计费和降低运维面。它适合低到中等频率事件处理、后台任务、轻量 API、定时任务、文件处理、Webhook、边缘触发和对冷启动不极端敏感的业务。Java 在 Serverless 中的挑战是启动时间、类加载、框架初始化、依赖体积、连接预热、JIT warmup 和内存占用。Native Image、jlink、SnapStart、CRaC 和 Project Leyden 相关方向都试图改善启动或运行状态恢复，但它们的状态、适用平台和生产语义必须按版本和供应商核验。

函数计算和容器化 Serverless 不同。函数计算通常有更强事件模型、运行时约束和平台集成，但本地状态、长连接和运行时控制较弱。Cloud Run/Knative 风格容器服务更接近普通 HTTP 服务，可以打包自定义镜像，支持并发和容器协议，但仍有实例冷启动、并发设置、请求超时、实例缩容和平台网络约束。传统 Kubernetes 服务运维面更重，但对连接池、状态、sidecar、长任务和可观测性控制更强。

Java Serverless 的关键不是“冷启动多少毫秒”，而是冷启动对业务是否重要。一个异步图片处理任务冷启动 1 秒可能可以接受；一个用户登录 API 冷启动 1 秒可能不可接受；一个高频稳定流量服务如果实例常驻，冷启动影响很小；一个低频峰值服务如果每次都从零启动，冷启动就是主要体验问题。架构师要看流量形态、并发、尾延迟、成本、预热策略和降级方式。

场景	Serverless 倾向适合	传统 K8s/JVM 倾向适合	判断证据
事件处理	文件、消息、Webhook、定时任务	持续高吞吐队列消费者	事件频率、并发、重试
HTTP API	低频或波峰明显	高 QPS、低 p99、长连接	冷启动和并发压测
数据处理	短任务、可重试	长任务、大内存、本地状态	超时、内存、幂等
AI 辅助任务	异步摘要、离线 embedding	在线低延迟 agent	模型调用时延和预算
成本模型	空闲时间多	稳定常驻流量	单请求成本和峰值

Serverless 也有故障模式。函数重试可能导致重复处理，需要幂等键；实例并发过高可能打穿数据库连接池；冷启动时多个实例同时预热可能造成下游尖峰；平台超时可能中断长任务；日志和 trace 可能跨平台碎片化；密钥和配置更新可能有传播延迟；镜像拉取慢可能放大冷启动。Java 应用还要考虑类初始化、连接池延迟、证书、DNS 和 JIT/native 路径。

Serverless 适配建议是：低风险异步任务优先试点；在线 API 先做冷启动与 p99 证据；连接池要按最大实例数和并发预算；写操作必须幂等；长任务要拆分或转队列；模型调用要有超时和预算；日志、trace、指标和成本要和主平台汇总；Native Image 或快照恢复要用真实业务路径验证，而不是只看框架启动样例。

本章结论是：Serverless 是运行模型选择，不是部署时髦词。下一章讨论 CI/CD 与供应链，因为云原生生产系统最终要靠可追溯交付链保证安全和回滚。

6.1 Serverless 适配要先看流量和状态

Serverless 最适合低频、突发、事件驱动、可重试、状态外置的任务。如果服务需要大量本地缓存、长连接、低尾延迟、复杂连接池、持续后台线程、长事务或强本地状态，Serverless 可能会增加复杂度。很多 Java 服务迁 Serverless 后最大问题不是代码能不能跑，而是连接池、缓存、超时和状态模型不匹配。

流量形态是第一判断。稳定高流量服务常驻 Pod 可能更便宜也更稳定；低频突发服务 Serverless 可能节省成本；波峰明显但对冷启动敏感的服务需要预热或最小实例；异步事件任务需要幂等和重试；批处理任务需要拆分和超时管理。不要只看“可以自动扩容”，还要看扩容时下游是否能承受。

状态模型是第二判断。Serverless 实例可能随时创建和销毁，本地缓存和连接都不可靠。Java 应用要把状态放到外部系统，并准备冷启动后重新建立连接。连接池不能按单实例最大效率设置，而要按最大实例数和并发总量设置。否则一次流量波峰会创建大量连接，打穿数据库或第三方服务。

6.2 冷启动优化要拆成阶段，不要只追一个数字

冷启动包含平台调度、镜像拉取、容器创建、运行时启动、类加载、框架初始化、依赖连接、缓存预热、探针通过和首次请求处理。不同优化手段作用于不同阶段。缩小镜像改善拉取；jlink 改善运行时体积；Native Image 改善运行时启动；SnapStart/CRaC/快照类技术改善已初始化状态恢复；懒加载减少启动工作；预热请求改善首次路径；最小实例减少从零启动。

因此，冷启动报告必须分段。只报“启动 500ms”没有意义，因为可能不包含镜像拉取、网络连接、数据库预热或首次业务请求。对用户体验，真正重要的是从平台决定扩容到实例能正确处理第一批真实请求的时间。对成本，重要的是为了降低冷启动需要保留多少预热实例。对可靠性，重要的是冷启动时是否会打穿下游。

冷启动优化也有副作用。懒加载可能把启动成本转移到首次请求；预热可能制造下游峰值；Native Image 可能增加构建和诊断成本；快照恢复可能固化初始化状态，需要特别处理随机数、时间、连接、证书和安全上下文。每个优化都要有边界。

6.3 Serverless 写操作必须以幂等为核心

Serverless 平台通常会重试事件，用户也可能重复触发请求，函数实例可能在超时边界被中断。只要有写操作，就必须有幂等键。创建订单、发通知、写工单、处理消息、生成账单、调用第三方 API，都不能依赖“函数只执行一次”。幂等策略可以用业务唯一键、事件 ID、去重表、状态机或外部事务日志实现。

幂等还要和可观测性结合。每次重试应记录同一个业务 ID 和事件 ID，方便追踪是否重复执行。超时后函数是否继续执行、平台是否重试、下游是否完成，都要能被审计。没有幂等和审计，Serverless 的自动重试会把偶发失败放大成重复业务动作。

6.4 Serverless 成本模型要算空闲、预热和下游成本

Serverless 常被描述为按需计费，但真实成本不只来自函数执行时间。为了降低冷启动，可能需要最小实例或预热，这会引入空闲成本；为了处理波峰，可能增加下游数据库、缓存和队列容量；为了保证可观测性，日志和 trace 费用可能上升；为了缩短启动，Native Image 构建和 CI 成本可能增加。架构评审要比较总成本，而不是只看单次调用价格。

成本模型还要和流量分布绑定。低频任务按需计费可能便宜；稳定高频服务常驻容器可能便宜；突发但低延迟要求高的服务可能需要预热实例，成本优势变小；大量短任务可能受平台最小计费粒度影响；模型调用或外部 API 可能成为主要成本，Serverless 本身费用反而不是重点。没有流量分布，Serverless 成本判断没有意义。

6.5 Java Serverless 的可观测性要跨平台统一

Serverless 平台通常有自己的日志、指标和 trace 体系，但企业仍需要统一观测。一次用户请求可能经过 API Gateway、函数、模型服务、数据库、队列和另一个 Kubernetes 服务。如果 trace 断在函数边界，事故时很难定位。Java Serverless 应使用统一 trace context、结构化日志、指标标签和错误分类，把函数运行纳入主观测平台。

函数的冷启动、初始化错误、超时、重试、并发、内存峰值和下游调用都要有指标。尤其要区分 init duration 和 invocation duration。否则团队只看到总延迟，不知道是平台冷启动、Java 初始化还是业务处理慢。对于 Native Image 函数，也要记录构建版本和运行时策略，避免和 JVM 函数混淆。

7. CI/CD 与供应链安全：SBOM、扫描、签名、attestation、制品晋级与回滚

本章回答的问题是：Java 云原生交付怎样证明“发布了什么、谁构建的、是否安全、能否回滚”。读完这一章，读者应该能设计构建证据、镜像 digest、SBOM、漏洞扫描、签名、attestation、制品晋级、环境推广和回滚策略。生产边界是：CI/CD 不是把 YAML 写长，而是把制品从源码到生产的证据链做完整。

Java 云原生制品通常包含源码、依赖、构建插件、JDK/GraalVM、容器基础镜像、运行时配置、Kubernetes 清单、Helm/Kustomize、SBOM、扫描报告、签名、attestation、测试报告和部署记录。任何一项不可追踪，事故时都可能无法回答“线上到底跑的是什么”。镜像 tag 如 latest 或可变版本号不足以作为发布证据；生产应尽量使用 immutable digest，并记录源码 commit、构建环境、依赖锁定和部署批次。

SBOM 让团队知道制品包含哪些组件，但 SBOM 不是安全终点。漏洞扫描需要结合可达性、运行时暴露面、基础镜像补丁、依赖版本和业务风险做判断。签名证明制品来自可信构建过程，attestation 证明构建过程满足某些条件。它们的价值在于让制品晋级有证据：开发环境、测试环境、预生产、生产应使用同一个制品或可验证派生产物，而不是每个环境重新构建不一致镜像。

CI/CD 还要管理配置与环境差异。模型 API key、数据库地址、证书、feature flag、JVM 参数、资源 requests/limits、HPA、探针阈值和安全策略通常按环境不同。差异可以存在，但必须受控、可审计、可回滚。最危险的是把生产修复手工改在集群里，CI/CD 不知道，下一次发布覆盖或丢失。

回滚策略要在发布前定义。回滚不仅是 kubectl rollout undo，还包括镜像 digest、配置版本、数据库迁移、消息格式、缓存、RAG 索引、Native Image/JVM 双轨、模型或外部服务版本。如果应用版本回滚，但数据库 schema 或外部依赖不可回滚，回滚可能失败。Java 服务常见的安全策略是向前兼容 schema、灰度验证、双写/双读过渡、feature flag 控制和小批量发布。

7.1 CI/CD 要把性能和运行证据纳入晋级

很多流水线只验证代码正确性，不验证运行特征。Java 云原生流水线应该在合适阶段记录启动时间、镜像大小、RSS、基本 GC 行为、探针通过时间、关键接口延迟、连接池可用性和配置摘要。不是每次提交都跑完整性能测试，但每次发布候选至少要有基本运行证据。否则镜像变大、启动变慢、内存上涨、探针变慢和配置错误会在生产才被发现。

运行证据还要可比较。今天的启动时间比上一版慢多少，RSS 增加多少，镜像大多少，依赖多了什么，漏洞多了什么，Native Image 构建时间变化多少，这些都可以作为发布评审输入。性能回归不是只在代码层发生，也会在镜像、运行时、基础镜像、依赖和配置层发生。

对关键服务，可以建立发布基线。基线包括代表性压测、冷启动、GC、RSS、连接池、HPA 和回滚演练。每次重大运行时变更，如 JDK 升级、基础镜像切换、Native Image 切换、jlink 引入、Kubernetes 资源变化，都要对比基线。这样云原生演进才不会变成盲目改模板。

下面的片段是“CI 证据形状”，不是完整流水线。场景是在构建后记录镜像 digest 和 SBOM；原因是让生产部署可追溯；观察点是部署应引用不可变 digest；生产边界是扫描阈值、签名工具和 attestation 格式必须按组织供应链规范确定。

steps:
  - name: build-image
    run: ./gradlew bootBuildImage
  - name: record-evidence
    run: |
      crane digest registry.example.com/team/app:${GIT_SHA} > image-digest.txt
      syft registry.example.com/team/app:${GIT_SHA} -o spdx-json > sbom.spdx.json

交付流水线的验收不应只看“构建成功”。至少要有单元测试、集成测试、契约测试、镜像扫描、SBOM、签名或等价可信证据、配置 diff、部署计划、灰度策略、指标基线、回滚路径和 owner。对 Native Image，还要有 native 构建报告和 native smoke；对 Kubernetes，还要有探针和资源验证；对 Serverless，还要有冷启动和超时验证。

7.2 SBOM 不是交付终点，而是风险索引

SBOM 能告诉团队制品包含哪些组件、版本和来源，但它本身不会修复漏洞。SBOM 的价值在于让安全团队、平台团队和应用团队快速定位受影响制品。当某个库或基础镜像曝出漏洞时，团队可以查询哪些镜像包含该组件，哪些环境已部署，哪些服务暴露相关路径，哪些制品需要重建。没有 SBOM，漏洞响应只能靠依赖扫描和人工搜索。

SBOM 还要和镜像 digest 绑定。同一个 tag 可能被覆盖，只有 digest 才能准确描述线上制品。SBOM 如果只和构建日志绑定，不和 digest、commit、构建环境和部署记录绑定，事故时仍然无法回答线上运行的是什么。成熟交付链会把 commit、artifact、image digest、SBOM、签名、扫描、部署批次和环境记录关联起来。

漏洞处理也需要上下文。某个 CVE 出现在镜像里，不一定意味着服务可被利用；但“不可利用”必须有证据，例如组件不可达、端口不暴露、功能未启用、已由外层防护阻断。不能简单忽略扫描结果。安全例外应有过期时间和 owner。

7.3 签名和 attestation 是信任链，不是合规装饰

镜像签名回答“这个制品是否由可信主体构建和发布”。attestation 回答“这个制品是如何构建的、经过了哪些步骤、满足哪些策略”。它们的核心价值是在发布前阻止不可信制品进入生产。如果签名和 attestation 只是生成文件但不参与准入控制，就只是合规装饰。

Java 平台团队可以把准入策略做成门禁：生产只允许来自受控 CI 的镜像，只允许带 SBOM 的镜像，只允许扫描结果满足策略的镜像，只允许签名主体在白名单中的镜像，只允许 digest 部署，不允许 latest。这些策略会增加流程成本，但能显著降低供应链风险。

attestation 还可以记录构建环境，例如 JDK/GraalVM 版本、构建插件版本、测试结果、源代码 commit 和依赖锁。对 Native Image，这些信息尤其重要，因为构建环境会直接影响可执行文件。半年后排查 native 行为差异时，构建证据可能比应用日志更重要。

7.4 制品晋级比多环境重建更可靠

很多团队在 dev、test、staging、prod 各环境重新构建镜像，这会导致“测试通过的制品”和“生产运行的制品”不是同一个。更可靠的方式是一次构建，多环境晋级。同一个镜像 digest 从测试到预生产再到生产，环境差异通过配置、密钥和策略注入。这样测试证据才能跟生产制品绑定。

制品晋级也让回滚更清楚。生产出现问题时，可以回滚到上一版已验证 digest，而不是重新构建旧代码。重新构建旧代码可能受到基础镜像更新、依赖仓库变化、插件版本变化和构建环境变化影响，得到的不是同一个制品。云原生生产治理应尽量避免“事故中临时重建”。

配置晋级也需要证据。应用镜像不变，但 ConfigMap、Secret、JVM 参数、资源限制、探针阈值、HPA 和 feature flag 改变，同样可能引发事故。部署记录应同时记录制品版本和配置版本。

7.5 回滚要覆盖应用、配置、数据和外部契约

回滚失败常见原因是只回滚应用镜像，没有回滚配置、数据库、消息格式、缓存、外部 API 契约或 RAG/模型相关资源。Java 云原生服务常常和数据库 schema、消息队列、缓存键、搜索索引、配置中心、第三方 API 和平台策略耦合。发布前必须判断哪些变化可逆，哪些变化只能前滚。

对数据库迁移，优先采用向前兼容策略：先添加字段和兼容代码，再切流量，再清理旧字段。对消息格式，消费者要能处理新旧格式。对缓存键，要能兼容旧值。对配置，要保留上一版。对 Native Image/JVM 双轨，要确认两个制品都能读当前配置和数据。回滚不是一个按钮，而是一组兼容性设计。

本章结论是：供应链证据是生产安全的一部分。下一章讨论故障诊断，把前面的镜像、资源、Kubernetes、Native Image、Serverless 和 CI/CD 串成排查路径。

8. 故障场景与诊断路径：OOM、探针误杀、冷启动、DNS、证书、字体、动态库和发布失败

本章回答的问题是：Java 云原生服务出问题时应该怎样定位。读完这一章，读者应该能把症状映射到 JVM、容器、镜像、Kubernetes、网络、供应链或应用层，而不是盲目改参数。生产边界是：诊断路径必须依赖证据，不能只靠经验。

如果症状是 Pod OOMKilled，先区分 Java heap OOM 和容器 OOMKill。Java heap OOM 通常有异常、heap dump 或 GC 证据；容器 OOMKill 可能没有 Java 堆栈。诊断顺序是容器事件、RSS 曲线、heap 使用、GC log、NMT、direct memory、线程数、Metaspace、native library 和节点压力。修复动作可能是降低 heap 百分比、限制 direct memory、修复 buffer 泄漏、减少线程、扩大 limit、拆分服务或修复本地库。

如果症状是探针误杀，先看 startup/readiness/liveness 的语义。启动慢时被 liveness 杀，说明 startup probe 或延迟配置不合理；下游短暂故障导致 liveness 失败，说明 liveness 依赖了不该依赖的外部系统；readiness 长期失败，可能是应用没有准备好、连接池不可用、配置错误或健康端点逻辑过重。修复动作不是简单增大阈值，而是把探针语义拆清楚。

如果症状是冷启动慢，拆成镜像拉取、容器创建、JVM 启动、类加载、框架初始化、JIT warmup、数据库连接、缓存预热、探针接入和首次请求。不同阶段对应不同修复：镜像拉取慢看镜像大小和节点缓存；JVM/框架慢看 CDS、jlink、懒加载、Native Image 或快照恢复；数据库连接慢看网络和连接池；首次请求慢看 JIT 和缓存。只有分段数据才能决定是否需要 Native Image。

如果症状是 DNS 或证书错误，先看镜像内 CA、JVM truststore、基础镜像更新、Service DNS、CoreDNS、网络策略、mTLS、证书链和域名缓存。极小镜像常缺 CA 或工具，导致排查困难。Java 还可能缓存 DNS 结果，和 Kubernetes 服务发现变化产生冲突。修复时要同时看应用、JVM、安全策略和集群 DNS。

如果症状是字体、时区、本地化或 PDF/图片失败，通常来自镜像裁剪。很多服务在开发环境运行正常，生产 distroless 或 scratch 镜像缺字体、locale、timezone data 或 native image resources 后才失败。诊断要看运行时资源是否存在，而不是只看 Java 代码。

如果症状是 native library 或 JNI 失败，先看 glibc/musl、CPU 架构、动态库路径、文件权限、镜像层、Native Image 链接方式和目标平台。Alpine、distroless、Native Image 和多架构镜像都可能改变 native 行为。对依赖本地库的服务，必须有镜像级集成测试。

如果症状是发布失败，先看 rollout history、镜像 digest、配置 diff、readiness、资源不足、调度失败、镜像拉取、数据库迁移、feature flag、HPA 和下游连接。不要只看新版本应用日志。很多发布失败来自平台层：镜像不可拉取、节点资源不足、探针阈值错误、配置密钥缺失、网络策略阻断或供应链扫描未通过。

症状	优先证据	常见根因	修复方向
OOMKilled	Pod event、RSS、NMT、GC log	heap 过大、direct/native 泄漏	重新预算内存、修资源泄漏
Java OOM	异常、heap dump、GC log	对象保留、缓存过大	修生命周期、限缓存、调 heap
探针误杀	Probe event、启动曲线	startup/liveness 语义混淆	拆探针、调整阈值
冷启动慢	分段启动数据	镜像拉取、框架初始化、JIT	缩镜像、预热、Native Image 评估
DNS/证书失败	truststore、CoreDNS、网络策略	CA 缺失、缓存、mTLS	补证书、调缓存、修策略
字体/时区缺失	镜像资源检查	运行时裁剪过度	补资源、镜像测试
native library 失败	ldd、架构、库路径	glibc/musl/ABI 不匹配	换基础镜像、补库、隔离
发布失败	rollout、digest、config diff	镜像/配置/资源/探针问题	回滚、修证据链

诊断的总原则是：先定位层，再改参数。JVM 问题用 JVM 证据，容器问题用 cgroup 和事件，Kubernetes 问题用 rollout 和 probe，镜像问题用资源和依赖检查，供应链问题用 digest/SBOM/签名，业务问题用 trace 和日志。把所有问题都用一个 JVM 参数解决，只会制造新的不确定性。

8.1 OOM 事故复盘要区分“谁杀死了进程”

OOM 复盘第一句话应该说明谁杀死了进程：是 JVM 抛出 Java OutOfMemoryError，还是 Linux OOM killer 杀死容器进程，还是 Kubernetes 因节点压力驱逐 Pod。三者证据不同、根因不同、修复也不同。Java OOM 通常能在应用日志、heap dump 或 JFR 中看到；容器 OOMKill 通常在 Pod 状态和节点事件中看到；节点驱逐可能和节点压力、QoS 等级、requests/limits 有关。

如果不区分这三类，团队容易做错修复。容器 OOMKill 后盲目增大 heap 可能让问题更严重；Java heap OOM 后只增大 Pod limit 可能掩盖对象泄漏；节点驱逐后只调 JVM 参数可能完全无效。正确复盘要把事件、RSS、heap、native、线程、direct memory、Metaspace 和节点状态放在一起。

复盘还要看时间线。OOM 前是否有发布、流量波峰、HPA 扩容、下游故障、缓存预热、批任务、配置变更、依赖升级或基础镜像变化。Java 内存事故很少凭空发生。时间线能帮助团队区分泄漏、容量不足、发布引入、流量变化和平台事件。

8.2 探针事故复盘要问“重启是否帮助恢复”

liveness 重启只有在进程卡死且重启能恢复时才有意义。如果下游数据库故障，重启应用不会修复数据库，只会放大压力。如果应用只是启动慢，重启会让它永远无法启动。如果 GC pause 短暂变长，重启可能丢失正在处理的请求。探针事故复盘要问：这次重启有没有帮助恢复？如果没有，liveness 条件就是错的。

readiness 事故要问：服务是否过早接流量，还是过晚接流量。过早接流量会导致 5xx，过晚接流量会拖慢发布或扩容。startup probe 事故要问：启动曲线是否被测量，阈值是否覆盖最慢合法启动路径，启动过程中是否做了过重下游检查。探针不是一次配置，而是随应用启动行为变化而调整的契约。

8.3 镜像资源问题要进入自动化测试

证书、时区、字体、locale、DNS、本地库和资源文件问题不能只靠人工记忆。它们应进入镜像级 smoke 测试。比如测试 HTTPS 调用能否验证证书，PDF 或图片路径能否找到字体，时区转换是否正确，DNS 查询是否符合预期，JNI 依赖是否能加载，Native Image 资源是否可读。测试应在最终生产镜像中运行，而不是在构建镜像或开发环境中运行。

这类测试的价值在于发现“代码没错，镜像错了”的问题。云原生把运行环境变成制品的一部分，环境缺失就是制品缺陷。生产镜像越小，这类测试越重要。

8.4 发布失败要保留失败现场

发布失败后，团队常常急于回滚，导致失败现场被清理。回滚止血是正确的，但应尽量保留证据：失败 Pod 的事件、日志、配置、镜像 digest、readiness 失败原因、节点信息、部署记录、HPA 状态和 Service endpoints。没有证据，下一次发布可能重复失败。

平台可以自动采集失败现场。例如 rollout 超时后保存 describe、events、Pod logs、deployment diff、replicaset、image digest 和配置版本。Java 应用也应在启动失败时输出结构化错误，例如缺配置、连接失败、证书错误、类加载失败、Native Image 资源缺失，而不是只抛一长串堆栈。发布失败证据是持续交付系统的一部分。

8.5 下游容量事故：从 Java 扩容反向打穿数据库

一个常见事故链是：业务流量上升，HPA 根据 CPU 或请求量扩容 Java 服务，新增 Pod 启动后每个 Pod 创建固定大小的数据库连接池，下游数据库连接数快速到达上限，请求开始排队和超时，应用重试放大压力，HPA 继续扩容，最终数据库和应用一起抖动。这个事故看起来像数据库容量不足，也像 Java 连接池问题，还像 HPA 策略问题，本质上是系统容量模型缺失。

排查这类事故时，不能只看应用错误率。要同时看 HPA 扩容时间线、Pod 数量、每 Pod 连接数、数据库 active/idle/waiting、连接获取耗时、请求超时、重试次数、CPU throttling 和下游慢查询。止血动作通常不是继续扩容，而是限制 HPA 上限、降低连接池、启用限流、关闭非核心流量、扩大下游容量或切降级路径。长期修复是把下游容量纳入 Java 服务发布和扩缩容评审。

这个事故链说明，云原生弹性不是越多越好。调用方扩容如果没有下游保护，会把局部压力扩散成系统故障。Java 服务常有成熟连接池和线程池，但这些池必须和平台弹性一起设计。HikariCP、HTTP client pool、gRPC channel、Redis pool、消息消费者并发，都不是单 Pod 局部配置，而是全局容量乘数。

8.6 基础镜像漏洞事故：为什么“重建一下”不够

另一个常见事故链是基础镜像出现高危漏洞，安全团队要求所有服务修复。应用团队以为只要改基础镜像 tag 或重新构建即可，但实际发现有些服务使用旧模板，有些镜像没有 SBOM，有些服务无法确认线上 digest，有些镜像重建后行为变化，有些 Native Image 构建失败，有些服务因为字体或证书变化导致运行异常。漏洞响应变成一次大型迁移。

成熟的响应流程应该从资产查询开始。先知道哪些镜像包含受影响组件，哪些环境运行这些 digest，哪些服务对外暴露，哪些服务有补丁镜像，哪些服务可快速重建，哪些服务需要例外。然后按风险分批：外部暴露和高敏服务优先，内部低风险服务按窗口升级。每次重建后跑镜像 smoke、关键接口、证书/DNS/字体/native 测试和灰度。最后更新 SBOM、签名、attestation 和部署记录。

这个事故链说明，供应链安全不是扫描工具的问题，而是资产、构建、测试、准入和运行记录的闭环问题。没有闭环，扫描只会制造待办列表；有闭环，漏洞响应才能变成可执行流程。

8.7 JDK 升级事故：参数、封装和性能基线都可能变化

JDK 升级通常被看作安全补丁或性能提升，但它也可能改变默认行为、废弃参数、TLS、证书、强封装、GC、JIT、诊断工具、locale 和第三方库兼容性。某些服务升级后启动失败，是因为旧 JVM 参数不再支持；某些服务运行后反射失败，是因为模块封装更严格；某些服务延迟变化，是因为 GC/JIT 行为或容器感知参数变化；某些服务证书失败，是因为 truststore 或 TLS 策略变化。

JDK 升级评估应该包含参数扫描、启动 smoke、关键业务路径、GC/JFR 对比、容器资源对比、TLS/证书测试、反射和 --add-opens 检查、Native Image 构建检查、依赖兼容性和性能基线。对重要服务，升级应先在低风险流量灰度，并保留旧 JDK 镜像回滚。不要把 JDK 升级和大量业务变更合并发布，否则性能或兼容性问题很难定位。

JDK 升级还要区分语言版本、运行时版本和发行商支持。某个 JDK line 是 LTS，并不代表所有发行商、所有框架、所有插件和所有基础镜像都已准备好；某个新特性 GA，也不代表业务应立即使用。云原生 Java 的升级策略要同时看安全、支持窗口、生态成熟度和企业验证成本。

9. 治理清单与反模式：上线前、运行中、事故后该检查什么

本章回答的问题是：Java 云原生生产运行如何形成固定门禁。读完这一章，读者应该能建立上线前检查、运行中观测、事故后复盘和长期治理清单。生产边界是：清单不是形式主义，而是把故障经验变成可重复执行的工程纪律。

上线前要检查运行时。JDK/JRE/jlink/Native Image 选择是否有理由，基础镜像是否有补丁来源，镜像 digest 是否固定，SBOM 是否生成，扫描结果是否处理，证书、时区、DNS、字体、locale、本地库和资源文件是否经过镜像级测试，JVM 参数是否按容器资源预算设置，GC/JFR/NMT 或等价诊断能力是否可用，健康端点是否区分 startup/readiness/liveness。

上线前要检查 Kubernetes。requests/limits 是否基于压测，HPA 是否考虑启动和下游容量，readiness 是否只在可接流量时成功，liveness 是否不依赖易抖动下游，termination grace period 是否覆盖优雅停机，滚动发布是否不会打穿数据库连接，配置和密钥是否有版本，服务账户和网络策略是否最小权限，日志和 trace 是否能关联请求。

上线前要检查交付证据。源码 commit、构建环境、依赖锁、镜像 digest、SBOM、扫描、签名、attestation、测试报告、配置 diff、部署计划、灰度策略、回滚步骤和 owner 是否可查。Native Image 服务还要有 native smoke 和 JVM 回退策略；Serverless 服务还要有冷启动、并发、超时、重试和成本证据。

运行中要看四类指标。资源指标包括 heap、RSS、direct memory、Metaspace、线程、CPU throttling、GC、连接池；平台指标包括 Pod 重启、探针失败、HPA、节点压力、镜像拉取、DNS；业务指标包括吞吐、错误率、p95/p99、队列长度、下游超时；供应链和发布指标包括部署批次、镜像 digest、漏洞、签名和配置版本。指标必须能按版本、Pod、节点、租户和功能维度切分。

事故后要复盘证据链。事故发生时运行的是哪个镜像 digest，使用哪个 JDK/GraalVM，配置版本是什么，资源 limit 是多少，Pod 为什么重启，探针为什么失败，是否发生 OOMKill，GC/JFR/NMT 有什么证据，是否有 DNS/证书/字体/本地库问题，是否能回滚，回滚是否真的恢复。复盘的输出应进入清单，而不是停留在个人经验。

阶段	检查项	失败信号	责任方
上线前	运行时、镜像、资源、探针、SBOM、回滚	证据缺失、值靠猜	应用 + 平台
灰度中	p95/p99、错误、重启、探针、连接池	小流量已异常	应用 owner
运行中	RSS、GC、throttling、DNS、证书、漏洞	慢性劣化	运维 + 平台
事故中	分层定位、止血、回滚	只看应用日志	oncall
事故后	根因、清单、自动化门禁	同类问题重复	架构 + 平台

常见反模式包括：把 JPMS 教程当云原生指南；把完整 YAML 当生产经验；把镜像大小当唯一目标；把 -Xmx 当总内存预算；用 liveness 检查数据库；没有 startup probe 却抱怨 Java 启动慢；把 Native Image 当默认更快；Serverless 只看冷启动不看并发和成本；CI/CD 只看构建成功不看 SBOM、签名和回滚；生产镜像没有诊断路径；事故后只改阈值不补证据。

9.1 企业级 Java 服务画像模板

为了避免每个团队用不同语言描述运行需求，可以为 Java 服务建立统一画像模板。模板第一部分是业务画像：外部流量还是内部流量，同步请求还是异步任务，是否客户可见，是否影响交易，是否有合规要求，是否需要多租户隔离。第二部分是技术画像：JVM 还是 Native Image，是否使用 Spring Boot，是否大量反射，是否依赖 JNI，是否需要字体和本地化，是否依赖文件系统，是否需要长连接，是否使用消息队列。第三部分是资源画像：目标 QPS、p95/p99、内存峰值、线程数、连接池、缓存大小、CPU 模型、启动时间和扩容速度。第四部分是运行画像：Kubernetes、Serverless、批处理、CronJob、StatefulSet 还是 Deployment。第五部分是治理画像：SBOM、签名、漏洞策略、回滚要求、诊断工具和 oncall owner。

画像模板的价值在于把运行决策前置。没有画像，平台只能给一个默认模板；有画像，平台可以推荐合理的镜像、资源、探针、HPA、日志、监控和供应链门禁。比如外部低延迟 API 需要更严格的 readiness、p99、连接池和灰度；内部批处理需要更关注重试、checkpoint 和资源峰值；JNI 服务需要镜像级 native 测试；报表服务需要字体、时区和 locale；Serverless 函数需要冷启动、幂等和超时；Native Image 服务需要元数据和 native smoke。

画像还帮助组织沟通。应用团队知道自己要提供什么信息，平台团队知道如何生成模板，安全团队知道哪些场景要提高门禁，运维团队知道事故时找谁。很多云原生问题不是技术不会做，而是信息没有结构化传递。服务画像把这些隐性知识变成显性契约。

9.2 运行手册应按症状组织，而不是按工具组织

运行手册如果按工具组织，例如“如何用 kubectl”“如何看 Grafana”“如何导出 JFR”，oncall 在事故中仍然要自己判断先看什么。更好的手册按症状组织：Pod 重启、OOMKilled、Java OOM、启动慢、readiness 失败、liveness 重启、p99 抖动、CPU throttling、DNS 失败、证书失败、镜像拉取失败、发布卡住、HPA 不扩容、下游连接耗尽、Native Image 路径失败、Serverless 超时。每个症状对应优先证据、排查顺序、止血动作、长期修复和升级路径。

以 p99 抖动为例，手册不应只说“看日志”。它应先确认是否刚发布、是否 HPA 扩容、是否节点 CPU throttling、是否 GC pause、是否连接池等待、是否下游慢、是否 DNS 或证书重试、是否 Service Mesh 重试、是否队列堆积、是否缓存失效。每一步都有证据来源：trace、JFR、GC log、container metrics、Kubernetes events、连接池 metrics、downstream metrics。这样 oncall 不会把所有问题都归因于 JVM。

运行手册还要包含止血动作。比如 OOMKilled 可以先回滚、降流量、扩大 limit 或关闭高内存功能；探针误杀可以暂停发布、调整 startup probe 或临时摘除错误实例；DNS 失败可以切备用域名或回滚镜像；下游连接耗尽可以降 HPA 上限、限制并发或启用降级。止血动作必须有风险说明，不能让 oncall 在压力下临时发明。

9.3 云原生 Java 的组织协作模型

Java 云原生生产运行涉及多个团队。应用团队负责业务逻辑、JVM 参数、健康端点、优雅停机、连接池、业务指标和故障复盘。平台团队负责基础镜像、Kubernetes 模板、CI/CD、镜像仓库、SBOM、签名、运行时基线和观测平台。安全团队负责漏洞策略、镜像准入、Secret 管理、证书、供应链策略和审计。数据团队或中间件团队负责数据库、缓存、消息队列和容量。运维/oncall 团队负责告警、事故响应和运行手册。缺少任何一方，云原生就会变成“应用团队自己摸索 Kubernetes”或“平台团队不了解业务”。

协作模型要明确变更 owner。JDK 升级谁发起，基础镜像更新谁推动，Kubernetes 模板变更谁验证，JVM 参数变更谁审批，探针阈值谁负责，HPA 上限谁确认，Native Image 迁移谁承担回滚，Serverless 成本谁看，漏洞例外谁批准。如果没有 owner，问题会在平台、应用和安全之间来回移动。

协作还要有节奏。平台可以定期发布运行时基线和镜像更新；应用团队定期验证服务画像和容量；安全团队定期清理漏洞例外；运维团队定期演练回滚；架构团队定期复盘模板和门禁。云原生不是一次项目，而是持续协作机制。

9.4 多环境一致性与差异管理

开发、测试、预生产和生产环境不可能完全一致，但差异必须可见。常见差异包括资源大小、外部依赖、证书、数据量、网络策略、Service Mesh、HPA、日志级别、JVM 参数、基础镜像、云区域和权限。差异不可怕，不可见才可怕。一次在测试环境通过、生产失败的发布，通常不是代码突然变化，而是环境差异没有被记录。

多环境一致性的第一原则是同制品晋级。相同镜像 digest 应从测试进入生产，配置差异通过受控配置管理。第二原则是关键差异显式化。资源、探针、JVM 参数、Secret、网络策略和依赖地址应能 diff。第三原则是预生产覆盖关键生产特征。至少要覆盖相同基础镜像、相同 JDK/GraalVM、相似资源限制、相同探针语义、相同证书路径和相同供应链门禁。第四原则是生产变更可回放。任何生产 hotfix 都应回写到代码和配置仓库。

差异管理也影响压测。没有生产等价资源，压测结果只能作为趋势，不应作为容量承诺。没有真实下游容量，HPA 和连接池无法验证。没有真实证书和 DNS，镜像资源问题可能漏掉。架构师应在压测报告中标注环境差异，避免把测试环境结论当生产事实。

9.5 Java 云原生升级策略

JDK、Spring Boot、GraalVM、Kubernetes、基础镜像、Buildpacks、Jib、CI 插件和云厂商运行时都会升级。升级策略不能只看新功能，还要看兼容性、补丁、安全、性能、运行证据和回滚。JDK 升级可能改变 GC、JIT、TLS、默认参数、模块封装和诊断工具；Spring Boot 升级可能改变 Actuator、健康探针、AOT/native 支持和依赖版本；Kubernetes 升级可能改变 API、准入策略和节点运行时；基础镜像升级可能改变 glibc、CA、字体和包版本。

升级应该先做影响矩阵。哪些服务使用相关功能，哪些 JVM 参数可能过期，哪些依赖可能不兼容，哪些镜像需要重建，哪些压测需要重跑，哪些探针和观测可能变化，哪些安全策略需要更新。然后做小批量灰度。对低风险服务先升级，对关键服务保留回滚，对 Native Image 服务重跑 native 构建和 smoke，对 JNI/字体/证书服务跑镜像级测试。

升级还要有冻结和例外机制。不是所有服务都能同时升级，但长期停留在旧 JDK 或旧基础镜像会积累安全和维护风险。平台应定义支持窗口、例外审批和退场计划。Java 云原生的长期稳定，来自可持续升级，而不是一次迁移成功。

9.6 从配置清单转向运行契约

云原生文档最容易退化成配置仓库摘录。大量 YAML、Dockerfile、CI 脚本和 JVM 参数看起来很实用，但读者真正需要的是判断路径。好的文档应先解释场景、原因、观察点和生产边界，再给最小片段。长配置应该放在附录或示例仓库，并默认折叠。正文应回答为什么这样配、什么时候不这样配、失败后看什么、如何回滚，而不是罗列所有字段。

这条原则也是工程规范。如果一段配置无法用几句话说明场景和边界，说明团队可能也没有理解它。配置应该服务运行契约，不能替代运行契约。生产经验不是“我有一份完整 YAML”，而是“我知道每个字段解决什么问题、引入什么风险、用什么证据验证”。

对 Java 云原生团队来说，这一点尤其重要。业务团队不是只需要复制一个 Kubernetes 清单，而是要建立架构判断能力。少量关键片段足以说明 jlink、容器内存、探针、Native Image 元数据和 CI 证据的形状；其余内容都应通过运行契约、表格和诊断路径表达。

9.7 上线前评审要输出一页运行决策

上线前评审不应该只有一堆 YAML 和流水线链接。每个 Java 服务都应有一页运行决策，说明运行时选择、镜像策略、内存预算、CPU 策略、探针语义、优雅停机、连接池上限、HPA 上限、供应链证据、回滚路径和主要故障诊断入口。这一页不是给审计看的形式文档，而是给 oncall、平台和业务 owner 在事故中快速理解系统的地图。

运行决策还要记录“不选择什么”。例如为什么不使用 Native Image，为什么不使用 distroless，为什么暂不使用 jlink，为什么设置 CPU limit，为什么 liveness 不检查数据库，为什么 HPA 上限是某个值。这些“不选择”的理由能防止半年后新人凭感觉改配置，也能让架构演进有上下文。

9.8 平台模板要允许服务画像差异

平台团队通常希望提供标准模板，这是好事，但模板不能抹平所有服务差异。面向外部用户的低延迟 API、内部后台任务、消息消费者、Serverless 函数、Native Image 服务、JNI 服务、报表服务和批处理服务需要不同默认值。一个统一 YAML 模板如果没有画像参数，很容易让某些服务长期处于错误边界。

更好的平台模板是“带决策点的模板”。它提供默认镜像、默认探针、默认资源、默认 SBOM 和默认观测，但要求服务声明画像：HTTP/worker/batch/function、JVM/native、是否 JNI、是否字体、是否长任务、是否连接密集、是否外部流量、是否低延迟。模板根据画像生成建议值，同时允许例外审批。这样平台既能治理一致性，又不牺牲服务差异。

9.9 运行中治理要看趋势，不只看阈值

很多云原生问题是趋势问题。RSS 慢慢上升、direct memory 增长、线程数缓慢增加、GC 周期变密、CPU throttling 逐周变多、镜像漏洞积累、冷启动变慢、发布耗时变长、回滚演练缺失，这些问题在达到阈值前就应该被发现。只靠告警阈值，往往等到事故才处理。

运行中治理应该有周期性审查。每周看错误率、延迟、重启、探针失败、HPA、资源利用；每月看内存趋势、依赖漏洞、镜像补丁、SBOM、基础镜像更新、JDK 更新；每季度看容量模型、回滚演练、Native Image/JVM 策略、Serverless 成本和平台模板。云原生不是一次性迁移项目，而是持续运行纪律。

9.10 事故经验要自动化成门禁

如果某次事故来自缺 CA 证书，就应该把证书检查加入镜像 smoke；如果来自 liveness 检查数据库，就应该把探针规则加入模板审核；如果来自 -Xmx 过大导致 OOMKill，就应该把内存预算检查加入评审；如果来自回滚镜像缺失，就应该把 digest 保留和回滚演练加入发布门禁。事故复盘的价值不在文档，而在自动化门禁。

门禁也要避免过重。不是所有服务都需要同等复杂的流程。低风险内部任务可以轻量，高风险外部服务需要完整。关键是门禁和风险匹配，并且每条门禁都能解释它防止哪类真实事故。没有事故映射的门禁会变成负担，有事故映射的门禁是工程记忆。

9.11 成本治理要覆盖计算、存储、网络和人力

Java 云原生成本不能只看 Pod 使用了多少 CPU 和内存。计算成本包括 requests 预留、limits、节点装箱、空闲副本、HPA 上限和 Serverless 预热；存储成本包括日志、trace、JFR、镜像仓库、SBOM、构建缓存和制品保留；网络成本包括跨区调用、镜像拉取、Service Mesh、外部流量和数据传输；人力成本包括模板维护、漏洞响应、升级验证、事故排查和运行手册。一个看似便宜的运行方案，如果频繁事故或难以诊断，总成本可能更高。

成本治理要和 SLO 一起看。把所有服务资源压得很低，可以降低账面成本，但会增加 throttling、GC、排队和事故风险；给所有服务过量资源，可以降低短期风险，但会浪费节点、掩盖内存泄漏并增加云账单。合理做法是按服务画像设目标：外部关键服务以 SLO 和安全余量优先，内部低风险任务以成本和队列削峰优先，批处理以吞吐和可重试优先，Serverless 以调用频率和冷启动成本平衡。

成本还要有归因。哪个团队、哪个服务、哪个版本、哪个环境、哪个功能消耗了资源，应该能在报表里看到。没有归因，平台只能做全局压缩；有归因，团队才能针对镜像大小、资源 requests、日志量、trace 采样、冷启动、HPA 和构建缓存做优化。云原生成本治理不是财务月报，而是架构反馈。

9.12 安全治理要避免把责任全部推给平台

平台可以提供镜像扫描、准入控制、Secret 管理、网络策略和审计，但应用仍然要承担安全责任。应用知道哪些端点外部可见，哪些数据敏感，哪些配置可以热更新，哪些工具需要权限，哪些日志可能包含个人信息，哪些下游需要证书，哪些错误不能暴露。平台不知道业务语义，无法替应用判断所有风险。

安全治理的正确分工是平台提供默认安全基线，应用声明业务风险，安全团队审核例外。基础镜像、非 root 用户、只读文件系统、最小权限、Secret 注入、网络策略、漏洞门禁、签名准入可以平台化；日志脱敏、业务权限、错误响应、数据分类、审计字段和合规留痕需要应用参与。把安全完全平台化会漏掉业务风险，把安全完全交给应用会造成重复建设和口径不一。

安全例外必须有期限。某个漏洞暂时无法修复，某个服务暂时需要 root，某个镜像暂时不能升级，某个 Secret 暂时用环境变量，这些都可能有现实原因，但必须记录 owner、原因、风险、补偿控制和到期时间。没有到期时间的例外会变成永久风险。云原生平台应把例外当作待关闭任务，而不是长期白名单。

9.13 平台模板的版本化和兼容性

平台模板本身也需要版本化。Deployment 模板、探针默认值、资源建议、日志格式、sidecar、ServiceAccount、NetworkPolicy、HPA、PDB、securityContext、镜像构建模板、CI/CD 模板都可能升级。模板升级会影响大量服务，如果没有版本和兼容性策略，就可能造成批量事故。

模板版本化应允许服务逐步迁移。平台发布新模板后，低风险服务先试用，发现问题后修正，再推广到关键服务。模板变更要有 release notes，说明默认值变化、迁移步骤、回滚方式和已知风险。应用团队不应在不知情的情况下被强制切换运行契约。平台统一和服务稳定之间需要灰度。

模板还要支持废弃策略。旧模板不能无限期保留，否则平台维护成本过高；但废弃前要有迁移工具、差异报告和例外流程。Java 云原生平台的成熟度，不仅体现在模板好不好，还体现在模板如何演进。

9.14 业务连续性和灾备视角

Java 云原生运行还要考虑业务连续性。单集群故障、单区域故障、镜像仓库不可用、配置中心不可用、证书系统故障、DNS 故障、CI/CD 故障、云厂商服务异常，都可能影响服务。云原生平台提高了自动化程度，也引入了新的集中依赖。关键服务需要明确哪些平台依赖是单点，哪些可以降级，哪些需要跨区或多集群策略。

灾备设计不能只复制应用 Pod。还要复制镜像仓库、配置、Secret、证书、数据库、消息队列、缓存、DNS、监控、日志、CI/CD 制品和回滚记录。Java 服务如果依赖本地状态或特定节点资源，也要考虑迁移。Native Image、jlink 和 distroless 镜像在灾备环境中同样要验证证书、字体、时区和动态库。

业务连续性还包括人工流程。事故中谁有权限回滚，谁能批准安全例外，谁能切流量，谁能访问审计数据，谁能恢复镜像仓库，谁能修改 DNS，这些都要演练。云原生工具可以自动化很多步骤，但最终仍需要组织授权链。

9.15 Java 云原生上线证据包

一个 Java 云原生服务上线时，应交付一份证据包。第一部分是制品证据：源码 commit、构建编号、JDK/GraalVM 版本、基础镜像 digest、应用镜像 digest、SBOM、扫描报告、签名或等价可信证明、attestation 和依赖锁。第二部分是运行证据：服务画像、运行时选择、JVM 参数、内存预算、CPU 策略、探针配置、优雅停机、连接池上限、HPA 上限、日志和指标清单。第三部分是验证证据：单元测试、集成测试、契约测试、镜像 smoke、证书/DNS/字体/locale/native 资源测试、启动曲线、关键接口延迟、冷启动或 native 测试。第四部分是发布证据：灰度计划、回滚步骤、配置 diff、数据库迁移兼容性、feature flag、owner 和 oncall。第五部分是事故证据：运行手册、常见症状排查路径、止血动作、升级路径和复盘模板。

证据包不是为了增加流程，而是为了让运行责任可交接。开发者可以离职，平台模板可以升级，JDK 可以换版本，基础镜像可以更新，但证据包让后来者知道当时为什么这样设计、上线时验证了什么、事故时该看哪里。没有证据包，云原生系统会随着人员变化慢慢退化成一堆没人敢动的 YAML。

证据包还应分级。低风险内部工具可以轻量，关键交易服务必须完整；实验性服务可以标记为试点，不能假装生产成熟；Native Image 或 Serverless 服务要增加运行时特定证据；涉及 JNI、字体、证书、跨区流量和高合规数据的服务要增加专项测试。分级让治理既有力度，也不会压垮所有团队。

9.16 平台与应用的共同验收

Java 云原生发布不能只有应用团队自测，也不能只有平台团队套模板。共同验收至少要回答四组问题。应用团队回答业务是否正确、降级是否可用、连接池和线程池是否安全、日志是否脱敏、健康端点是否表达真实状态。平台团队回答镜像是否合规、资源是否合理、探针是否符合平台策略、SBOM 和签名是否齐全、回滚是否可执行。安全团队回答漏洞和密钥是否受控、网络策略是否最小权限、证书和审计是否满足要求。运维团队回答指标、告警、runbook 和 oncall 是否足够。

共同验收的重点是发现边界缝隙。例如应用认为 readiness 能接流量，平台却发现探针路径没有覆盖关键依赖；平台认为 HPA 能扩容，应用却指出数据库连接上限不允许；安全认为镜像扫描通过，应用却记录了敏感字段到日志；运维认为告警足够，开发却无法从告警定位到具体业务路径。把这些缝隙在上线前暴露出来，比在事故中暴露便宜得多。

共同验收还要形成退出条件。哪些问题必须阻断发布，哪些可以作为风险接受，哪些需要灰度观察，哪些需要在下个迭代修复。没有退出条件，评审会变成主观争论；有退出条件，团队可以在风险和交付之间做明确取舍。

本章结论是：Java 云原生治理要把运行时、平台、交付和诊断统一起来。最后一章给出整体判断。

10. 结论：Java 云原生的价值在可运营、可诊断、可回滚的生产边界

本章回答的问题是：Java 云原生最终给企业架构师什么判断。结论是：Java 云原生不是从虚拟机搬到容器，也不是从 JAR 搬到 Native Image，而是把 Java 服务放进可调度、可观测、可验证、可回滚、可审计的生产系统。镜像、Kubernetes、Serverless、Native Image、CI/CD 和供应链安全都是手段，目标是让服务在真实流量、真实故障和真实组织流程中稳定运行。

JPMS 与 jlink 的价值在于让运行时依赖更清晰、运行镜像更可控，但它们不应吞掉整篇云原生主线。Native Image 的价值在于改变启动和内存特征，但它不是 JVM 的全面替代。Kubernetes 的价值在于调度和运行契约，但它不会替应用设计超时、连接池和优雅停机。Serverless 的价值在于弹性和事件模型，但它不适合所有低延迟或长连接服务。CI/CD 的价值在于可追溯交付链，而不是把构建脚本写得更长。

对 Java 架构师来说，真正重要的是建立判断路径。第一，明确服务运行模型：长生命周期、短任务、事件驱动、Serverless、Native Image 还是传统 JVM。第二，定义镜像和运行时策略：完整 JDK、JRE 风格、jlink、distroless、UBI、Alpine、native。第三，做容器资源预算：heap 只是总内存的一部分。第四，设计 Kubernetes 契约：resources、探针、优雅停机、发布和回滚。第五，建立供应链证据：digest、SBOM、扫描、签名、attestation。第六，准备故障诊断路径：OOM、探针、冷启动、DNS、证书、字体、本地库、发布失败。第七，把经验沉淀成门禁和清单。

这也是 Java 在云原生时代仍然强大的原因。Java 不再只是语言和 JVM，而是庞大企业系统中的运行资产。它可以在容器中稳定运行，可以在 Kubernetes 中被调度，可以用 Native Image 适配特定场景，可以通过 Spring Boot 与观测体系结合，可以通过 CI/CD 和供应链证据进入现代发布流程。前提是团队不要把云原生降级为配置堆砌，而要把它当作生产运行工程。

最终判断是：云原生 Java 的成熟度，不看 Dockerfile 多复杂，也不看 YAML 多长，而看事故发生时能否回答五个问题：线上跑的是什么制品，为什么这样配置资源，为什么 Pod 被重启，如何定位故障层，如何安全回滚。如果这五个问题能被证据回答，Java 服务才真正进入了云原生生产状态。

10.1 给架构师的最终行动清单

第一，重新盘点服务画像。不要从现有 YAML 反推架构，而要从业务流量、资源形态、依赖形态、诊断要求和合规要求重新定义服务画像。第二，建立运行时决策记录。说明为什么用 JVM、jlink、distroless、Native Image 或 Serverless，说明为什么不选其他方案。第三，补齐容器资源预算。把 heap、Metaspace、direct memory、thread stack、code cache、native memory 和安全余量列出来，并与压测证据绑定。第四，重审探针和优雅停机。确认 startup、readiness、liveness 语义正确，确认 SIGTERM 后不会丢请求或重复处理。第五，建立供应链证据。每次发布都能追踪 commit、镜像 digest、SBOM、扫描、签名、配置和部署批次。第六，补齐运行手册。按症状组织，不按工具组织。第七，定期演练回滚。没有演练过的回滚不算能力。

这份清单的价值在于把云原生从“部署平台项目”变成“应用架构能力”。平台团队可以提供默认能力，但每个 Java 服务仍要有自己的运行判断。架构师不能把所有问题交给 Kubernetes，也不能把所有问题交给 JVM。成熟的 Java 云原生系统，是应用、平台、运行时和组织流程共同设计的结果。

10.2 与本系列其它篇章的关系

这篇云原生文章不是孤立主题。GC 篇讨论的堆、暂停、JFR 和容器内存，在这里变成资源预算和 OOM 诊断。Loom 篇讨论的虚拟线程和下游保护，在这里变成连接池、线程池、HPA 和容量模型。Valhalla/Panama 篇讨论的 native interop 和内存边界，在这里变成 JNI、动态库、基础镜像和 Native Image 风险。Spring AI 篇讨论的模型网关和成本治理，在这里变成 Serverless、供应链和运行证据。JIT/AOT 篇讨论的 JIT 与 Native Image 边界，在这里变成运行时选择和冷启动判断。生态篇讨论的版本路线，在这里变成 JDK、GraalVM、Kubernetes 和基础镜像升级策略。

也就是说，云原生不是一个部署附录，而是把前面所有 JVM、并发、内存、native、AI 和性能知识放进生产环境的综合考场。只有在容器、Kubernetes、CI/CD、供应链和故障诊断中仍然能做出清晰判断，前面那些技术知识才真正转化成企业架构能力。

10.3 最后的判断

Java 云原生的目标不是追逐最小镜像、最快启动或最长 YAML。目标是让服务在不可避免的变化中仍然可控：JDK 会升级，基础镜像会更新，漏洞会出现，节点会故障，流量会波动，下游会变慢，证书会过期，配置会变化，业务会增长。成熟系统不是没有这些问题，而是问题出现时有证据、有边界、有 owner、有止血、有回滚、有复盘。

如果一个团队能做到这一点，Java 在云原生时代仍然是非常强的企业运行平台。它有成熟 JVM、强生态、可观测工具、丰富框架、供应链工具和大量生产经验。真正需要改变的不是 Java，而是团队对运行边界的理解：从“应用能跑”升级到“系统可运营”，从“配置能用”升级到“证据可追踪”，从“出了问题改参数”升级到“按层定位和自动化门禁”。

10.4 一句话总结给不同角色

对应用开发者来说，云原生 Java 意味着代码之外也有责任：健康端点、优雅停机、连接池、日志、指标、JVM 参数和镜像资源都属于应用质量。对平台工程师来说，云原生 Java 意味着模板之外也有差异：不同服务画像需要不同运行策略，标准化要和例外治理并存。对安全工程师来说，云原生 Java 意味着扫描之外也有证据：SBOM、签名、attestation、Secret、证书、日志脱敏和漏洞例外都要闭环。对架构师来说，云原生 Java 意味着局部优化之外要看系统边界：下游容量、发布策略、回滚路径、成本和组织协作都影响稳定性。

这四类角色如果只在自己的边界内优化，系统仍可能失败。开发者把 JVM 调好，但平台探针误杀；平台模板标准，但应用连接池打穿数据库；安全扫描严格，但回滚镜像缺失；架构设计先进，但 oncall 没有运行手册。云原生成熟度来自角色之间的契约，而不是任何单个工具。

10.5 读者可以立即执行的三步

第一步，选择一个生产 Java 服务，写出一页运行决策：运行时、镜像、资源、探针、连接池、供应链、回滚和诊断入口。第二步，选择最近一次事故或告警，按本文的分层方法复盘：它属于 JVM、容器、Kubernetes、镜像、网络、供应链还是业务层，缺了什么证据，能否自动化成门禁。第三步，选择一个最长的配置清单，把它改写成“场景、原因、观察点、生产边界、最小片段、诊断路径”。如果这三步做完，团队对 Java 云原生的理解会比复制十份模板更扎实。

最终，Java 云原生不是一组工具名，而是一种生产工程能力。它要求团队把 JVM 的细节、容器的限制、Kubernetes 的生命周期、供应链的证据、业务的 SLO 和组织的协作放在同一张图里思考。能做到这一点，Java 服务就不仅能在云上运行，而且能在云上长期、稳定、可解释地运行。

10.6 面向未来的判断

未来几年，Java 云原生还会继续演进。JDK 会继续改善启动、内存、并发、JIT/AOT 和容器感知；GraalVM Native Image 会继续降低动态特性成本；Project Leyden、CRaC 和云厂商快照技术会继续探索启动路径；Kubernetes 和 Serverless 平台会继续改善调度、供应链和可观测性；SBOM、签名和 attestation 会从“安全加分项”逐步变成准入基础。工具会变，但生产问题不会消失：资源预算、下游保护、证据链、回滚、诊断和组织协作仍然是核心。

因此，架构师不应押注某个单点技术解决所有问题。更稳妥的策略是建立可演进边界：运行时可替换，镜像可重建，配置可回滚，指标可对比，供应链可追踪，服务画像可更新，平台模板可升级。只要边界清晰，团队就能吸收新技术；边界混乱时，新技术只会带来新的不确定性。

还有一个更容易被低估的未来判断：Java 云原生能力会越来越像“组织运行系统”，而不是单个团队的部署技巧。平台团队负责抽象通用能力，应用团队负责声明业务语义，安全团队负责准入和例外，运维团队负责观测和事故流程，架构师负责把这些边界放进同一套决策语言。只有当这些角色都能读懂同一份运行证据，云原生才不会退化成各自为政的工具堆叠。

例如一次 JDK 升级不应只是修改基础镜像 tag。它应该触发依赖兼容性检查、启动曲线对比、GC 与 JIT 基线对比、容器内存峰值对比、Native Image 构建验证、探针行为验证、TLS 与证书验证、镜像漏洞对比和回滚演练。一次 Kubernetes 模板升级也不应只是替换 YAML。它应该说明默认资源、探针、securityContext、ServiceAccount、NetworkPolicy、PDB、HPA 和日志采集字段发生了什么变化，哪些服务画像受影响，哪些服务可以自动迁移，哪些服务需要人工评审。

这就是本文反复强调“证据”的原因。证据不是文档装饰，而是跨角色协作的接口。没有证据，平台说“模板没问题”，应用说“代码没问题”，安全说“扫描通过”，运维说“告警正常”，但事故仍然可能发生；有证据，团队至少能把争论收敛到事实：哪个版本、哪个配置、哪个资源边界、哪个指标、哪个依赖、哪个发布批次引发了变化。

对企业架构师来说，未来的关键能力不是记住更多工具名，而是建立可重复的决策闭环。引入新技术前，先定义它解决的症状和不解决的问题；试点时，记录基线、收益、失败模式和回滚路径；推广时，把经验沉淀为模板、门禁和运行手册；淘汰时，给出迁移窗口、兼容策略和例外管理。这样组织才不会被每一轮云原生潮流牵着走，而能把新技术吸收到稳定的生产体系里。

如果用一句工程判断结束这一篇：Java 云原生的竞争力不来自某个最小镜像、最快冷启动或最新平台功能，而来自持续把复杂运行事实变成可理解、可验证、可回滚的系统边界。能把这件事做好，Java 仍然是企业核心系统非常可靠的运行底座；做不好，再先进的容器平台也只会把不确定性自动化、放大化和规模化。

落到日常工作中，最值得长期坚持的是“小步升级、证据对比、快速回退”。每次改 JDK、基础镜像、探针、资源、HPA、构建模板或运行时形态，都要留下变更前后的运行证据，并明确如果指标恶化如何回退。很多团队的风险不在于不会使用新技术，而在于每次升级都像重新赌博：没有基线、没有灰度、没有回滚、没有责任人、没有复盘入口。云原生的真正收益，是让这些变化变成可管理的工程流程。

因此，本文最终给出的不是某份固定配置，而是一套判断顺序：先定义服务画像，再选择运行时，再计算资源，再设计平台契约，再补齐供应链证据，再准备诊断和回滚，最后把事故经验反哺模板。这个顺序不一定最短，但足够稳。对企业系统而言，稳定可解释的演进路径，往往比一次性的极限优化更有价值。

如果读者只能带走一个检查动作，那就是在下一次上线前追问：这个服务的运行边界是否能被新人、平台、oncall 和安全团队共同复述。如果不能，说明云原生改造还停留在部署层；如果能，才说明配置已经转化为组织可以共享的生产知识。

参考文献

1. Oracle Java SE Support Roadmap: https://www.oracle.com/java/technologies/java-se-support-roadmap.html
2. Oracle JDK 26 Release Notes: https://www.oracle.com/java/technologies/javase/26all-relnotes.html
3. OpenJDK JEP 261: Module System: https://openjdk.org/jeps/261
4. OpenJDK jlink Tool Guide: https://docs.oracle.com/en/java/javase/25/docs/specs/man/jlink.html
5. GraalVM Native Image Documentation: https://www.graalvm.org/latest/reference-manual/native-image/
6. Kubernetes Resource Management for Pods and Containers: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
7. Kubernetes Liveness, Readiness, and Startup Probes: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
8. Spring Boot Actuator Kubernetes Probes: https://docs.spring.io/spring-boot/reference/actuator/endpoints.html#actuator.endpoints.kubernetes-probes
9. Jib Project Documentation: https://github.com/GoogleContainerTools/jib
10. Buildpacks Documentation: https://buildpacks.io/docs/