服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

公司 K8s 每次发版都有几个 502。查了监控，规律很明显——总是在旧 Pod 被 kill 的那几秒。原来是 K8s 滚动更新的时候，先发 SIGTERM 给旧 Pod，然后立刻把流量切到新 Pod。但旧 Pod 上还有正在处理的请求——SIGTERM 一来，进程直接退，请求半途而废。前端就 502 了。 Spring Boot 2.3 以后支持优雅停机，但光配 server.shutdown=graceful 还不够。K8s 的流量切换和 Pod 停机之间有时间差——你得让 Pod 在被 kill 之前有足够时间把正在处理的请求跑完。 问题拆解：K8s 发版一分钟内发生了什么 K8s 滚动更新流程： T+0s 新 Pod 创建，等待就绪 T+5s 新 Pod Ready → 加入 Service Endpoint T+5s K8s 发 SIGTERM 给旧 Pod T+5s 旧 Pod 上的请求还在跑 → 但 Service 已经不分配新请求了 T+5s 旧 Pod 收到 SIGTERM → Spring 开始优雅停机 ├─ 不再接受新请求 ├─ 等待正在处理的请求完成（30....

前言 在 Kubernetes（K8s）环境中部署应用时，一个常见的问题就是：流量被分发到还未完全就绪的实例，导致用户请求失败或超时。这不仅影响用户体验，还可能引发连锁故障，造成严重的业务损失。 想象一下这样的场景：你的应用正在 K8s 中进行滚动更新，新的 Pod 刚启动，但应用还在初始化数据库连接、加载缓存数据、预热连接池。此时，K8s 的 Service 已经将流量路由到这个新 Pod，但由于应用还未完全就绪，所有请求都失败了。更糟糕的是，如果多个新 Pod 同时出现这种情况，整个服务可能陷入不可用状态。 应用启动健康检查和就绪探针（Readiness Probe）是解决这个问题的关键技术。它们可以帮助 K8s 准确判断应用是否真正准备好接收流量，避免将请求发送到未就绪的实例。 本文将详细介绍如何在 SpringBoot 项目中实现应用启动健康检查和就绪探针，构建一个在 K8s 环境中稳定可靠的应用系统。 一、健康检查和就绪探针的核心概念 1.1 什么是健康检查 健康检查（Health Check）是一种用于检测应用运行状态的机制，它定期检查应用是否正常运行。健康检查通常包括： ....