js判断客户端是否启用了代理_nginScript 系列：使用 nginScript 将客户端重定向到新服务器...

nginScript 的一个关键优势在于它提供了读取和设置 NGINX 配置变量的能力。变量可以用于自定义路由规则。也就是说，我们可以使用 JavaScript 来实现复杂的功能，这些功能可以直接对请求的处理产生影响。

将客户端重定向到新的应用服务器

在这篇文章里，我们将介绍如何使用 nginScript 来实现优雅的服务器间切换。我们不打算进行“一次性”的切换，而是定义了一个时间窗口，客户端在事件窗口内循序渐进地切换到新的服务器。我们可以逐渐地自动给新服务器增加流量。

我们定义了一个两个小时的时间窗口，我们希望切换就在这两个小时内完成，也就是下午 5 点到 7 点。我们预期在第一个 12 分钟内，有 10% 的客户端被重定向到新的服务器，24 分钟之后有 20%，并以此类推。下图展示了切换过程。

(点击放大图像)

在两个小时内将客户端从旧的服务器重定向到新的服务器

这种“渐进式切换”要求已经切换到新服务器的客户端不能又回到旧的服务器，也就是说，一旦一个客户端被重定向到新的服务器，那么从今以后它就一直被定向到那里。

我们会在稍后描述完整的配置，不过简单地说，NGINX 和 NGINX Plus 在处理已经被切换过来的请求时，会遵循如下规则。

• 如果切换时间窗口还没有开始，那么请求就被重定向到旧的服务器。

• 如果切换时间窗口已经结束，那么请求就被重定向到新的服务器。

• 如果切换在进行当中，那么：

1. 计算当前时间在切换时间窗口中的位置。

2. 计算客户端 IP 地址的散列值。

3. 计算散列值在所有散列值中的位置。

4. 如果散列值的位置比切换时间窗口的当前位置要大，那么请求就被重定向到新的服务器，否则重定向到旧的服务器。

为 HTTP 应用配置 NGINX 和 NGINX Plus

在这个例子里，我们将使用 NGINX 和 NGINX Plus 作为一个 Web 应用服务器的反向代理，所以所有的配置都是关于 HTTP 的。

首先，我们分别为旧应用程序和新应用程序所在的服务器定义单独的 upstream 配置块。虽然切换过程是渐进式的，NGINX 和 NGINX Plus 在切换期间会一直充当负载均衡器的角色。

upstream old { server 10.0.0.1; server 10.0.0.2;}upstream new { server 10.0.0.9; server 10.0.0.10;}

接下来，我们定义前端的服务，NGINX 和 NGINX Plus 通过它们将呈现内容发送给客户端。

js_include /etc/nginx/progressive_transition.js;js_set $upstream transitionStatus; # 基于时间窗口位置返回"old|new"server { listen 80; location / { set $transition_window_start "Wed, 31 Aug 2016 17:00:00 +0100"; set $transition_window_end "Wed, 31 Aug 2016 19:00:00 +0100"; proxy_pass http://$upstream; error_log /var/log/nginx/transition.log info; # 启用 nginScript 日志  }}

我们使用 nginScript 来决定应该使用哪个 upstream 组，所以我们需要指定 nginScript 代码的位置。在 NGINX Plus R11 及其后的版本里，所有的 nginScript 代码必须被放置在单独的文件里，然后通过 js_include 指令来指定它们的位置。

js_set 指令用于设置 $upstream 变量。要注意，这个指令并不是要让 NGINX 或 NGINX Plus 去调用 nginScript 函数 transitionStatus。NGINX 变量是按需进行计算的，也就是在处理请求期间用到变量时才会进行计算。所以，js_set 指令是要告诉 NGINX 或 NGINX Plus 在必要的时候如何计算 $upstream 变量。

server 代码块定义 NGINX 和 NGINX Plus 如何处理 HTTP 请求。listen 指令告诉 NGINX 和 NGINX Plus 对 80 端口(默认 HTTP 端口)进行监听，不过生产环境一般配置成 SSL/TLS 来保护传输中的数据。

location 代码块的作用域包括了整个应用空间(/)。在这个代码块里，我们使用了 set 指令和两个新的变量 $transition_window_start 和 $transition_window_end 来定义切换时间窗口。时间可以被声明成RFC 2822 格式(例子里所示)或ISO 8601 格式(包含毫秒)。两种格式必须包含它们各自的本地时区标识符。因为 JavaScript 的 Date.now 函数总是返回 UTC 日期和时间，所以只有提供本地时区才能进行准确的时间比较。

proxy_pass 指令将请求重定向到 upstream 组，transitionStatus 函数会对它进行计算。

最后，error_log 指令启用了 nginScript 事件日志，级别为 info 及以上(默认情况下，只有 warn 及以上级别的事件会被记录下来)。将这个指令放在 location 代码块里，并指定单独的日志文件，这样就可以避免将主要的错误日志与其他 info 日志消息混杂在一起。

HTTP 应用的 nginScript 代码

我们假设你已经启用了 nginScript 模块。

我们将 nginScript 代码放在/etc/nginx/progressive_transition.js文件里，正如 js_include 指令所指定的那样。所有的函数都包含在这个文件里。

被调用的函数必须在函数调用者之前出现，于是我们定义了一个函数用于返回客户端 IP 地址的散列值。如果应用服务器的主要用户处于相同的局域网内，那么我们的客户端就会有相似的 IP 地址，所以我们的散列函数需要为小区间的输入值返回平均分布的散列值。

在这个例子里，我们使用了FNV-1a 散列算法，这个算法短小精悍，很快，而且具有良好的平均分布能力。它的另一个优势在于，它返回的是一个 32 位的正整数，这样可以很方便地计算每一个客户端 IP 地址在输出区间的位置。下面的代码是 FNV-1a 算法的 JavaScript 实现。

function fnv32a(str) { var hval = 2166136261; for (var i = 0; i < str.length; ++i ) { hval ^= str.charCodeAt(i); hval += (hval << 1) + (hval << 4) + (hval << 7) + (hval << 8) + (hval << 24); } return hval >>> 0;}

接下来，我们定义 transitionStatus 函数，这个函数将 js_set 指令里的 $upstream 变量设置到 NGINX 配置里。

function transitionStatus(req) { var vars, window_start, window_end, time_now, timepos, numhash, hashpos; // 从 NGINX 配置里获取切换时间窗口  vars = req.variables; window_start = new Date(vars.transition_window_start); window_end = new Date(vars.transition_window_end); // 是否处于切换时间窗口内? time_now = Date.now(); if ( time_now < window_start ) { return "old"; } else if ( time_now > window_end ) { return "new"; } else { // 处于切换时间窗口内  // 计算切换时间窗口内的位置 (0-1) timepos = (time_now - window_start) / (window_end - window_start); // 获取客户端 IP 地址的散列值  numhash = fnv32a(req.remoteAddress); // 计算散列值在输出区间里的位置 (0-1) hashpos = numhash / 4294967295; // Upper bound is 32 bits req.log("timepos = " + timepos +