什么是灰度发布?
灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式,让一部分用户继续用A,一部分用户开始用B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。
haproxy是什么?
HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代 理,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。HAProxy运行在当前的硬件上,完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中, 同时可以保护你的web服务器不被暴露到网络上。 HAProxy实现了一种事件驱动, 单一进程模型,此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制,很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务,所以没有这些问题。此模型的弊端是,在多核系统上,这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。
OK,上业务场景。
其实就是类似AB/TEST的做法,通过算法将一部分流量(或人)导入后端指定的几台机器上面。这个的难点在于:
如何保证用户一旦进入新版本后不会再跳回老版本?
如何控制流量和后端指定app数量之间的比率?
我的做法:首先确认了不能让haproxy种cookie,至于为什么可以参考我在stackoverflow的帖子。点我
核心代码我贴下,下面这段配置是放在frontend下:
acl cookie_gray_new hdr_reg(cookie) -i ha_gray_cookie=(1|2|3|4|5)(.*?) acl cookie_gray_old hdr_reg(cookie) -i ha_gray_cookie=(6|7|8|9|0)(.*?) use_backend app_1 if cookie_gray_new use_backend app_2 if cookie_gray_old
我实际的代码是把流量分成了10等分(cookie按照0-9随机分发),按10%一档来渐变的。后端根据不同的机器数量进行百分比的切换。如 后端10台机器,如果30%的灰度。前端将30%的流量切到后端机器总数的30%上面。即cookie为0-2的跳转到后端为新版本的三台机器上。这样就能保证灰度发布过程中不至于出现前端大部分的流量集中访问到后端较少的机器上的极端情况。
第二次如果需要调整流量的话,只需修改cookie值0-9之间的值即可。
解决掉这个问题之后,剩下的就是如何去按照灰度发布的要求去算出配置文件是怎么样的了,苦逼无技术含量的活,大致的思路是将haproxy特定的位置打上标记,通过代码算出前端流量和后端机器的数量,然后自动生成配置文件,验证后reload即可。