nodejs 的灰度发布

不知道灰度发布具体指的是什么意思。

如果指的是整体服务的版本发布，可以让新版做好旧版的兼容，然后多实例一个一个的升级。
如果指的是热加载一些 js 文件可以动态 require，但对打包工具不友好。

@libook 谢谢大佬。主要目的就是 类似 ABTest 那样，先分配小流量用户体验新功能，如果反馈比较好，就会全量发布的。就是不明白 nuxt 如何根据流量占比来使用户走不同的 version，会有那种多版本共存的概念。

@121819756 #2
灰度发布和 ABTest 有时候需求会有些区别。

你们应该是分布式方案吧，如果是分布式无状态方案的话（如 REST API ），ABTest 通常需要确保一个用户不会被重复分配 AB 组，需要用户户第一次访问的时候分配 A 组或 B 组，然后用户每一次访问都走被分定的组，这个有两种方案：
1. 在所有服务节点都部署 AB 两种逻辑，然后用户第一次访问给用户分组并记录到数据库（或 Redis ）中，用户再次访问的时候从数据库中读取用户的分组，然后走对应逻辑。
2. 服务前面加一个 API 网关层，API 网关用户给用户分组、记录分组信息、转发用户请求到特定分组的服务器集群。

然后单纯的灰度发布的话可能不需要固定用户的分组信息，所以通常的做法是从负载均衡上，给一台实例的权重设为 0 （停止分配流量），等没流量了就给这台实例升级为新版本，然后负载均衡慢慢提权重，一点一点放流量进来，同时监控服务状态，出现异常就掐断流量回滚，正常就逐渐把流量放到平均水准，然后再更新第二个实例，重复上述操作，知道把所有实例更新完毕。这个有些持续部署工具可以做到自动化的。

你会发现，这些基本都是通过运维方案来解决的，服务程序本身通常不需要考虑，顶多做好老版本的兼容，确保无缝升级的时候不会有兼容问题。

@libook 是的，之前有想过用 nginx+lua 的方案处理，也用了服务做跳转到类似 index@+ version.html 的方式。因为我的用户群体没那么大，所以说就没有集群，目前已知的线上也就两台服务器吧。所以不是很好用网关做灰度，nuxt 是启 node 服务的，不知道怎么修改他的代码来进行版本的切换