这是网上对灰度发布的解释。在我们的实际项目中,经常会有新版本的更新和迭代,如何把新版本和旧版本之间的变化,以一种平滑过渡的方式呈现给用户,这就是灰度发布的意义。
灰度发布的思路
在实际工作开发中,为了造成一次全量发布带来的未知风险,我们会使用灰度发布。具体方案如下
部分用户使用新版本:可以只让少部分用户使用新版本,剩余用户继续沿用老版本。根据新版本用户使用过程中提出的反馈意见,以及新版本使用的一些bug。做好及时修正问题,甚至修改产品的需求和设计方案,完善项目。经过反复的测试,修改,最终再上线新版本
新旧版本数据对比:新版本使用的数据量及用户体验情况,与老版本的数据对比,来决定是否有必要全量发布新版本。
总之,就是给部分用户上新版本,合适,就给全部用户上。不合适,赶紧回退。
灰度规则
可以根据用户的年龄,性别,所处地区,职业等来划分。在注册用户的时候,根据这些特征,来生成指定的id,之后灰度的时候,就能方便的划分体验新版本的用户了。
灰度发布的方案
1 服务端渲染分流
简单来说就是,前端需要提供新版本和旧版本两套代码,然后打包部署,存放到服务器上。用户访问服务器的时候,服务端根据用户信息与灰度规则,set-cookie并在redis存储,返回对应一套版本的index.html。用户再次访问服务端的时候,如果cookie存在且redis有对应版本信息,则直接返回对应的版本。
2 nginx + 服务端 + redis + 前端
这种方案需要前端主动请求灰度规则,比如用户通过点击一个按钮,来请求灰度规则接口。服务端判断用户是否在灰度规则里,然后set-cookie并在redis存储,并通过nginx重定向到指定的版本,返回给用户.如果用户已经存在灰度cookie,nginx可以根据cookie直接判断给用户返回哪个版本的服务。(新旧版本各自都要启动nginx服务,运维层启动了一层入口nginx服务)
3 前端条件判断
这种方案适合组件或者部分页面的灰度实现。如果是组件层面的,直接根据后端接口返回的标示,判断组件的显隐就可以。页面层面的话,可以增加一个入口文件,将两套页面分别当成组件,在入口文件根据标识判断显示哪套页面。还有就是使用高阶组件,根据标识,进行路由分发,来获取对应的页面。再者就是可以用动态的router文件,根据不同的情况,获取不同的router。