使用 nginx 进行 ab 站点的过程简单分析

由于业务需要，在官网上部署两套前端页面，通过特定的字段（例如手机号码）进行分流，来达到 a/b 站的要求，后续对 a/b 站最终数据进行分析，选出哪部分页面对用户体验来说会更优秀。

nginx 请求分流

考虑利用 nginx 的分流功能：http://neoremind.com/2012/03/nginx%E6%A0%B9%E6%8D%AEcookie%E5%88%86%E6%B5%81/

在 mac 下使用 brew install nginx，安装完成后的目录为：/usr/local/Cellar/nginx/1.10.3（根据不同的版本会有所不同）/，nginx 配置文件所在目录：/usr/local/etc/nginx。

在 Postman 中需要安装下载 Postman Interceptor 扩展程序，此时就可以通过发送 Headers 中的内容，来达到发送 Cookie 的目的：

(http://pic.findyou.xin/e84e776bb97f44d992454a680cb6daf7.png)

在 nginx 中，可以根据该 cookie 进行匹配判断，决定要发送的服务器 upstream：

match cookie
set $stream stream0;
if ($http_cookie ~* "phone=([^;]+)(1$)"){
    set $stream stream1;
}
if ($http_cookie ~* "phone=([^;]+)(2$)"){
    set $stream stream2;
}

在上面的示例中，仅能匹配单个 http_cookie 的最后一行，如果我们想要根据手机尾号进行用户划分的话，必须要匹配多个属性：

match cookie
        set $stream stream0;
        if ($http_cookie ~* "phone=([^;]+)([5-9]$)"){
            set $stream stream1;
        }
        if ($http_cookie ~* "phone=([^;]+)([0-4]$)"){
            set $stream stream2;
        }

进行范围查找，如果在 5-9 之间，对应 stream1，否则对应 stream2，如果没有该 cookie，需要给定一个默认值 stream0。

上述情况出现在用户已经登录的情况下，如果请求是处于注册/登录的过程中，此时并没有 cookie 数据，但这两种操作都是通过 POST 请求，在 form 表单中存在对应的字段手机号（phone），考虑是否可以根据 request body 中的字段进行填充。

nginx 中的变量介绍主要如链接中：https://moonbingbing.gitbooks.io/openresty-best-practices/content/openresty/inline_var.html

可以在日志中将 request_body 打印出来，只要加上 request_body 属性即可，如果我们加上的数据为“phone=111”

------WebKitFormBoundaryq2rbBAdTrAuTi6IG\x0D\x0AContent-Disposition: form-data; name=\x22phone\x22\x0D\x0A\x0D\x0A111\x0D\x0A------WebKitFormBoundaryq2rbBAdTrAuTi6IG--\x0D\x0A

可见这些字段是已经经过了额外的转义处理，如果想要分析 request body 中的字段比较麻烦，nginx 只有在修改插件运行的情况下（对 nginx 本身进行编程），才能访问到 request body 中的字段。

因此我们的方案调整为，注册/登录完成后写 Cookie，但不能马上刷新缓存，但可以通过页面上的 ajax 请求 success 回调，去强制重刷整个页面来获取 a/b 站点对应 js/css 资源，但可能造成额外的流量损耗。

内部域名解析/转换

但我们部署的服务理论上是在两台 docker 容器上，并无固定 ip，是通过不同的内部域名进行处理的，因此在 upstream 出现域名时，就会发生无法转发的问题，即定义的 http://${url}并不进行替换。

upstream main {
      server web1.local:80;
      server web2.local:80;
      server web3.local:80;
    }

通过问题查找，参考下面的一篇文章：

Make nginx to pass hostname of the upstream when reverseproxying I run several docker containers with hostnames: web1.local web2.local web3.local Routing to these done based on hostname by nginx. I have a proxy in front of this setup (on different machine conn... Server Fault - serverfault.com

曾经尝试了第一种方式，设置 proxy_set_header，并没有起作用：

    proxy_set_header Host            $host;
    proxy_set_header X-Forwarded-For $remote_addr;

第二种方式理论上应该可行，是通过开放多个端口的方式，建立几个 virtual server，但由于我们将系统部署在 lain（docker 的一种实践）上，限制条件比较多，只能开放一个 web 端口，因此该方式在 lain 环境上不可行。

server {
  listen      8001 default_server;
  server_name web1.example.com;
  location / {
    proxy_pass       http://web1.local:80;
    proxy_set_header Host web1.local:80;
  }
}

server {
  listen      8002 default_server;
  server_name web2.example.com;
  location / {
    proxy_pass       http://web2.local:80;
    proxy_set_header Host web2.local:80;
  }
}

server {
  listen      8003 default_server;
  server_name web3.example.com;
  location / {
    proxy_pass       http://web3.local:80;
    proxy_set_header Host web3.local:80;
  }
}

upstream main {
  server 127.0.0.1:8001;
  server 127.0.0.1:8002;
  server 127.0.0.1:8003;
}

server {
  listen      80;
  server_name example.com;
  location / {
    proxy_pass http://main;
  }
}

Tengine 提供此支持，http://tengine.taobao.org/document_cn/http_upstream_dynamic_cn.html，但通过测试发现 tengine 支持的这种方式可能只能利用外网可解析的域名来处理，如果是内网域名仍然是与没有配置该模块的结果相同。

upstream stream80 {
        dynamic_resolve fallback=next fail_timeout=30s;
        #server www.xxx.cn;
        server xxx.xxapp.xyz;
    }

转移到 xxx.xxapp.xyz，此为内部解析的域名：

(http://pic.findyou.xin/38257ca397a84fc896e0d9f617f99cc0.png)

我们将转移到 www.xxx.cn，会发现已经进行了转换（错误是由于 servername 名称不匹配）

(http://pic.findyou.xin/ba9885a13dcb4797ab9f50e473deae58.png)

基本判断 tengine 的这个模块应该是可用的，但域名解析可能用到了一些特殊的条件或算法，导致无法解析我们内网的域名，所以在只能部署单个对外端口的 docker 容器下，暂时不能解决内网 upstream 带 server_name 的问题（最终考虑将其部署在虚拟机上，开启多个端口来解决该问题，也就是参考链接中的第二条）。