持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第3天，点击查看活动详情
前言
这是网上对灰度发布的解释。在我们的实际项目中，经常会有新版本的更新和迭代，如何把新版本和旧版本之间的变化，以一种平滑过渡的方式呈现给用户，这就是灰度发布的意义。
灰度发布的思路
在实际工作开发中，为了造成一次全量发布带来的未知风险，我们会使用灰度发布。具体方案如下
部分用户使用新版本：可以只让少部分用户使用新版本，剩余用户继续沿用老版本。根据新版本用户使用过程中提出的反馈意见，以及新版本使用的一些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。
