devops 什么是灰度发布,以及灰度发布 A/B 测试

流川凤 · 2018年08月22日 · 最后由 红客联盟 回复于 2022年04月11日 · 3820 次阅读

在一般情况下,升级服务器端应用,需要将应用源码或程序包上传到服务器,然后停止掉老版本服务,再启动新版本。但是这种简单的发布方式存在两个问题,一方面,在新版本升级过程中,服务是暂时中断的,另一方面,如果新版本有 BUG,升级失败,回滚起来也非常麻烦,容易造成更长时间的服务不可用。

为了解决这些问题,人们研究出了多种发布策略,下面我们一一介绍。

蓝绿部署

所谓蓝绿部署,是指同时运行两个版本的应用,如上图所示,蓝绿部署的时候,并不停止掉老版本,而是直接部署一套新版本,等新版本运行起来后,再将流量切换到新版本上。但是蓝绿部署要求在升级过程中,同时运行两套程序,对硬件的要求就是日常所需的二倍,比如日常运行时,需要 10 台服务器支撑业务,那么使用蓝绿部署,你就需要购置二十台服务器。

滚动发布

滚动发布能够解决掉蓝绿部署时对硬件要求增倍的问题。

所谓滚动升级,就是在升级过程中,并不一下子启动所有新版本,是先启动一台新版本,再停止一台老版本,然后再启动一台新版本,再停止一台老版本,直到升级完成,这样的话,如果日常需要 10 台服务器,那么升级过程中也就只需要 11 台就行了。

但是滚动升级有一个问题,在开始滚动升级后,流量会直接流向已经启动起来的新版本,但是这个时候,新版本是不一定可用的,比如需要进一步的测试才能确认。那么在滚动升级期间,整个系统就处于非常不稳定的状态,如果发现了问题,也比较难以确定是新版本还是老版本造成的问题。

为了解决这个问题,我们需要为滚动升级实现流量控制能力。

灰度发布

灰度发布也叫金丝雀发布,起源是,矿井工人发现,金丝雀对瓦斯气体很敏感,矿工会在下井之前,先放一只金丝雀到井中,如果金丝雀不叫了,就代表瓦斯浓度高。

在灰度发布开始后,先启动一个新版本应用,但是并不直接将流量切过来,而是测试人员对新版本进行线上测试,启动的这个新版本应用,就是我们的金丝雀。如果没有问题,那么可以将少量的用户流量导入到新版本上,然后再对新版本做运行状态观察,收集各种运行时数据,如果此时对新旧版本做各种数据对比,就是所谓的 A/B 测试。

当确认新版本运行良好后,再逐步将更多的流量导入到新版本上,在此期间,还可以不断地调整新旧两个版本的运行的服务器副本数量,以使得新版本能够承受越来越大的流量压力。直到将 100% 的流量都切换到新版本上,最后关闭剩下的老版本服务,完成灰度发布。

如果在灰度发布过程中(灰度期)发现了新版本有问题,就应该立即将流量切回老版本上,这样,就会将负面影响控制在最小范围内。

使用脉冲云轻松地实现灰度发布 -查看视频

脉冲云的部署管理可以轻松实现上述的带有流量管理功能的灰度发布。正常编辑应用信息后点击保存,然后脉冲云会提示直接升级或灰度发布。

直接升级就是使用一般的滚动升级,点击灰度发布后可以人工干预升级过程,进行流量控制。

选择灰度发布后,就会呈现灰度发布控制面板。

在这个控制面板上,可以拖拉滑块,快速调整新旧版本的运行副本数量,同时也可以按百分比,将流量导入到新版本上。此外,还可以通过匹配 HTTP Header,指定个别用户的流量到新版本上。

除了匹配用户流量的 HTTP 请求头,还可以直接指定匹配请求头中的 Cookie 信息,匹配规则支持精确匹配、包含、正则、前缀、后缀等,甚至还允许反向匹配。

当确认新版本运行无误后,就可以点击 完成升级 按钮,就会将流量全部切换到新版本上,并且销毁掉所有老版本应用。如果新版本出了问题,可以点击 取消升级 按钮,立即将流量切回老版本,并销毁掉新版本应用。

总结

在新版本应用发布时,为了服务器不停机升级,使用灰度发布策略,在灰度发布开始时,使用 HTTP Header 匹配指定测试人员的流量到新版本上,然后当新版本内部测试通过后,可以再按百分比,将用户流量一点一点导入到新版本中,比如先导入 10% 观察一下运行情况,然后再导入 20%,如此累加,直到将流量全部导入到新版本上,最后完成升级,如果期间发现问题,就立即取消升级,将流量切回到老版本。

运用灰度发布,就再也不需要加班到深夜进行停机升级了,在白天就可以放心大胆地、安全地发布新版本。

点击右侧查看视频:5 分钟学会灰度发布

共收到 5 条回复 时间 点赞

厉害!纯干货啊

有个问题,很好奇,在灰度发布时,怎么精准的分流。
具体点,V1 和 V2 对应的数据库结构不一样,用户 A 被负载均衡切换到 V2 时,进行了刷库操作,那么以后怎么能保证用户 A 一直访问的是 V2?
问这个问题的背景,我们团队现在的做法,不是在负载均衡那层做分流,而是新起一个鉴权服务,存储一份灰度名单,该名单相对固定,鉴权服务发现 A 用户是在灰度名单中,则让 A 访问 V2.
总感觉我们现在的做法不是真正意义上的灰度发布,求各大大佬给点意见,希望知道大厂是怎么做的,请指教。

Kevin Gu 回复

个人认为灰度发布的灰度期应该是有限的,毕竟发布是为了发布成功。你这种情况应该需要鉴权服务长期运行进行长期分流,而且很有可能你的 V1 和 V2 仍然需要各自独立升级,并不一定从 V1 升级到 V2,或者短期内不会。

Alex96321 回复

谢谢,希望有所帮助!

有个问题,有了灰度以后,对全量发布测试回归帮助有多大,包括时间节约等,灰度环境是全量环境的子集,应该可以避免大部分问题?

需要 登录 後方可回應,如果你還沒有帳號按這裡 注册