前端灰度发布是什么

某个已上线处于运行中的系统需要一次新的功能迭代，但是由于功能变动较大，所以发布需要考虑用户的使用反馈以及代码可能存在一些未知的异常，这时候则需要将新的功能逐步地一批一批的推送给用户。
在这个逐步放量的过程中，可以根据用户接受度（用户投诉多不多）和观察本次功能是否存在上线前未发现的异常，来决定是否继续发布推送新功能，如果新功能反馈较差或者存在功能异常问题，则停止放量或者回滚到之前稳定的版本，及时修改问题。
这样便避免一次推送情况下，如果出现问题则造成线上问题突然上升造成阻塞用户使用的问题。
灰度发布的优点：
1.提前收集用户使用意见，及时完善产品功能
2.控制未知异常只出现在小范围内，不影响大多数用户
3.发现产品是否存在外在问题（如合规），可及时回滚至已旧版本
前端灰度发布的几种方式？
1、对于服务端渲染的应用：用户首先发起请求后，服务器并不会直接组装静态资源，而是先去灰度规则里获取名单，然后将灰度名单拿到进行判断处理来决定渲染那一套模板资源给到客户端，最终给处于灰度名单里的用户展示新版本页面，而非名单内的用户继续使用旧版本的页面内容，如需要放量时，直接在灰度规则里进行修改即可
2、前后端办分离，是指在有一部分前端应用的html文件依旧在服务端上，但是实际上却在客户端渲染的；因为两次迭代需求，前端开发者将前端资源打包成了两个资源包，分别上传到CDN的不同位置处，以版本号作为标识来确定新旧内容。
当用户的请求被接收到后，先通过getRule获取灰度规则来确定给当前用户展示哪一个版本号的资源，然后返回带着资源版本的模板内容，客户端接收到该模板之后，再加载对应的版本号资源，从而达到灰度要求。
3、客户端渲染，前端开发完成后，直接打包至CDN上，然后利用nginx来请求到静态资源，这时候CDN服务器并不会去做灰度判断相关的操作；在页面渲染之前发起异步获取灰度规则的请求，将结果拿到后在客户端决定渲染那一套页面，从而达到灰度的要求。