Audit or harden an existing ap…

# Spring Boot 电商订单系统 v2.3 发布前可用性加固方案

一、灰度发布检查清单

1. 灰度策略设计

• 按流量比例灰度：建议通过 K8s Service / Istio 配置权重路由，首批放 5%~10% 流量，观察 30~60 分钟后再逐步放量（如 10% → 30% → 50% → 100%）
• 按用户维度灰度：优先对内部账号、白名单用户、低价值测试订单开放，避免影响主力交易用户
• 按 API 分级灰度：订单创建/支付回调等核心链路最后放量，查询类接口可先行

2. K8s 层面检查项

• readinessProbe / livenessProbe 配置：确保就绪探针检测依赖（DB、Redis、MQ）连通性，避免新 Pod 未就绪即接流量
• 滚动更新参数：设置 maxSurge / maxUnavailable（如 25%/25%），保证更新期间服务容量充足
• PodDisruptionBudget：防止节点维护时同时驱逐过多实例
• preStop 钩子 + 优雅停机：配置 server.shutdown=graceful，等待存量请求（尤其支付回调）处理完再退出

3. 流量一致性

• 新老版本共用数据库时，确认 schema 变更向后兼容（只加列不删列、新旧代码可共存）
• MQ 消费者版本兼容：老版本 Pod 产生的消息新版本能消费

二、回滚方案检查清单

1. 回滚触发条件（明确量化标准）

• 订单创建成功率跌破阈值（如低于 99.5%）
• 接口 P99 延迟超预算（如超过原基线的 1.5 倍）
• 支付回调积压、MQ 死信队列异常增长

2. 回滚手段与时效

• 镜像回滚：保留 v2.2 前一版本镜像，验证 kubectl rollout undo 链路，目标回滚时间控制在 5 分钟内
• 配置回滚：Nacos/Apollo 配置变更单独可回退，避免配置与代码耦合
• 数据库回滚预案：新增表/字段保留不删，写好反向兼容说明；破坏性变更须先演练

3. 回滚演练（上线前必做）

• 在预发环境完整演练一次“发布 → 发现异常 → 回滚 → 验证”全流程
• 验证回滚后灰度期间的新数据在老版本下可正常读写

三、上线前其他加固建议

• 全链路压测：按日订单 2 万的 2~3 倍峰值预估压测，覆盖下单、支付回调、库存扣减
• 发布窗口选低峰期，安排值班表与告警升级路径
• 关键监控就位：业务指标（订单量/成功率）+ 技术指标（JVM、DB 连接池、慢 SQL）
• 准备应急预案文档：含回滚命令、联系人、降级开关（如关闭非核心推荐/积分逻辑）

建议时间线：周一完成灰度配置与探针检查 → 周二预发全量演练含回滚 → 周三评审发布清单 → 周四按计划灰度上线。