我开源了一个 A/B 实验、功能发布管理平台项目

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 656 天前的主题，其中的信息可能已经有所发展或是发生改变。

A/B 实验、以功能粒度发布的管理平台

主要使用场景如下：

1. 『功能粒度』灰度发布: 每个功能独立灰度发布给用户。可迅速关闭受 BUG 影响的功能，同时不影响其他正常功能的使用。

2. 降低测试环境搭建成本: 节约测试环境搭建和线下测试时间成本。利用线上环境小流量测试，环境真实同时影响可控。

3. 降低故障恢复时间:故障发生时通过降级策略调整服务行为，保障用户主路径不受影响。

4. 简化研发协同方式: 用功能开关替代传统分支开发的团队协同模式。真正实现主干开发、持续部署。减少分支合并冲突，显著加快迭代速度。

5. 统一的配置管理中心: 通过用户友好的操作页面，统一操作线上配置，实时修改功能参数，让运营活动生效更简单。

GitHub 地址： https://github.com/FeatureProbe/FeatureProbe

文档地址： http://docs.featureprobe.io

体验环境地址： https://featureprobe.io/

欢迎 star 和提 issue/pr,如果能得到大家小小的鼓励和认可，是我的荣幸!

功能

粒度

灰度

测试

37 条回复 • 2024-11-20 10:01:47 +08:00

ryan4yin

2023-02-17 10:14:01 +08:00

看着不错，企业会比较需要这种

FeatureProbe

2023-02-17 11:54:52 +08:00

@ryan4yin 欢迎使用，如有任何建议或问题的话，可以提 issue/pr ，也可以找我哦。

gangbinfo123

2023-02-17 11:56:04 +08:00

感觉发现了新大陆，使用一段时间，上线风险降低好多啊

shibo501c

2023-02-17 11:58:01 +08:00 via Android

紧急情况关闭一些功能还挺好用，配置系统还是太偏向研发人员了，这种平台其他角色也可以用，国外还有 launchdarkly, growthbook 什么的，国内少一点

millken

2023-02-17 12:38:27 +08:00

带侵入的方案企业一般不敢用，A/B testing 大多数 gateway 已经支持了，当然你这个属于定制行非常强，在非常熟悉 SDK 的情况下且有复杂场景需求的可以考虑使用。

shibo501c

2023-02-17 17:41:18 +08:00

@millken 是的，后端其实方案比较多，主要还是移动端要发版，上应用商店，能够快速关闭个功能，还是挺有用的

gohaian

2023-02-24 11:47:45 +08:00

体验了，非常不错，期待开源更多功能。

lessMonologue

2023-03-01 17:23:49 +08:00

DIDI 的 apollo ？

FeatureProbe

2023-03-01 17:24:41 +08:00

@gohaian 这周上线了指标分析功能，欢迎使用，有任何问题和建议欢迎提 issue

zhaoyta

2023-03-01 17:39:37 +08:00

携程的 apollo ？

dnsjia

2023-03-01 18:17:21 +08:00

https://github.com/dnsjia/luban

FeatureProbe

2023-03-02 10:22:37 +08:00

@zhaoyta 携程的 apollo 是配置中心，FeatureProbe 主要是功能粒度去管理和发布功能，之前写了一篇文章讲了二者的区别，有兴趣可以看一下 https://juejin.cn/post/7187598169730416701

FeatureProbe

2023-03-02 10:33:21 +08:00

@lessMonologue 欢迎使用

shibo501c

2023-03-02 11:34:46 +08:00

@lessMonologue 难道是老橘子

OpenSea

2023-03-02 13:54:53 +08:00

呀，在 V 站看到了，之前提了不少 issue

opentrade

2023-03-02 13:55:28 +08:00

有米置顶

99yuying

2023-03-02 14:19:32 +08:00

文档写的很全面👍

kingterrors

2023-03-02 14:41:16 +08:00

看起来就很厉害，向大佬学习！

jiangzm

2023-03-02 14:47:17 +08:00

