蓝绿部署与 DNS 切换

蓝绿部署会同时保留两套完整的生产环境：一套在线（“蓝”），一套闲置但已完整部署、随时待命（“绿”），然后在两者之间一次性快速切换流量，而不是滚动更新。实现这种切换的一种常见方式，尤其是跨独立基础设施或跨服务商时，就是修改 DNS：在确认绿环境健康之后，把域名的记录更新为指向绿环境的地址。

简单做法的不足之处

基于 DNS 的切换并不像切换负载均衡器的目标组那样瞬时生效。每个缓存了旧（蓝）应答的解析器，都会一直返回它，直到该记录的 TTL 过期。这意味着在与 TTL 成正比的一段时间内，仍有一部分流量落在您刚刚想要切走的环境上。如果 TTL 是一小时，那么在切换于各处全部完成之前，流量可能在两个环境之间分流长达一小时。

• 在计划切换之前，提前很久就调低 TTL，最好至少提前一个完整的旧 TTL 周期，这样到切换时，所有解析器都已按新的较短 TTL 重新缓存。
• 切换之后，旧（蓝）环境要在至少一个 TTL 窗口内保持完整运行且健康，不要立刻下线，因为在这段时间里它仍在接收真实流量。
• 直接查询 DNS 来验证切换，而不是只看应用日志，这样可以确认记录本身已经改变，与有多少流量已经跟上无关。
• 只有在确认切换已经完成且稳定之后，才把 TTL 调回正常值。

渐进式替代方案：加权 DNS

与其一次性把所有解析器都切过去，并寄希望于绿环境能立即扛住全部生产负载，不如使用多家 DNS 服务商支持的加权（或按百分比）路由策略：95% 的应答指向蓝环境，5% 指向绿环境，并随着对新环境信心的增强逐步调整比例，例如 80/20、50/50，依此类推。

它用一次干净利落的简单切换，换来了在问题只影响一小部分流量时就能发现的能力；而且如果绿环境尚未就绪，几秒钟内就能切回 100% 蓝环境，不必在压力之下去撤销一次完整的切换。

两种方式用同样的方法验证

无论采用哪种策略，验证步骤都是相同的：从多个观测点反复解析该域名，并确认实际观察到的分流比例与配置一致。一个本应把 10% 流量送往绿环境、实际却送去了 40% 的加权策略，可能是权重配置有误，也可能是部分解析器有缓存，不像预期那样频繁地重新抽取分流。这类偏差，只有检查真实的解析应答才能发现，而不能指望 DNS 服务商的仪表盘完美反映现实。