本文是《MCP实战手记系列十MCP Server高可用实战》的延伸知识点。完整的高可用方案多实例、负载均衡、熔断降级、Redis哨兵见系列十。多实例部署完之后很多团队以为高可用就做完了。但生产里绝大多数实例下线是运维主动发起的发版重启。而事故恢复那套Nginx把死实例摘掉管不了这个场景进程是被主动kill的Nginx要等请求失败攒够max_fails才知道那批请求已经变成502了。也就是说如果只做故障恢复不做优雅停机这覆盖的只是那10%的场景每次发版都会稳定地甩给用户一批错误。四步流程摘流量 → 等请求排空 → 停进程 → 部署新版本 → 健康检查通过 → 加回流量第一步应用侧开优雅停机。Spring Boot两行配置server:shutdown:graceful# 停止接收新请求等存量请求处理完再退出spring:lifecycle:timeout-per-shutdown-phase:30s# 最多等30秒超时强杀开了之后Tomcat先停止接受新连接把在途请求处理完才退出。第二步Nginx侧摘流量。最省事的是把该实例在upstream里标成downupstream mcp_backend { server 10.0.0.12:8088 down; # 摘掉准备发版 ... }改完nginx -t验一下语法再reload——reload不是重启但不代表可以跳过校验。第三步等排空。等的时间按最长超时给一般30秒够。第四步滚动发布。多实例就是这套流程对每个实例轮流做一遍一次只动一个保证其他实例一直在接客。三个坑坑一等待时间必须大于最长工具超时。这条最容易忽略。配了timeout-per-shutdown-phase: 30s但有个下游调用的超时也是30秒——真有请求卡满30秒时停机等待同时到期直接强杀优雅停机等于没开。要么把下游超时压下去要么把等待时间加长两者不能相等。坑二健康检查会拖长停机。应用已经进入shutdown流程了但/actuator/health可能还返回UP取决于停机阶段Nginx还会往里发请求。Spring Boot的readiness探针在停机时会转为DOWNK8s环境下这一步是自动的裸机 Nginx的就得靠主动标down。坑三无状态HTTP模式和SSE长连接模式不是一回事。本文这套在无状态HTTP模式下很干净没有长连接要drain。如果是SSE长连接还得处理存量长连接怎么迁移、客户端重连会不会形成风暴——那是另一个问题本文不覆盖。小结优雅停机不是高级功能是发布流程的基本配置。四步里最容易漏的是第一步应用侧配置和第一、二步之间的配合——只开应用侧配置、不摘流量Nginx照样在停机窗口里往里发请求。同专题推荐本文是「MCP Server高可用」小专题的第2篇共5篇Nginx开源版没有主动探活四种补救方案和一个能用的脚本发版就掉请求Spring Boot优雅停机的四步← 当前这篇超时不是一个数字是一套体系MCP Server的五条约束待发高可用配完之后该看哪几个指标池子该设多大待发缓存穿透、击穿、雪崩三个概念三种解法待发相关阅读《MCP实战手记系列十MCP Server高可用实战》本文延伸自该篇《MCP实战手记系列八无状态之后的生产落地清单》配套代码https://gitee.com/ethanliang2016/mcp-in-actiontagv10