共计 2649 个字符，预计需要花费 7 分钟才能阅读完成。
背景
单位的云办公相干零碎没有成熟的平滑公布计划，导致每一次公布都是间接公布，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
