基于Nginx实现灰度发布的详细流程
作者:云牧
灰度发布概述
软件开发过程中,通常不会直接推出最终版本,而是通过逐步迭代的方式进行降低风险。
灰度发布系统的核心是将用户流量分成不同部分,一部分用户使用新版本,而另一部分用户继续使用旧版本。通过控制流量比例,例如最初只有 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灰度发布的资料请关注脚本之家其它相关文章!