这是一个创建于 553 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题。前段时间参加面试，被问到前端如何实现灰度发布的方案。作为一个小作坊里的页面仔，脑海里一片空白，我只能说听过这些概念，什么 A/B 测试、渐进式发布、金丝雀发布，但寻思这些是大厂里才会有的部署流程吧。
今天心血来潮，搜了下灰度发布，有人说是和金丝雀发布一样的概念，有人又说不是。所以有几个问题想问：
1 、灰度发布和金丝雀发布分别是什么，它们究竟有什么区别联系；
2 、特性标志 Feature Flags 是什么，与灰度发布的关系；
3 、实现灰度发布是否需要大量配置，如 BFF 层、Nginx 、监控工具等；
4 、作为普通的开发者，该如何选择合适的发布策略
今天心血来潮，搜了下灰度发布，有人说是和金丝雀发布一样的概念，有人又说不是。所以有几个问题想问：
1 、灰度发布和金丝雀发布分别是什么，它们究竟有什么区别联系；
2 、特性标志 Feature Flags 是什么，与灰度发布的关系；
3 、实现灰度发布是否需要大量配置，如 BFF 层、Nginx 、监控工具等；
4 、作为普通的开发者，该如何选择合适的发布策略
 | 1 dobelee 2024-05-26 16:35:50 +08:00 via Android 灰度和金丝雀都是灰度发布，本质是同样的灰度测试。只是策略不同，这就很主观了，不做 qa 和效能的话没必要纠结。 |
 | 2 mark2025 2024-05-26 16:39:32 +08:00 我的理解： 1. 灰度发布是流量控制策略。比如某个灰度根据地域、用户、升级通道等等来决定流量是走正式还是灰度 2. 金丝雀是应用升级部署策略。升级部署新应用时检测应用响应状态（可以走自检测或者切一点线上流量），如果监测到异常（比如 500 ）就立即取消本次部署。 灰度发布可以采用金丝雀发布的方式来发布，也可以直接上线。 |
 | 3 hallDrawnel 2024-05-26 16:41:24 +08:00 他们都属于先尝试更新一部分负载看看表现，没问题再全量的操作，只是过程有区别而已。一般灰度发布都需要基础设施支持但是不需要大量配置，这些都是基础设施团队完成的事情，对于业务来说就是点几下的操作。 看你业务规模，灰度并不是必要的一环。在鹅厂很多业务也是直接全量上的。 |
 | 4 Spoken6035 2024-05-26 18:08:31 +08:00 via Android 现在前端这么卷了吗？灰度发布根本轮不到前端呀 |
 | 5 hesetiema OP @dobelee 灰度测试就是 A/B 测试吗，已经有个大体的认识了，感觉就是将不同功能映射到不同用户然后监控，推陈出新。 |
 | 7 tutu11 2024-05-26 18:23:11 +08:00 这种公司直接忽略，之前遇到过，就是初创团队，不知道招什么人，做的事情也不清晰 |
| 8 hesetiema OP @hallDrawnel 嗯嗯，小步试错、快速迭代，然后再根据反馈，自适应控制、模型预测控制。可惜小公司一般不会有这种基础设施团队，估计底层实现还是挺复杂的。业务规模不大好像确实不用太关注这些哈，我感觉我了解的皮毛已经够了，哈哈 |
 | 9 sunpj 2024-05-26 18:26:56 +08:00 作为后端来说 金丝雀发布是灰度发布的测量之一 灰度发布有多种 比如金丝雀跟蓝绿等 特征标志我理解是指定流量灰度测试 比如我现在后端发了 20% 然后需要在 header 或者哪里加标志位 全链路才能访问到我指定的那 20%机器 监控肯定是必须的 灰度的前提是可观测 安全生产三板斧 可灰度 可观测 可回滚 我经历过的大厂一般都是金丝雀 |
| 10 hesetiema OP @sunpj 学习了。我看国外很多相关的问题，都是比较的金丝雀和蓝绿部署，没提到灰度的概念，可能国内通常统一说灰度。特性标志我看还有一些第三方的库或工具，比如 ConfigCat ，提供前后端 SDK 加上各种配置管理感觉很灵活的样子，不知道这种工具大厂是不是也都是自研的。监控好像还有一些什么 Prometheus 、Grafana 工具，真心感觉 学习 DevOps 的话需要懂的东西好多... |
| 11 hesetiema OP  1 @Spoken6035 可能那个公司业务规模上来了，需要这样的基础建设吧，抑或是想让我知难而退。无所谓，涨知识就对了，哈哈。 |
| 13 tutu11 2024-05-26 20:17:37 +08:00 @hesetiema 主要是让前端 hold 就很离谱，而且前端能做的很有限，他们应该在招聘的 JD 上就写清楚需要运维相关技术栈，这种是很坑的，专门问一些和岗位没关系的问题或者不给出真实的需求，而且这种问题一般可以用来搪塞面试者，不给你过也是很好的理由 |
 | 14 bthulu 2024-05-27 10:35:13 +08:00 我司用的国产古方金丝楠木发布 |
 | 15 dododada 2024-05-27 11:07:07 +08:00 这个灰度系统和 AB 系统要根据公司的具体业务做开发的。 以前公司的灰度就是用来小批量功能验证，不上量。 灰度没问题之后开始 AB ，分为实验组和对照组，按渠道、地域、人群、或者其他不同维度慢慢放量，运行一周之后进行数据回归分析，如果 AB 测试的效果满足预期或者对留存转化有提升，就进入下一步，不同渠道滚动升级；如果 AB 效果不佳，就版本回退，继续新的开发测试流程 |
 | 16 hellojl 2024-05-27 14:13:21 +08:00 需要解决的问题都是如何小批量的验证新功能。 灰度部署和金丝雀部署通常存在新旧或者 A/B 版本，通过逐渐放量到新版本上，验证上线、新功能是否 OK ，需要基础设施的支持。而在部署两个版本的情况下，通常对基础设施要求会更高一些，比如如何实现上述的按比例 CD 的功能。另外一个隐藏的问题是，对于流量的控制不在程序本身，一个请求访问新 or 旧版本，需要由上游的调用方确定，实际中上游可能是 Nginx 、网关或者另一个服务，需要适配的会比较多一些，对于一些请求链路比较长的服务不是很友好。 后续有一些公司尝试了名为 Dark Launching 的方案，也就是 Feature Flag 功能开关。好处是可以在一个服务内实现更细粒度的请求控制，对于上下游调用、CI/CD 也很友好，因为对于外部来看这个服务只存在一个版本，实际新旧是由服务内部类似 if/else 的逻辑控制的。缺点就是对代码有入侵，功能正式上线后可能还需要去掉 Feature Flag 相关的代码，虽然一些主流的库不去掉也机会没有性能影响。 个人使用体验来看，更倾向功能开关的方案。虽然功能开关的方案对代码有入侵，增加代码复杂度，但是整体上看增加的内容不多，而且在代码层都能控制。无论是灰度发布还是金丝雀发布，在基础设施层引入了更多的配置，实际上会增加出问题的可能性。 面试问这个没什么问题，只要涉及到新功能上线、小批量验证的需求，其实都需要考虑类似的问题，不区分前后端。 |
Select Language