蓝绿部署与金丝雀发布的取舍

Kubernetes 默认的滚动更新是逐个替换旧实例为新实例，全程零停机，但流量切换是渐进又不可控的——同一时刻新旧版本混跑，出问题时很难精确判断是不是新版本引起的。蓝绿部署和金丝雀发布都是在这个基础上追加一层”更可控的流量切换”：蓝绿部署直接在旁边搭一套完整的新环境（绿），验证没问题后把全部流量一次性从旧环境（蓝）切过去，回滚只需要把流量切回蓝环境；金丝雀发布则是把流量逐步、小比例地从旧版本挪到新版本，先小范围验证效果，确认没问题再逐步扩大到全部用户。两者共同的好处是”回滚”变成了一个流量切换操作而不是重新部署旧版本，代价则是都需要同时维持两套（或两个比例的）生产环境，比单纯滚动更新更耗资源。发散：这本质是”先验证再切流量”和”边验证边切流量”两种风险控制粒度的取舍——蓝绿部署是粗粒度的开关式切换，金丝雀发布是细粒度的渐进式切换，后者能更早发现问题但控制逻辑更复杂。