基于 cookie 的中间层灰度流程的一些思考

@zwwill 2018-10-26 03:32:34发表于 kaola-fed/blog 待归档

前言

关于灰度发布的意义此处就不进行介绍了,可以先读下这两篇文章

《微服务部署:蓝绿部署、滚动部署、灰度发布、金丝雀发布》

《灰度发布:灰度很简单,发布很复杂》

灰度方案说白了就是,分配一定比例或者筛选有特殊身份的用户,让这部分用户提前试用产品的最新版本,以便尽早发现问题也可将问题的影响最小化。不同公司都有自己独特的灰度流程,此处仅仅讨论灰度方案中的其中一个小环节,用户分配。

灰度流程

粗粒度灰度流程图

粗粒度灰度流程图(存在细节问题)

粗粒度的流程看上去似乎没有多大问题,但如果往细里考究,就会看到,漏洞百出

  • 首次访问的时候无 cookie 必然走 online 集群,但如果命中灰度,接下来的异步请求将被分流到 beta 集群,资源错乱
  • beta 集群下 cookie 过期后(浏览器自动清理),接下来的异步请求将会从新被灰度分配,如果未命中灰度,接下来的异步请求将被分流到 online 集群,资源错乱
  • 失效时间如果设置较短,则达不到灰度的目的

接下来,优化是必然的

几个大的问题

1、同步资源和异步资源的问题

描述:

同一个会话下,由于时机不同,导致同步资源和异步资源流入不同集群,此处假设 online 集群和 beta 集群资源不一致

场景:

1、同步 online 异步 beta:同步资源在无 cookie 条件下流入 online 集群,同步命中灰度设置了 cookie,之后的异步请求将会流入 beta 集群

2、同步 beta 异步 online:同步资源在有 cookie 条件下流入 beta 集群,随后 cookie 失效,之后的异步请求将会流入 online 集群


方案 a) node 中台灰度命中后重新代理回 ngnix 进行分流。 (1-,-2){1:有效,1-:部分有效,-1:无效,下同}

方案 b) beta 集群资源兼容 online 集群。 (1,-2)

方案 c) beta 集群独立域名(302),使用域名区分 online & beta。 (-1,2)

综合方案 b,c 可解决场景 1,2

2、灰度 cookie 过期或重置问题

描述:

会话期间更新 disconf 配置,或 cookie 自然过期会出现以下场景,导致资源请求错乱问题

场景:

3a、同步请求前设置灰度配置(online -> beta,同步资源同步)

3b、同步请求前关闭灰度配置(beta -> online,同步资源同步)

4a、同步(online)请求后异步请求前重置灰度配置(beta)

4b、同步(beta)请求后异步请求前重置灰度配置(online)

5a、下一个同步请求前重置灰度配置(online -> beta,同步资源不同步)

5b、下一个同步请求前重置灰度配置(beta -> online,同步资源不同步)


方案 a) 同上。(3a,3b,-4a,-4b,-5a,-5b)

方案 b) 同上。(3a,-3b,4a,-4b,5a,-5b)

方案 c) 同上。(-3a,3b,4a,4b,-5a,5b)

综合 b,c 可解决场景 3,4,5

3、灰度 cookie 的有效期时长问题

描述:

假设上方问题都已经解决,那么 cookie 的 maxAge 该设置成多少才比较合理?

  • 有效期较短,如 10s

问题:假设用户访问一个页面的时间大于10s,那么,此用户的异步请求将会在 online 和 beta 集群来回切换,虽然解决了资源错乱的问题,用户无感知,但 beta 集群受到的压力将会成倍增大。

同时,从目标用户分配的比例上来看,1天内机会所有的用户都会引流到 beta 集群,这样灰度将失去意义,且带来较大风险

  • 有效时间较长,如 1 天或更高

问题:过期时间设置较长,其优点恰恰是有效规避了有效期较短的致命缺点,beta 集群的流入用户比例和服务器压力都比较低。

但是,另外一个方面,如果 beta 集群出错宕机,或者我们主动将 beta 集群下线。就会导致灰度用户在 1 天内的反馈就是 404,且无解,只能等 cookie 过期或者用户主动换浏览器。导致的结果就是,客服电话被打爆,然后甩一句【垃圾网站!】,这是完全不能接受的。

  • 适中的有效期,如 10分钟到 1 小时

一般来讲,如果不是生产工具类的网站,用户一次的访问周期不会超过 1 小时,及时用户没有关闭网页的习惯,1 个小时候再次操作也不会对网站造成多大影响。

虽然说,宕机导致的 404 同样无解,但损失可以降到最小

总结

灰度细化流程图
灰度细化流程图

综合来看,方案 b,c 基本可以解决我们的上述问题。

beta 集群资源兼容 online 集群,静态资源长发布到 CDN,所以只需对异步资源进行同步即可。

集群独立域名(302),使用域名区分 online & beta,做域隔离,即使 cookie 失效也可以保证用户的当前会话操作维持在 beta 集群。

另外针对 a 方案,针对不同的业务场景,还有有一定的作用,比如避免出现跨域请求等。

问题是相对的,方案是灵活的。不同类型的系统会用不同的问题,我们能做的就只有针对问题思考解决方案。

如果你有更好的解决方案,还请不吝赐教!拜谢!


转载请标明出处

作者: 木羽 zwwill

首发地址:zwwill/blog#25