乐趣区

关于nginx:基于-Nginx-实现灰度发布与-AB-测试

jiezi

背景

单位的云办公相干零碎没有成熟的平滑公布计划，导致每一次公布都是间接公布，dll 文件或配置文件的变更会引起站点的重启。

云办公零碎的常驻用户有 10000+，即便短短半分多钟，也会收到一堆投诉。基于此，咱们梳理了一套平滑公布的计划。

实施方案

1、跟 nginx 代理服务器约定了一个健康检查的接口

2、通过接口返回的 http 状态码来让 ngx 是否分流用户申请（这个咱们单位的技术部那边有规范的做法）

3、依据提供的这个服务健康检查的接口：nginx 判断只有某个实例的接口返回 5xx 的状态码，即把该实例下线（nginx 不会把流量转发到该实例）

公布流程

目标次要是为了公布的时候可能平滑公布，所以 QA 与开发人员在公布得时候依照如下步骤操作：

1、关上零碎的 nginx 列表治理页面：[/publish/ngxconfig]

2、下架某一个实例（假如零碎集群有 A、B、C 个实例），比方 A 实例

3、查看是否下架胜利：这个就是咱们跟 nginx 约定的健康检查接口，失常在线状态下是 200 的 statu，切离线后，这个接口返回的是 401 的 statu。

在线状况：

离线状况：

4、察看监控站点，直至该实例下的 Req、Connnectiuon 流量都隐没

5、在该实例下进行版本公布

6、关上 Fidller，host 到待发布的实例，而后判断是否公布胜利（公布 dll、配置文件时，IIS 站点会短暂重启）

7、QA 同学走查灰度的 A 实例服务器，保障它失常运行，如此循环，直到所有服务器都公布。

进一步 AB 测试的优化

平滑公布做完之后，的确给我带来很大的便当，不必每次公布都发布告，不重要的或者非功能性的内容公布了就是了。

然而用久了，客户量下来之后，又遇到一个问题，那就是每一次业务大变更，大型公布都是间接公布到生产，这样可能存在危险。设计师设计的性能，用户不肯定齐全承受，一旦上线新版本，收到一大堆的吐槽，都是用户呀，如果能在小范畴人群内进行灰度试用，实现安稳的适度和应用反馈之后，优化后再上到生产会更好一点。

所以这边须要思考和设计一套对立的技术计划，将来无论云办公还是其余的业务零碎，都能通过灰度公布在可指定的小范畴内先进行体验和性能验证。

基于下面的平滑，咱们在 Nginx 反向代理服务器上动心理，让 nginx 来帮咱们做 ABTesting 的计划。

以下是咱们尝试的几种计划

1、Nginx 反向代理：去路 IP 策略

流程图：

步骤：

  • 1、进入云办公零碎，进入 Nginx 反代服务器
  • 2、Nginx 读取去路 IP 的 AB 名单
  • 3、依据 IP AB 名单进行流量转发(名单 A 走特定实例，名单 B 走云办公原有集群实例)
server {
listen 80;
server_name officecloud.com;
access_log officecloud.com/logs main;
ip_list 192.168.254.4,192.168.254.170

set $group default;
if ($remote_addr in iplist) {set $group ACluster;}
location / { 
proxy_pass http://$group;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
index index.html index.htm;
}
}

优缺点：

  • 1、配置简略，原资源平台的灰度降级就是依据 IP 名单来划分设计降级的
  • 2、内部计算机很多都是非固定 IP，这个适宜在公司内网实现，比方只是配置公司内网的 IP。
2、Nginx 反向代理：$.Cookies 策略

流程图：

步骤

  • 1、进入云办公零碎，进入 Nginx 反代服务器
  • 2、Nginx 读取 Http 申请的 Cokie 的 version 信息（也能够是别的 key）
  • 3、依据 Key 的版本来进行流量转发(比方 Version1.1 走特定集群，Version1.0 走通用集群实例)
server {
listen 80;
server_name officecloud.com;
access_log officecloud.com/logs main;
ip_list 192.168.254.4,192.168.254.170

set $group default;
if ($http_cookie ~* "version=V1.0"){set default;}
if ($http_cookie ~* "version=V1.1"){set $group ACluster;}

location / { 
proxy_pass http://$group;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
index index.html index.htm;
}
}

优缺点：

  • 1、配置简略，依据 Nginx 的 $COOKIE_version 属性来判断
  • 2、绝对稳固，对须要凋谢名单的用户，在 Cookie 头部退出特定的版本即可，利用只有少许的开发量
  • 3、首次拜访动态页面可能不会产生 cookie

备注：这是团队内认为最好的 Nginx 代理计划，同理，User-Agent 和 Header 都能够做此种类型的判断，然而 Header 须要侵入底层 HttpRequest 去业务增加，不倡议。

3、AB 集群 + 业务代理形式

流程图：

步骤：

  • 1、进入云办公零碎，两种形式进入零碎，一种是登录页登录：~/login，一种是 default 页面带 uckey 登录：~/default?usertoken=#usertoken#
  • 2、登录的时候和 usertoken 传入的时候进去 路由代理模块, 进行用户信息校验，依据不同的人员和部门 (人员和部门配置归属 AB 名单) 分流到两个不同的 AB 集群
  • 3、依据转发跳到具体的实例集群域名下（能够配置 AB 集群领有不同域名, 更容易辨别）

优缺点

  • 1、与 Nginx 剥离，不必依赖公司的通用平台和技术部的实现
  • 2、须要申请 AB 集群，AB 集群领有不同的域名。
  • 3、如果是前后端拆散状况下，须要保障动态站点和服务站点均申请 AB 集群
  • 4、所有入口须要对立做代理，有肯定的开发量

目前手上 2 个零碎曾经依据该计划实现了。

作者：翁智华
出处：cnblogs.com/wzh2010/p/13458723.html

退出移动版