本次查询：Canary Release
中文解释：金丝雀发布
常见场景：软件部署 / 云原生 / DevOps
一句话解释
金丝雀发布（Canary Release）是一种将新版本率先部署到一小部分用户或服务器上，观察运行状态和反馈，确认稳定后再逐步扩大部署范围，直至覆盖全量用户的发布策略。
为什么会被关注
在传统发布中，一次性全量上线新版本可能导致大规模故障，例如配置错误、性能退化或代码bug影响所有用户。金丝雀发布通过限制初始影响面，让团队在真实流量中提前发现问题，避免灾难性回滚，大幅降低发布风险。
随着微服务、容器化和持续交付的普及，团队需要更精细的控制手段。金丝雀发布配合监控、日志和告警系统，能快速验证功能正确性，同时支持逐步回滚，成为DevOps实践中的核心部署策略之一。
核心逻辑
核心思路是“小范围试错，大范围信任”。首先从集群中切出少量实例（如5%的流量）部署新版本，其余实例仍运行旧版本。通过对比两组实例的指标（错误率、延迟、资源消耗等），判断新版本是否健康。
若金丝雀组指标正常，逐步增加新版本实例比例（如10%、25%、50%），每次切换后观察一段时间。如果出现异常，立即将流量切回旧版本，仅影响少量用户。成功通过所有阶段后，新版本替换全部旧实例。
常见场景
大型互联网公司的新功能上线，如电商首页改版、推荐算法更新，通过金丝雀发布先让1%~5%的用户体验，收集用户体验数据和系统负载。
云原生环境中的服务版本迭代，例如Kubernetes集群中通过Istio或Nginx Ingress的流量权重调节，配合Prometheus监控实现自动化金丝雀发布。
移动App的后端API升级，通过网关层将部分请求路由到新版微服务，验证接口兼容性和性能表现，避免全量升级导致的客户端崩溃。
容易混淆的点
金丝雀发布常与灰度发布混用，实际上灰度发布是一个更宽泛的概念，金丝雀发布是其一种具体实现，通常强调逐步增加份额并持续监控。
与蓝绿部署不同，蓝绿部署维持两套独立环境（蓝和绿），直接切换全部流量，而金丝雀发布是渐进式切换，且新旧版本可能同时运行在同一集群中。
与A/B测试区分：A/B测试核心目的是比较两个版本的业务指标（如点击率），通常持续更久、样本分配固定；金丝雀发布主要是排查技术风险，验证稳定性后就会快速全量。