优雅停机让请求体面地结束默认情况下SpringBoot收到停止信号会立即关闭容器正在处理的请求直接被中断。用户看到的是502或连接重置。优雅停机的思路是收到停止信号后先拒绝新请求给正在处理的请求留出完成时间再关闭应用。配置只需两行。在application.yml中yaml复制下载server: shutdown: graceful spring: lifecycle: timeout-per-shutdown-phase: 30sserver.shutdown: graceful开启优雅停机。timeout-per-shutdown-phase设定最大等待时间超时则强制关闭。当应用收到SIGTERMWeb服务器会停止接受新连接等待活跃请求结束。如果30秒内没处理完才会强制退出。这个机制在Kubernetes里尤其重要。Pod被删除时K8s先发送SIGTERM等待terminationGracePeriodSeconds后发送SIGKILL。如果SpringBoot的优雅停机超时时间小于K8s的宽限期就能保证请求完整处理。否则K8s会在请求处理到一半时杀掉进程。建议将timeout-per-shutdown-phase设为25秒K8s的terminationGracePeriodSeconds设为30秒留出缓冲。健康检查让编排系统准确判断状态SpringBoot Actuator提供了开箱即用的健康检查端点。引入依赖xml复制下载运行dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency默认暴露/actuator/health返回{status:UP}。但生产环境需要更细粒度的探针。Kubernetes区分liveness和readinessliveness判断容器是否活着失败则重启readiness判断容器是否准备好接收流量失败则从Service端点摘除。SpringBoot 2.3支持探针分组。配置yaml复制下载management: endpoint: health: probes: enabled: true show-details: always health: livenessstate: enabled: true readinessstate: enabled: true这样会暴露/actuator/health/liveness和/actuator/health/readiness。liveness检查应用内部状态比如是否死锁readiness检查依赖的外部资源比如数据库、Redis是否可用。如果数据库暂时不可用readiness应返回DOWNK8s会停止向该Pod发流量但不会重启它等依赖恢复后自动重新加入。自定义健康指示器内置检查覆盖了数据库、磁盘、消息队列等常见依赖。如果有自定义组件实现HealthIndicator接口即可java复制下载Component public class CustomHealthIndicator implements HealthIndicator { Override public Health health() { if (isHealthy()) { return Health.up().withDetail(custom, ok).build(); } return Health.down().withDetail(custom, failed).build(); } }这样/actuator/health会包含你的自定义状态。注意liveness探针不应包含外部依赖否则数据库抖动会导致Pod被反复重启反而放大故障。liveness只检查应用自身readiness才检查外部依赖。生产实践建议优雅停机和健康检查要配合使用。K8s的preStop钩子可以加一个短暂sleep等待Service端点更新完成再发送SIGTERM。否则Pod从端点摘除和收到停止信号几乎同时发生可能有少量请求仍被路由过来。加5秒preStop延迟能消除这个窗口。另外健康检查端点不要暴露敏感信息。show-details: always方便调试但生产环境建议设为when-authorized只对内部网络或特定角色开放。Actuator端点也应通过management.server.port独立端口暴露避免和业务端口混用。优雅停机和健康检查不是银弹但它们是生产环境的底线。配置得当发版时用户无感知故障时编排系统能准确判断避免雪崩。花十分钟配好这两项比事后半夜爬起来处理告警划算得多。