跟 DIDI 有个开源项目很像，另外字体是不是有点小感觉不太协调。

jiangzm

2023-03-02 15:00:13 +08:00

@zhaoyta
@lessMonologue
@FeatureProbe
对的配置中心一般给开发人员用的，A/B 实验一般是产品基于用户画像来实验新功能的。

daguozi

2023-03-02 15:33:53 +08:00 via iPhone

小白看了非常感兴趣，想请教楼主对于 AB 测试如何做的 randomization? 在有 gradularity 时，如何确定用户 A 在 10%的 roll out 呢？每次 rollout 时，A 永远在 10%还是每次都不一样呢？

shibo501c

2023-03-02 16:16:54 +08:00

@daguozi 好像比较常见的做法是不同的 AB 实验，用不同的 salt 进行 hash ，也有提前分不同的 zone 的。10% 的 roll out 也分稳定的还是不稳定的，只要用户有唯一的 key ，hash 出来就可以是稳定的。

daguozi

2023-03-02 16:53:32 +08:00

@shibo501c 谢谢解释！我比较感兴趣的是如果 10% rollout 然后 roll back 10%，再 rollout 10% 以后是否是稳定的。还没有仔细看 doc ，也许我说的是错的，但感觉看起来 hash 是根据 project 的 unique identifier 进行 salt 的？那只要是一个 project 下的 rollout ，就是稳定的。但如果 new 了一个 project ，那新的 project 下的 10%可能应该就是 reshuffle 了

jiangzm

2023-03-02 17:09:41 +08:00

@daguozi 是的，灰度流量不能总是让同一批人当小白鼠。用 user_id 加上 exp_no hash 算出流量区间，或者基于 session_id 来计算，这样能保证实验的独立性。

shibo501c

2023-03-02 17:18:18 +08:00

@daguozi 是的，所以如果是想让全新用户进组的话，有很多办法，比如可以让业务代码上记录下属性，FeatureProbe 目前支持用户代码传入一个 user 的属性，初始化时候，传入用户时候看过上一个版本，在 toggle 的规则中排除掉，比如过滤掉 user["feature_v1_viewed"] == true 的用户。

daguozi

2023-03-02 18:06:07 +08:00

@shibo501c @jiangzm 啊是这个是个好方法哈哈！有意思，感觉应该是灰度到了每个 variant 了。感觉是 project 下有 concurrent toggles ，然后每个 toggle map 100% user base 。突然有这么个问题。。。如果有其中 toggle 里 1 ，2 ，3 三个 enum flag rollout 。rollout 20% 1 ，40% 2 ，40% 3. 那么 stable 情况下，第二次 rollout 30% 1 ，30% 2 ，40% 3. 那么这次 1 多出来的 10% 是从 2 拿的呢还是说 2 + 3 里拿的。。。想请教这里的顺序问题。。。

shibo501c

2023-03-02 18:38:42 +08:00

@daguozi 好问题，目前我们开源的版本是会出现 2 和 3 组都会有一部分用户进入组 1 ，是有方案做到只从 2 组拿用户出来的，但是实现要复杂一些。

比如目前是分 100 个桶，第一次按照流量分前 20 是组 1 ，中间 40 是组 2 ，最后 40 是组 3 ，调整后，找减少最多的组中多余桶，再进行 hash 分给增加的组，直到桶分完。

shibo501c

2023-03-02 19:15:18 +08:00

补充下，因为 3 组 40%没变，所以目前的一层 hash 实现只会从 2 组挪动 10%到 1 组。
如果是变成 30%，40%，30%，则会让组 2 的一部分去组 1 ，组 3 一部分去组 2 。
两层 hash 的话，可以只让 3 组的进入组 1 ，组 2 不动。

daguozi

2023-03-02 19:22:26 +08:00

@shibo501c 谢谢作者的解释，明白了，看来这种 edge case 应该不是 best practice 的 use case 。感觉 binary 的 flag rollout 就没有问题哈。