权重调优比纯蓝绿切换更稳妥，因其避免“0→100”硬切带来的预热不足、状态不一致和验证滞后问题；通过渐进式流量接管（如10%→30%→50%…），结合可观测闭环与自动化响应，实现无感发布。
通过权重调优配合蓝绿部署实现无感业务发布，关键在于**不直接切换服务实例，而是用流量权重渐进接管**——既保留蓝绿的环境隔离优势，又规避“全量切流”带来的瞬时压力和验证盲区。
为什么权重调优比纯蓝绿切换更稳妥？
传统蓝绿是“0→100”式硬切换：旧环境权重归零、新环境权重拉满。这种方式虽回滚快，但存在两个风险：
- 新版本刚上线，连接池、缓存预热、JVM JIT 等未充分就绪，突增全量流量易引发超时或雪崩
- 部分边缘请求路径（如长连接、异步回调）可能仍落在旧节点，导致状态不一致
- 缺乏真实流量下的性能基线对比，问题暴露滞后
用权重实现平滑过渡的实操要点
核心思路：将“蓝绿”从环境级切换升级为流量级灰度，即让同一 Service 或路由规则同时指向蓝、绿两套后端，并通过动态权重控制比例。
- Consul + fabio 场景：在路由配置中为蓝、绿服务设置非0/100的初始权重（如 blue:90, green:10），验证稳定后逐步调整（90→70→50→30→0），每次调整后观察错误率、延迟、CPU等指标
- Kubernetes + Istio 场景：在 VirtualService 中定义两个 subset（blue/v1、green/v2），用 trafficPolicy 设置 weight，支持精确到1%的粒度；配合 DestinationRule 的负载均衡策略（如 ROUND_ROBIN 或 LEAST_CONN）提升分发合理性
- Nginx Ingress 场景：不依赖两个独立 Ingress，而是在单个 upstream 中配置多个 server，并用 weight 参数区分（如 server green-svc:8080 weight=10; server blue-svc:8080 weight=90;），配合健康检查自动剔除异常节点
权重调优必须配套的保障动作
仅调权重不够，需同步建立可观测闭环：
- 所有蓝、绿服务打统一 trace ID 和 version 标签，确保链路追踪能准确归属流量来源
- 在监控大盘中并列展示蓝/绿两组实例的 QPS、P99 延迟、5xx 错误率、GC 时间，设置同比/环比告警
- 对 green 环境开启慢日志、SQL 审计、JVM 内存快照等深度诊断能力，blue 环境保持轻量采集
- 当 green 权重升至 30% 后，触发自动化压测（如用 k6 对 /health、/api/user/profile 等核心接口发起 2 倍日常流量）
遇到异常时的快速响应逻辑
权重不是摆设，而是回滚开关：
- 若 green 权重升至 20% 后错误率跳升 >0.5%，立即执行权重回退（green:20 → green:5），而非等待全量切回
- 若 green 权重已达 50% 但 P99 延迟持续高于 blue 30%，暂停上调，先排查 green 实例的资源配额或依赖服务水位
- 所有权重变更操作必须记录 operator、时间戳、变更前/后值，并同步推送至值班群
