背景

单位的云办公相干零碎没有成熟的平滑公布计划，导致每一次公布都是间接公布，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.170set $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.170set $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