HelloWorld 滚动重启指南

滚动重启是在不中断整体服务的前提下，逐台或逐批替换运行实例的做法。它用于发布更新、修复问题或回收资源，同时保持可用性。关键在于有序下线、就绪检测和流量导引，避免请求打到未就绪实例。本文按步解释何时使用、常见策略（如Kubernetes、负载均衡排空、会话迁移）、常见陷阱及实战命令与检查表，便于生产环境安全执行。

先把概念讲清楚：什么是滚动重启

把滚动重启想像成替换一列火车的车厢：不把整列车停掉，而是把一节一节换上新的车厢，确保乘客不会被赶下车，也不会一上来就掉进缝隙里。技术上，它指的是按顺序重启服务实例（或节点），每次只影响一部分流量，待新实例健康后再处理下一批。

为什么要用滚动重启

• 零/低停机：用户请求不中断或中断最小化。
• 风险分散：如果新版本有问题，只影响少量实例，便于回滚。
• 容量保持：通过控制并发替换比例，维持整体服务能力。
• 顺序部署：支持渐进式发布、金丝雀或A/B测试。

何时不该用滚动重启

• 数据库架构非向后兼容的重大迁移（需要先做数据兼容性或停机窗口）。
• 外部依赖强一致性要求，短时间内跨版本协作会导致错误。
• 当实例启动时间极长且无法承担双版本协作时，可能需要蓝绿部署或计划停机。

常见策略对比

滚动重启的核心要素（靠谱清单）

• 可观测性：完整的日志、指标（错误率、延迟、吞吐）和追踪。
• 健康检查：就绪（readiness）和存活（liveness）探针必须配置正确。
• 优雅下线：确保实例在接到下线信号后停止接新连接并完成旧连接。
• 连接排空（drain）：负载均衡器或服务发现应支持将流量从正在下线实例逐步导出。
• 会话/状态管理：避免本地黏性会话或采用外部会话存储。
• 迁移策略：数据库变更采用 expand-contract（扩展—兼容—收缩）模型。

实战步骤（一步一步来）

准备阶段

• 确认变更类型：配置、依赖、代码还是架构变更？
• 检查兼容性：前后端、数据库、消息队列协议是否兼容。
• 创建回滚计划：版本回退步骤与回退触发阈值（错误率或延迟）。
• 设定维护窗口与通知相关方。

预演与测试

• 在预发布环境复现重启流程并做容量测试。
• 模拟失败场景（某批次无法就绪、慢启动等）。
• 验证监控告警是否能及时触发。

执行阶段（以Kubernetes为例）

最简单的命令是：kubectl rollout restart deployment/my-app。真实场景需要设置滚动参数：在Deployment中配置strategy.rollingUpdate的maxUnavailable和maxSurge。

• 示例：maxUnavailable=1, maxSurge=1 表示每次替换1个实例，允许短时间增加1个新实例以保持容量。
• 确保readinessProbe和livenessProbe配置合理，preStop hook用于优雅关闭。
• 观察：kubectl rollout status deployment/my-app；如果超时或错误，触发回滚：kubectl rollout undo deployment/my-app。

非容器化实例（例如物理机或VM）

• 通过负载均衡器API标记节点为 draining（移除流量）。
• 等待当前连接清零或达到安全阈值（例如 30s、60s），再停止服务。
• 重启进程/软件，确认健康检查通过后再逐个恢复流量。

优雅关闭的实践细节

优雅关闭不是靠猜的，需要代码和基础设施配合：

• 捕捉终止信号（SIGTERM），在处理逻辑里先停止接新请求，然后等待当前请求完成或超时关闭。
• 短超时 vs 长超时：设置合理的请求超时，避免无限等待；同时给后台任务一点缓冲时间。
• preStop hook：在容器中提供preStop脚本，通知应用准备关闭（例如把实例从服务发现移除）。

会话与状态的实际处理方式

• 尽量无状态化：如果可以，把状态放到Redis、数据库或专门的会话服务。
• 若必须粘性会话：控制粘性失效时间，或在替换前把粘性路由短暂切换到新实例。
• 事务性操作：使用幂等或补偿机制，避免半成品数据。

数据库变更的常见模式

数据库通常是滚动重启的绊脚石，推荐的模式：

• Expand-Contract（扩展—使用—收缩）：先添加向后兼容的列/索引，部署代码使用新列，再删除旧列。
• 双写/回写：短期内同时写入旧结构和新结构，验证完毕后切换读取。
• 复杂迁移可在维护窗口执行，或用专门的迁移工具逐步迁移。

监控与回滚触发条件（示例阈值）

• 错误率上升 > 2x 且持续 5 分钟 → 触发警报并评估是否回滚。
• 平均延迟增加 > 50% 且伴随错误率上升 → 考虑回滚。
• 资源异常（内存、CPU）超出预期 → 停止进一步替换并排查。

常见问题与陷阱

• 就绪探针配置太宽松：会把未完全就绪的实例纳入负载，导致用户请求失败。
• 没有排空连接：立即下线会丢失短连接或TCP会话。
• 依赖不兼容：新旧版本并存时服务间协议不兼容会暴露问题。
• 忽视后端资源：短时间并发峰值可能压垮数据库或缓存。

常用命令速查（示例）

• Kubernetes：kubectl rollout restart deployment/my-app；kubectl rollout status deployment/my-app；kubectl rollout undo deployment/my-app。
• Node drain：kubectl drain node/ –ignore-daemonsets –delete-local-data。
• NGINX upstream 下线：将 upstream server 标记为 down，或在 upstream 上设置 max_fails/ fail_timeout 再 reload。
• HAProxy：通过 admin socket 执行 disable server backend/name/server/name。

执行后的检查表（短）

• 所有实例就绪且健康检查通过。
• 错误率和延迟回到基线。
• 关键业务API的端到端测试通过。
• 监控报警处于正常或已受理状态。

小贴士（生活化的经验）

• 把重启演练当作例行体检：偶尔做全量重启，找出隐藏问题。
• 保持变更小而频繁：小变更更容易回滚和定位问题。
• 别把所有实例设为一台一台手工处理：自动化减少人为错误，但先在预发布练熟脚本。
• 写好“回滚说明书”，并把触发回滚的步骤写得清楚、短小。

如果你现在就要操作，一条实用流程：先在预发布用相同流量走金丝雀，验证链路稳定；然后设置maxUnavailable和Probe，逐批上线；监控阈值一旦触及就按预案回滚。唉，说了这么多，但每个团队的细节不同，照着清单一步步做，问题通常就能被切成能吞下的小块，慢慢解决—就像修自行车一样，别一次拆太多螺丝。