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



    此文已由作者申国骏授权网易云社区发布。

    欢迎访问网易云社区,了解更多网易技术产品运营经验。


    前言

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

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

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

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


    灰度流程


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

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

    • 首次访问的时候无 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 方案,针对不同的业务场景,还有有一定的作用,比如避免出现跨域请求等。

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

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


    免费体验云安全(易盾)内容安全、验证码等服务

    更多网易技术、产品、运营经验分享请点击


    相关文章:
    【推荐】 代码在线编译器(下)- 用户代码安全检测
    【推荐】 在Android中使用FlatBuffers(中篇)
    【推荐】 亲近用户—回归本质

  • 相关阅读:
    参考资料
    利用docker compose启动gitlab及runner
    在gitlab上setup CI
    git ssh端口号变更之后所需要的修改
    使用Docker Image跑Gitlab
    用Docker Compose启动Nginx和Web等多个镜像
    .NET core mvc on Docker
    ubuntu 挂载windows共享目录的方法
    13-14 元旦随想
    Uva 10177 (2/3/4)-D Sqr/Rects/Cubes/Boxes?
  • 原文地址:https://www.cnblogs.com/163yun/p/9990837.html
Copyright © 2020-2023  润新知