灰度发布概述

软件开发过程中，通常不会直接推出最终版本，而是通过逐步迭代的方式进行降低风险。
灰度发布系统的核心是将用户流量分成不同部分，一部分用户使用新版本，而另一部分用户继续使用旧版本。通过控制流量比例，例如最初只有 5% 的用户使用新版本，如果没有问题，比例可以逐步提高到 10%、50%，最终实现 100% 用户使用新版本。这种方法可以最大程度地减少潜在问题对用户的影响。
除了逐步推出新版本外，灰度发布系统还可用于产品的 A/B 测试。通过将流量分成两部分，一部分用户使用 A 版本，另一部分用户使用 B 版本，可以测试哪个版本更有利于业务。

灰度发布的流程

• 用户首次请求时，根据设定的比例随机设置 cookie，实现流量染色。
• 用户再次访问时，根据 cookie 转发至不同版本的服务。
• 后端根据 cookie 请求不同的服务，前端根据 cookie 执行不同逻辑。

实现灰度发布

其灰度发布通常是通过 Nginx 实现的。Nginx 是一个反向代理服务，可以将用户请求转发给具体的应用服务器，这一层也被称为网关层。在网关层，可以控制流量分配，决定哪些流量使用 A 版本，哪些使用 B 版本。

创建 nest

创建个 nest 项目开启两个端口，一个 3000，一个 3001：

npx nest new gray_test -p npm

分别访问返回 Hello111 和 Hello 222：

现在我们就有了两个版本的 nest 代码。

使用 docker 运行 nginx 服务

设置容器名为 gray1，端口映射宿主机的 82 到容器内的 80：

现在访问 http://localhost:82/ 就可以看到 nginx 页面了：

继续跑个 nginx 容器：

容器名为 gray2，端口映射 83 到容器内的 80。
挂载目录不变。

修改 Nginx 配置文件，设置路由规则，将特定请求转发给指定的服务

把配置文件复制出来：

docker cp gray1:/etc/nginx/conf.d/default.conf ~/nginx-config

编辑复制文件：

# 定义一个location块，用于处理以/api开头的请求
location ^~ /api {
    # 使用rewrite模块来重写请求的URI
    # 将请求中/api/(.*)的部分重写为/$1，即去掉/api前缀
    # 'break'标志表示停止后续的重写操作
    rewrite ^/api/(.*)$/$1 break;

    # 将重写后的请求代理到后端服务器
    # 请求将被转发到192.168.0.100:3001这个地址
    proxy_pass http://192.168.0.100:3001;
}

然后我们访问下 http://localhost:83/api/：

创建多组 upstream，分别代表不同版本的服务

之前负载均衡的时候，是这么配的：

现在我们需要配置多组 upstream：

# 定义上游服务器组，用于版本1.0的服务
upstream version1.0_server {
    server 192.168.0.100:3000; # 指定服务器IP地址和端口号
}

# 定义上游服务器组，用于版本2.0的服务
upstream version2.0_server {
    server 192.168.0.100:3001; # 指定服务器IP地址和端口号
}

# 定义默认的上游服务器组，当请求没有指定版本时使用
upstream default {
    server 192.168.0.100:3000; # 指定默认的服务器IP地址和端口号
}

根据请求中的 cookie 决定流量转发的版本

set $group "default";
if ($http_cookie ~* "version=1.0"){
    set $group version1.0_server;
}

if ($http_cookie ~* "version=2.0"){
    set $group version2.0_server;
}

location ^~ /api {
    rewrite ^/api/(.*)$ /$1 break;
    proxy_pass http://$group;
}

测试验证

我们重新跑下容器：

访问 http://localhost:83/api/ 走到的就是默认的版本：

带上 version=2.0 的 cookie，走到的就是另一个版本的代码：

以上就是基于Nginx实现灰度发布的详细流程的详细内容，更多关于Nginx灰度发布的资料请关注IT俱乐部其它相关文章！