后端服务如何做灰度发布和蓝绿部署

**结论：灰度发布和蓝绿部署解决的是两个不同问题——蓝绿部署解决"发错了怎么在 30 秒内退回去"，灰度发布解决"新版本放出去会不会炸"。生产上最稳的做法是两者叠加：用蓝绿建出可一键回滚的两套环境，再用灰度控制放量节奏，比例按 1% → 5% → 10% → 30% → 50% → 100% 递进。**

灰度发布和蓝绿部署有什么区别？

**结论：蓝绿部署是"两套完整环境、同一时刻只有一套接流量、切换是二元的"；灰度发布是"新旧版本同时在线、按比例或按规则分流、放量是渐进的"。**

蓝绿部署里 blue 是当前生产环境，green 是部署好新版本的环境。切流前 green 拿 0% 流量，切流后拿 100%，中间没有 30% 这种状态。它的优势是回滚极快——把负载均衡或网关的路由指回 blue 即可，通常 10 秒内生效；代价是资源要双份，成本翻倍。

灰度发布（也叫金丝雀发布）是新旧版本共存，流量按权重或规则切分。粒度可以细到"只让 uid % 100 < 5 的用户走新版本""只让带 x-gray: true 请求头的内部测试账号走新版本"。它的优势是爆炸半径可控，代价是同一时间两套代码都在跑，对数据兼容性要求高得多。

蓝绿部署具体怎么做？六个步骤

**结论：蓝绿部署的关键不在切流动作，而在切流前的数据库兼容性验证和切流后的观察窗口。**

1. 确认数据库变更双向兼容：新增字段必须有默认值，不改字段类型、不删字段、不改语义。做不到就先做 expand-contract 三步走——先加新字段，双写并回填历史数据，等两个发布周期后再删旧字段。
2. 部署新版本到 green 环境，不挂载到生产流量入口。
3. 对 green 跑冒烟测试和健康检查，确认 /healthz 返回 200、依赖的 DB/Redis/MQ 全部连通。
4. 切流：K8s 里改 Service selector 指向 version: green；用 Istio 则是把 VirtualService 的 weight 从 100/0 改成 0/100；用 Nginx 则是改 upstream 权重。
5. 观察 10-15 分钟，盯四个指标：HTTP 5xx 比例、P99 延迟、CPU/内存、下游依赖错误率。
6. 异常则切回 blue；正常则保留 blue 环境至少 24 小时，确认无长尾问题后再销毁。

注意点：不要在同一台机器上混跑 blue 和 green 的进程，端口和本地缓存会串。

灰度发布怎么按比例放量？

**结论：灰度分流的三种主流实现是按网关权重、按注册中心元数据、按业务规则，按用户维度分流比按请求维度分流更能保证体验一致。**

• 网关权重：Istio 的 VirtualService 写 weight: 90 / 10；Nginx 用 split_clients "${remote_addr}" $variant { 5% gray; * prod; } 按客户端 IP 哈希分配 5% 流量；Spring Cloud Gateway 用自定义 WeightCalculatorWebFilter。
• 注册中心元数据：Nacos 给实例打 version=v2 标签并配权重，Spring Cloud LoadBalancer 按权重挑选实例。这种方式无需改网关，但要求所有调用方都走注册中心。
• 业务规则：uid % 100 < 5 这种对用户 ID 取模的方式，能保证同一用户在整个灰度期始终命中同一版本，避免"刷两次页面看到两个版本"。内部白名单则用请求头 x-gray: true 或公司内网 IP 段直接放行。

放量节奏建议：每档至少观察 10 分钟，且至少覆盖一个业务高峰时段。1% 到 5% 之间不要跳，因为 1% 只能验证"能不能跑通"，5% 才能暴露并发问题。

为什么数据兼容是灰度发布最大的坑？

**结论：灰度期间新老版本同时读写同一份数据和同一个消息队列，任何不向前兼容的变更都会导致老版本崩溃。**

三条硬规则：一、消息格式只加字段不删字段，新老消费者都要能反序列化对方发的消息；二、缓存 key 加版本前缀，如 user:v2:{id}，或干脆双写；三、分布式锁、幂等键的语义不能变，否则会出现重复扣款这类事故。数据库变更统一走"先兼容、后使用、再清理"，禁止在同一个发布里既加字段又删字段。

出了问题怎么回滚？

**结论：蓝绿回滚是切路由，秒级；灰度回滚是把灰度权重置 0，同样是秒级，前提是旧版本实例没有被全部替换掉。**

所以不要在灰度期间做全量滚动更新。K8s Deployment 应设置 maxSurge: 1、maxUnavailable: 0，保证任何时刻都有足量旧版本实例在线。如果用了 Argo Rollouts 或 Flagger，可以配置 Prometheus 查询作为自动晋级条件：错误率超过 1% 或 P99 超过 500ms 就自动中止并回滚，无需人工介入。

工具怎么选？

K8s 原生 Deployment 的滚动更新不是灰度发布，它只是逐个替换实例，无法控制流量比例；要做灰度必须配合 Service、Ingress 或服务网格。轻量场景用 Nginx + 注册中心权重就够了；已有 Istio/Linkerd 的团队直接用服务网格；想要声明式加自动分析，选 Argo Rollouts（K8s CRD 方式）或 Flagger。云厂商的 MSE、TSF 也提供现成能力，但要注意灰度规则是否支持按用户维度。

回到开头：蓝绿和灰度不是二选一。蓝绿给你一个随时能退回去的"安全底座"，灰度给你一个控制爆炸半径的"油门"。数据库兼容是这两件事共同的前置条件，做不到就别急着上。