灰度发布方案#

实现方式：

1. 网关路由：按 header/cookie/IP 路由到新版本
2. 权重分流：Nginx/Istio 按百分比分流
3. 用户标签：特定用户群先灰度

K8s 实现： 两个 Deployment + Istio VirtualService 按权重分流

灰度发布的核心思想是不一次性全量上线，而是按用户或流量比例逐步将请求切到新版本，观察没问题再扩大范围。实现方式主要有三种：第一种是网关路由，在 Spring Cloud Gateway 或 Nginx 层根据请求的 header、cookie 或 IP 地址把特定请求路由到新版本的服务实例；第二种是权重分流，通过 Istio VirtualService 或 Nginx upstream 按百分比分配流量，比如先切 5% 的流量到新版本；第三种是用户标签，比如先让内部员工或特定地区的用户使用新版本。在 Kubernetes 环境下，我们通常部署两套 Deployment，一套旧版本一套新版本，通过 Istio 的权重配置逐步调整流量比例。灰度期间要重点监控错误率、响应时间和关键业务指标，不能只看错误率。出问题时把权重调回 0% 就能立即回滚。全链路灰度还要考虑下游服务和消息队列的版本隔离。

追问方向：

• “灰度出 bug 怎么回滚？”→ 流量网关立即将灰度流量切回老版本，然后下线灰度实例；K8s 场景直接 kubectl rollout undo 回滚 Deployment，保证几秒内生效
• “全链路灰度怎么做？”→ 在请求头注入灰度标签（如 x-gray: true），通过网关→RPC→MQ 全链路透传标签，每个中间件根据标签路由到灰度实例/灰度队列，确保灰度流量闭环不污染正式环境
• “A/B 测试和灰度区别？”→ A/B 测试目的是对比不同方案的效果（需要对照组和数据统计），灰度发布目的是降低新版本风险（逐步放量验证稳定性）；A/B 看指标差异，灰度看异常兜底

易错点：

• ❌ 灰度就是按比例分流——还可以按用户标签
• ❌ 灰度只看错误率——还要看性能和业务指标