基于 Nginx 实现灰度发布与AB测试

出处:http://adkx.net/9eigk

03cd597eb51fc8fbc032c4864ab255c8.png

背景

单位的云办公相关系统没有成熟的平滑发布方案,导致每一次发布都是直接发布,dll文件或配置文件的变更会引起站点的重启。 

云办公系统的常驻用户有10000+,即使短短半分多钟,也会收到一堆投诉。基于此,我们梳理了一套平滑发布的方案。


实施方案

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

2、通过接口返回的http状态码来让ngx是否分流用户请求(这个我们单位的技术部那边有标准的做法)

3、根据提供的这个服务健康检查的接口:nginx判断只要某个实例的接口返回5xx的状态码,即把该实例下线(nginx不会把流量转发到该实例)

6e00bdae732152d7c0284fa82d6d1ca0.png

发布流程

目的主要是为了发布的时候能够平滑发布,所以QA与开发人员在发布得时候按照如下步骤操作:

1、打开系统的nginx列表管理页面:[/publish/ngxconfig]

2、下架某一个实例(假设系统集群有A、B、C个实例),比如A实例

456ddcaa6b845279b4957c6d0b0da44e.png

3、查看是否下架成功:这个就是我们跟nginx约定的健康检查接口,正常在线状态下是200的statu,切离线后,这个接口返回的是401的statu。

在线情况:

112abda908135a966430a9895986ab30.png

离线情况:

6406c1cdb48387955e17a9fa1253ab83.png

4、观察监控站点,直至该实例下的Req、Connnectiuon流量都消失

 24cfb11d46075cd493695c9e6917f01b.png

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

6、打开Fidller,host到待发布的实例,然后判断是否发布成功(发布dll、配置文件时,IIS站点会短暂重启)

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

进一步AB测试的优化 

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

但是用久了,客户量上去之后,又遇到一个问题,那就是每一次业务大变更,大型发布都是直接发布到生产,这样可能存在风险。设计师设计的功能,用户不一定完全接受,一旦上线新版本,收到一大堆的吐槽,都是用户呀,如果能在小范围人群内进行灰度试用,完成平稳的过度和使用反馈之后,优化后再上到生产会更好一点。

所以这边需要思考和设计一套统一的技术方案,未来无论云办公还是其他的业务系统,都能通过灰度发布在可指定的小范围内先进行体验和功能验证。

基于上面的平滑,我们在Nginx反向代理服务器上动心思,让nginx来帮我们做ABTesting的方案。

以下是我们尝试的几种方案:

1、Nginx反向代理:来路IP策略 

流程图:

9842c1f9dd978c17583a7097449f42e7.png

步骤:

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策略 

流程图:

1697cdb21fd101663b102edb8f5d86e4.png

步骤

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集群+业务代理方式 

流程图:

bb2ec2b58a9b796bec5be8784a6c0195.png

步骤:

1、进入云办公系统,两种方式进入系统,一种是登录页登录:~/login ,一种是default页面带uckey登录:~/default?usertoken=#usertoken#

2、登录的时候和usertoken传入的时候进去 路由代理模块,进行用户信息校验,根据不同的人员和部门(人员和部门配置归属AB名单)分流到两个不同的AB集群

3、根据转发跳到具体的实例集群域名下(可以配置AB集群拥有不同域名,更容易区分)

优缺点 :

1、与Nginx剥离,不用依赖公司的通用平台和技术部的实现

2、需要申请AB集群,AB集群拥有不同的域名。

3、如果是前后端分离情况下,需要保证静态站点和服务站点均申请AB集群

4、所有入口需要统一做代理,有一定的开发量

目前手上2个系统已经根据该方案实现了。

推荐阅读:

世界的真实格局分析,地球人类社会底层运行原理

不是你需要中台,而是一名合格的架构师(附各大厂中台建设PPT)

企业IT技术架构规划方案

论数字化转型——转什么,如何转?

企业10大管理流程图,数字化转型从业者必备!

【中台实践】华为大数据中台架构分享.pdf

华为的数字化转型方法论

华为如何实施数字化转型(附PPT)

超详细280页Docker实战文档!开放下载

华为大数据解决方案(PPT)

d6d1cf4d330dce888ac77bfa16ac031c.png

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值