使用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的目的：

 

 

 

在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;
    }

 

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

http://serverfault.com/questions/598202/make-nginx-to-pass-hostname-of-the-upstream-when-reverseproxying

 

曾经尝试了第一种方式，设置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的问题（最终考虑将其部署在虚拟机上，开启多个端口来解决该问题，也就是参考链接中的第二条）。