灰度发布 vs 金丝雀发布，什么是合适的发布策略？

[hesetiema]

如题。前段时间参加面试，被问到前端如何实现灰度发布的方案。作为一个小作坊里的页面仔，脑海里一片空白，我只能说听过这些概念，什么 A/B 测试、渐进式发布、金丝雀发布，但寻思这些是大厂里才会有的部署流程吧。
今天心血来潮，搜了下灰度发布，有人说是和金丝雀发布一样的概念，有人又说不是。所以有几个问题想问：
1 、灰度发布和金丝雀发布分别是什么，它们究竟有什么区别联系；
2 、特性标志 Feature Flags 是什么，与灰度发布的关系；
3 、实现灰度发布是否需要大量配置，如 BFF 层、Nginx 、监控工具等；
4 、作为普通的开发者，该如何选择合适的发布策略

[dobelee]

灰度和金丝雀都是灰度发布，本质是同样的灰度测试。只是策略不同，这就很主观了，不做 qa 和效能的话没必要纠结。

[mark2025]

我的理解：
1. 灰度发布是流量控制策略。比如某个灰度根据地域、用户、升级通道等等来决定流量是走正式还是灰度
2. 金丝雀是应用升级部署策略。升级部署新应用时检测应用响应状态（可以走自检测或者切一点线上流量），如果监测到异常（比如 500 ）就立即取消本次部署。

灰度发布可以采用金丝雀发布的方式来发布，也可以直接上线。

[hallDrawnel]

他们都属于先尝试更新一部分负载看看表现，没问题再全量的操作，只是过程有区别而已。一般灰度发布都需要基础设施支持但是不需要大量配置，这些都是基础设施团队完成的事情，对于业务来说就是点几下的操作。
看你业务规模，灰度并不是必要的一环。在鹅厂很多业务也是直接全量上的。

[Spoken6035]

现在前端这么卷了吗？灰度发布根本轮不到前端呀

[hesetiema]

@dobelee 灰度测试就是 A/B 测试吗，已经有个大体的认识了，感觉就是将不同功能映射到不同用户然后监控，推陈出新。

[hesetiema]

@mark2025 嗯嗯，确实感觉灰度的理念好像更广义一点。

[tutu11]

这种公司直接忽略，之前遇到过，就是初创团队，不知道招什么人，做的事情也不清晰

[hesetiema]

@hallDrawnel 嗯嗯，小步试错、快速迭代，然后再根据反馈，自适应控制、模型预测控制。可惜小公司一般不会有这种基础设施团队，估计底层实现还是挺复杂的。业务规模不大好像确实不用太关注这些哈，我感觉我了解的皮毛已经够了，哈哈

[sunpj]

作为后端来说 金丝雀发布是灰度发布的测量之一 灰度发布有多种 比如金丝雀跟蓝绿等
特征标志我理解是指定流量灰度测试 比如我现在后端发了 20% 然后需要在 header 或者哪里加标志位 全链路才能访问到我指定的那 20%机器
监控肯定是必须的 灰度的前提是可观测 安全生产三板斧 可灰度 可观测 可回滚
我经历过的大厂一般都是金丝雀

[hesetiema]

@sunpj 学习了。我看国外很多相关的问题，都是比较的金丝雀和蓝绿部署，没提到灰度的概念，可能国内通常统一说灰度。特性标志我看还有一些第三方的库或工具，比如 ConfigCat ，提供前后端 SDK 加上各种配置管理感觉很灵活的样子，不知道这种工具大厂是不是也都是自研的。监控好像还有一些什么 Prometheus 、Grafana 工具，真心感觉 学习 DevOps 的话需要懂的东西好多...

[hesetiema]

@Spoken6035 可能那个公司业务规模上来了，需要这样的基础建设吧，抑或是想让我知难而退。无所谓，涨知识就对了，哈哈。

[hesetiema]

@tutu11 那个公司发展其实挺不错的，可惜自己太菜...

[tutu11]

@hesetiema 主要是让前端 hold 就很离谱，而且前端能做的很有限，他们应该在招聘的 JD 上就写清楚需要运维相关技术栈，这种是很坑的，专门问一些和岗位没关系的问题或者不给出真实的需求，而且这种问题一般可以用来搪塞面试者，不给你过也是很好的理由

[bthulu]

我司用的国产古方金丝楠木发布

[dododada]

这个灰度系统和 AB 系统要根据公司的具体业务做开发的。

以前公司的灰度就是用来小批量功能验证，不上量。

灰度没问题之后开始 AB ，分为实验组和对照组，按渠道、地域、人群、或者其他不同维度慢慢放量，运行一周之后进行数据回归分析，如果 AB 测试的效果满足预期或者对留存转化有提升，就进入下一步，不同渠道滚动升级；如果 AB 效果不佳，就版本回退，继续新的开发测试流程

[hellojl]

需要解决的问题都是如何小批量的验证新功能。

灰度部署和金丝雀部署通常存在新旧或者 A/B 版本，通过逐渐放量到新版本上，验证上线、新功能是否 OK ，需要基础设施的支持。而在部署两个版本的情况下，通常对基础设施要求会更高一些，比如如何实现上述的按比例 CD 的功能。另外一个隐藏的问题是，对于流量的控制不在程序本身，一个请求访问新 or 旧版本，需要由上游的调用方确定，实际中上游可能是 Nginx 、网关或者另一个服务，需要适配的会比较多一些，对于一些请求链路比较长的服务不是很友好。

后续有一些公司尝试了名为 Dark Launching 的方案，也就是 Feature Flag 功能开关。好处是可以在一个服务内实现更细粒度的请求控制，对于上下游调用、CI/CD 也很友好，因为对于外部来看这个服务只存在一个版本，实际新旧是由服务内部类似 if/else 的逻辑控制的。缺点就是对代码有入侵，功能正式上线后可能还需要去掉 Feature Flag 相关的代码，虽然一些主流的库不去掉也机会没有性能影响。

个人使用体验来看，更倾向功能开关的方案。虽然功能开关的方案对代码有入侵，增加代码复杂度，但是整体上看增加的内容不多，而且在代码层都能控制。无论是灰度发布还是金丝雀发布，在基础设施层引入了更多的配置，实际上会增加出问题的可能性。

面试问这个没什么问题，只要涉及到新功能上线、小批量验证的需求，其实都需要考虑类似的问题，不区分前后端。

[hesetiema]

@hellojl 受教了。第一次听说 Dark Launching ，可能对于用户来说就是无感知。功能开关是不是是最近才流行起来的技术呀，感觉灵活性挺高的。面试还是挺难的，哎，失业了两个多月，成都太卷了...

[hellojl]

@hesetiema 我最早是在 17 年接触的功能开关的概念，但是国内用的确实不多，大部分还停留在灰度发布的阶段。今年面试确实难，我也挂好几家了，共勉吧......