Tomcat升级本身不强制停机，零中断依赖错峰切换与冗余承接：通过Nginx反向代理实现灰度切流、Redis外置会话、配置解耦及一键回滚，配合K8s滚动更新可保障业务无感升级。
保障业务零中断不是靠“不重启”，而是靠“错峰切换+冗余承接”。Tomcat 本身是单进程容器，一次升级必然涉及进程重启，但通过合理架构设计和流程控制，可让终端用户完全感知不到服务中断。
前置：确认是否真需停机升级
多数场景下，Tomcat 升级本身不强制停机——只要新旧版本配置兼容、应用二进制无强依赖、JVM 参数可平滑迁移，就具备热切换基础。真正造成中断的，往往是以下操作：
- 直接 kill 进程再启动新版本（最常见误操作）
- 未做灰度验证，上线即全量，出问题回滚耗时长
- 共享存储（如 session 存 Redis）未启用或配置不一致，导致会话丢失
- 反向代理（Nginx/Apache HTTPD）未配置健康检查，无法自动摘除异常节点
关键：用反向代理实现平滑滚动升级
这是企业级零中断升级最成熟、最低风险的方式。核心思路是让流量在新旧实例间逐步切流：
- 部署新版本 Tomcat 实例（不同端口，如 8081），保持与旧版（8080）并行运行
- 在 Nginx 中配置 upstream，加入两个 server，并开启 health_check 或基于 /health 端点的主动探活
- 先将新实例权重设为 0，验证其静态资源、管理页、应用接口是否正常
- 逐步调高新实例权重（如 10% → 50% → 100%），同时监控错误率、响应时间、GC 日志
- 确认稳定后，再关停旧实例（8080）；若异常，秒级切回旧版
必须配套的三项加固动作
仅靠代理切换不够，还需从状态、配置、回滚三方面兜底：
- 会话状态外置：禁用 Tomcat 默认的 in-memory session，改用 Redis 或 JDBC Session Manager，确保用户请求跨实例不掉登录态
- 配置文件解耦：把 server.xml、context.xml 中与环境强相关的部分（端口、路径、JDBC URL）抽到外部 properties 文件，避免升级时手改出错
- 一键回滚包就绪：升级前打包包含旧版 bin/、conf/、webapps/ 的完整快照，并验证 restore 脚本——不是“能备份”，而是“能 2 分钟内恢复服务”
进阶：容器化环境下的原地升级（K8s 场景）
若运行在 Kubernetes 上，可进一步简化流程：
- 使用 RollingUpdate 策略，设置 maxSurge=1, maxUnavailable=0，保证升级中 Pod 总数不减
- 在 readinessProbe 中加入对 /manager/status 的健康检测，确保新 Pod 真正 ready 后才接收流量
- 利用 InitContainer 预检 Java 版本、配置语法、JAR 签名，失败则跳过该 Pod 启动
