一种前端灰度发布方案

前端大学

共 2140字,需浏览 5分钟

 ·

2020-01-07 23:25


(给前端大学加星标,提升前端技能.

作者:吕大豹 

https://www.cnblogs.com/lvdabao/p/11920919.html

本文介绍一种前端灰度发布方案,主要解决的是传统的灰度发布只能以机器维度进行分组的问题。提供一种用户维度分组的灰度发布机制。


传统灰度发布,因为是以机器分组,所以要求服务是无状态的。所谓无状态就是对请求的处理是上下文无关的。有长连接、读写文件、缓存等场景,就是所谓”有状态“的。有状态的服务,如果用户的前一个请求打在机器A,后一个请求打在机器B,就会出问题。


所以,有状态的服务灰度发布,要做到:


  1. 同一用户始终访问同一版本的代码

  2. 放量过程像传统发布一样可控


本灰度发布方案对构建、部署、启动服务、处理请求阶段分别做改造,实现有状态服务灰度发布。

方案概述

我们把线上的代码称为stable版,本次发布的新代码称为beta版。先整体描述一下方案:


  • 用git tag标识每次发布

  • 在构建阶段生成tag,同时用tag名称来命名manifest.json

  • 每次构建完新版本后,从cdn源机器取回上次发布的manifest.json文件,一并放在dist目录下

  • 部署阶段全量部署到所有机器,在运行阶段来决定访问哪个版本的代码

  • node层启动服务时,读dist目录下的两份manifest.json文件,这样就能拿到新旧两个版本的文件清单

  • 处理请求时,根据动态配置的放量信息和分流策略,来决定使用哪个manifest.json中的文件

  • 版本号信息放在cookie中,以保证同一用户始终访问同一版本代码

开发阶段

正常开发代码,无需有任何额外操作。

构建阶段

publish-tag


新增一个git tag,以p-开头,意为publish。每次发布都有一个tag标记,格式为p-201911111001-lvdabao.标记发布时间与发布者。构建完成并同步cdn成功后,会将该tag同步到git仓库。


manifest.json


manifest.json是webpack构建完毕后的文件清单,可以用webpack-manifest-plugin插件生成。如有特殊需求也可以自己编写。我们是自己编写,并在动态渲染首页HTML时读取清单内容并输出script标签。


每次构建生成的文件名称是这样的格式:manifest-p-201911111001-lvdabao.json,这样每次发布都生成对应tag命名的manifest.json文件。


启动服务时可以一次读取到内存中,并不是处理每个请求都读一下文件,所以不必担心性能。


获取上次发布的版本信息


我们是用publish-tag来标识版本号的,只要拿到上次发布时的tag,就能取到对应的manifest.json文件。所以构建的最后一步就是把上一版的manifest.json文件从cdn源机器取到当前构建后的dist目录下,为后续服务启动时使用。


取上次的tag也很简单,一个git命令搞定:git tag --sort=-taggerdate | grep "^p-.*" | head -n 1


容错机制


如果上次发布的版本有重大问题,不能作为stable版使用,有什么办法呢?

所以我们增加了一个额外流程,允许构建的时候传入环境变量,指定stable tag。这样在获取stable版本信息时,优先取环境变量中指定的。

部署阶段

部署跟普通流程没什么区别,将dist目录发布到目标机器就行了。每次部署的dist文件包含以下:


  • beta版的manifest.json文件

  • beta版的资源文件

  • stable版的manifest.json文件

启动服务

启动服务时我们需要干两件事情:


  1. 把两个manifest.json文件读到内存中,供分流时使用

  2. 自动修改放量配置,将新版本比例改为

放量配置

上面提到了放量配置,这个是放在单独的配置系统中的,当然简单点放在服务端也是可以的。用途就是根据当前用户的uuid,来确定用户该使用哪个版本的资源。


配置内容也及其简单:


{
    percent10
}


percent即是beta版的放量比例,10表示10%的用户使用beta版。全量的时候手动改为100就行啦。


因为启动服务的时候会自动将percent改为0,所以每次发布完后,我们只需根据放量节奏逐步扩大percent的值就好。


处理请求

万事具备,我们在处理请求的时候,就很easy了。只需获取当前用户的uuid,node层通过RPC调用获取到放量配置,通过分流策略来计算应该使用哪个版本的资源。


我们的首页是动态输出的(SSR),拿到分流策略得出的tag,把相应的manifest.json中的文件输出,这样就控制了哪部分用户使用beta版本。

分流策略

最后再谈谈分流策略,这块也是有很多细节的。分流策略要做的核心工作:


  1. 根据放量配置来决定当前用户应使用的资源版本

  2. 确保用户的分流路线稳定,即下次请求页面应与上次的分流结果一致

  3. 新版本发布或放量比例变化时,重新分流


首先,放量配置只有一个百分比数字,我们需要把uuid散列化,即把uuid字符串对应到0-99间固定的数字。算法可以有很多,我们选一种简单的,取每个字符的ASCII码相加,然后再除100取余。伪代码:


for (i = 0; i < uuid.length; i++) {
    hash += uuid.charCodeAt(i);
}


取到的这个hash就可以与放量百分比比较,在范围内就使用beta版。


另外一个比较麻烦的事情是第2点,为了让用户下次访问的时候能够跟首次的分流一致,我们需要把首次分流的结果保存在cookie中。当请求来的时候先分析cookie中的版本信息,如果可用则优先用cookie。不可用的话清掉cookie,再去计算分流。


那么既然uuid的散列算法能保证hash值稳定,每次都用uuid计算不行吗?原因就是我们访问环境的特殊,uuid的稳定性不能保证,相对来说还是cookie更稳定。这个看项目吧,如果你的项目uuid稳定,那可以省去用cookie。

总结

以上就是灰度发布方案的核心内容啦,相关的代码细节不赘述,有读者朋友感兴趣可以留言探讨。


通过这套方案我们实现了以用户维度进行分组的灰度发布,并且整个流程足够自动化,业务开发无感知,需要手动操作的只有修改放量配置。


有朋友可能想说,你这个方案和ABTest很相似啊!其实ABTest和本方案的差别主要有:


  1. 需要同时上线AB两套新代码

  2. 最终会丢弃其中一套代码


尽管看起来差别不大,但ABTest方案的构建、部署、分流控制都会有所区别。


当然,如果我们把ABTest退一步,认为stable版是A,新上线代码是B,那么将本方案改造成ABTest方案也很容易。


分享前端好文,缺个 在看 6b20a7f480d4aa2902509dce4dd4ff7a.webp

浏览 46
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报