Nodejs 的灰度发布

发布于 1周前 作者 ionicwang 来自 nodejs/Nestjs

Nodejs 的灰度发布

求问大佬们，nodejs 的灰度发布流程，目前思路是模版语言来走不同版本的 js 。不知道 Nuxtjs 如何进行灰度发布？求大佬解答

Harmonyos Next教程
5 回复

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

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


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

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

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

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

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

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

关于Node.js的灰度发布（Canary Release），这是一种逐步推出新功能到生产环境的方法，通过限制新功能的用户范围来降低风险。以下是一个简化的灰度发布实现思路，利用Node.js和Express框架来演示：

  1. 配置环境变量： 在config.js文件中，设置环境变量来区分不同的发布阶段，比如production和canary。

    const config = process.env.NODE_ENV === 'canary' ? { isCanary: true } : { isCanary: false };
module.exports = config;

  2. 路由逻辑区分： 在app.js中，根据配置变量来决定使用哪个版本的逻辑。

    const express = require('express');
const config = require('./config');
const app = express();

app.get('/', (req, res) => {
    if (config.isCanary) {
        res.send('This is the canary release version.');
    } else {
        res.send('This is the production version.');
    }
});

app.listen(3000, () => {
    console.log('Server is running on port 3000');
});

  3. 部署策略： 使用反向代理（如Nginx）或者服务管理工具（如PM2）来将流量按比例导向不同的实例。比如，可以将10%的流量指向运行灰度版本的实例。

  4. 监控与回滚： 使用监控工具（如Prometheus、Grafana）来观察灰度版本的表现，如果发现异常，可以迅速回滚到稳定版本。

这样，通过逐步扩大灰度发布范围，可以确保新功能在全面铺开前经过充分验证，降低发布风险。

回到顶部