蓝绿部署本质是“非0即100”的全量切换，不天然支持权重调节；但可通过流量网关叠加权重机制，在保持环境隔离与秒级回滚能力基础上，实现5%→30%→100%的渐进式验证，以暴露偶发性故障并降低全量切换风险。
蓝绿部署本身是“非0即100”的全量切换，不天然支持权重调节；但若想用权重调优来增强蓝绿的可控性，实际是将蓝绿与灰度能力融合——不是改变蓝绿本质，而是借助流量网关的权重能力，在蓝绿框架内实现分阶段验证。关键在于：蓝绿提供环境隔离与秒级回滚能力，权重调优提供渐进式观察窗口。
为什么蓝绿需要叠加权重机制
纯蓝绿虽能秒切、秒回，但一次性切全量流量仍存在风险盲区：比如偶发性超时、特定用户链路异常、数据库慢查询在高并发下才暴露。权重调优（如从5%→30%→100%）相当于给新版本加一道“压力探针”，让真实流量按比例流经绿环境，在低影响面下完成生产级验证。
主流平台的权重接入方式
无需修改应用代码，全部通过基础设施层实现：
- 云厂商 ALB/NLB（如 AWS ECS 场景）：将蓝、绿服务分别注册到两个独立目标组，通过监听器规则配置权重路由。例如设置蓝目标组权重95、绿目标组权重5，API 调用或控制台操作即可动态调整，生效时间＜1秒。
- Kubernetes Ingress（如 Nginx Ingress Controller）：使用 annotation 开启 canary 功能，例如 nginx.ingress.kubernetes.io/canary: "true"，再配合 nginx.ingress.kubernetes.io/canary-weight: "5" 控制流量比例。注意需确保蓝/绿 Deployment 使用不同标签，且 Service 后端分别指向各自 Pod。
- 自建 Nginx + Lua（OpenResty）：在 upstream 模块中定义蓝、绿两组 server，通过 set_by_lua_block 根据 Header、Cookie 或请求路径动态计算权重并 proxy_pass 到对应 upstream，灵活性高但需自行维护逻辑。
权重调优的关键执行节奏
不是机械递增，而是结合可观测信号做决策：
- 初始切5%：只放行非核心路径（如静态页、查询类接口），跳过支付、下单等关键链路；观察 5 分钟内绿环境 5xx 错误率是否
- 升至30%：放开全部读接口，保持写操作仍走蓝环境（通过网关路由规则拦截 POST/PUT 请求）；重点看日志中是否有新版本特有的 warn 级关键词（如 “v2.1-cache-miss”）。
- 切至100%前：确认数据库连接池无泄漏、第三方 SDK 调用成功率达标、Prometheus 中绿环境 JVM GC 频次未突增；此时再执行最终切换，而非仅凭时间推算。
必须同步完善的配套机制
权重只是“怎么切”，背后依赖三根支柱才能真正无感知：
- 健康检查必须真实有效：不能只 ping /healthz，要包含业务就绪检查（如连通下游 Redis 并写入测试 key，再读出校验）；ECS 任务定义或 K8s readinessProbe 中需嵌入此类逻辑。
- 数据库变更严格向前兼容：绿环境上线前，所有 DDL 必须是“只增不删、字段可空、默认值兼容”，避免蓝环境旧代码因读取新字段而 panic。
- 配置与静态资源分离管理：Nginx 配置、网关路由规则、Feature Flag 开关全部 Git 化；前端 JS/CSS 加哈希后缀，避免浏览器缓存旧资源导致蓝绿混用。
