nginScript 的一个关键优势在于它提供了读取和设置 NGINX 配置变量的能力。变量可以用于自定义路由规则。也就是说，我们可以使用 JavaScript 来实现复杂的功能，这些功能可以直接对请求的处理产生影响。
将客户端重定向到新的应用服务器
在这篇文章里，我们将介绍如何使用 nginScript 来实现优雅的服务器间切换。我们不打算进行“一次性”的切换，而是定义了一个时间窗口，客户端在事件窗口内循序渐进地切换到新的服务器。我们可以逐渐地自动给新服务器增加流量。
我们定义了一个两个小时的时间窗口，我们希望切换就在这两个小时内完成，也就是下午 5 点到 7 点。我们预期在第一个 12 分钟内，有 10% 的客户端被重定向到新的服务器，24 分钟之后有 20%，并以此类推。下图展示了切换过程。
(点击放大图像)
在两个小时内将客户端从旧的服务器重定向到新的服务器
这种“渐进式切换”要求已经切换到新服务器的客户端不能又回到旧的服务器，也就是说，一旦一个客户端被重定向到新的服务器，那么从今以后它就一直被定向到那里。
我们会在稍后描述完整的配置，不过简单地说，NGINX 和 NGINX Plus 在处理已经被切换过来的请求时，会遵循如下规则。
如果切换时间窗口还没有开始，那么请求就被重定向到旧的服务器。
如果切换时间窗口已经结束，那么请求就被重定向到新的服务器。
如果切换在进行当中，那么：
计算当前时间在切换时间窗口中的位置。
计算客户端 IP 地址的散列值。
计算散列值在所有散列值中的位置。
如果散列值的位置比切换时间窗口的当前位置要大，那么请求就被重定向到新的服务器，否则重定向到旧的服务器。
为 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 + ", hashpos = " + hashpos); //error_log [info]
// 需要切换这个客户端吗?
if ( timepos > hashpos ) {
return "new";
} else {
return "old";
}
}
}transitionStatus 函数只有一个参数 req，这个参数代表的是一个 HTTP request 对象。request 对象的 variables 属性包含了 NGINX 的所有配置变量，包括用于设置切换时间窗口的 $transition_window_start 和 $transition_window_end。
外面的 if/else 代码块检查切换时间窗口是否启动、结束或者正在进行当中。如果在进行当中，我们通过向 fnv32a 函数传递 req.remoteAddress 来获取客户端 IP 地址的散列值。
然后我们计算散列值在区间中的位置。因为 FNV-1a 算法返回的是一个 32 位的正整数，我们可以直接将散列值除以 4,294,967,295（32 位整数的十进制表示）。
这个时候，我们调用 req.log() 来记录散列位置和切换时间窗口的当前位置。我们使用 info 级别将这些信息记录到之前在 NGINX 和 NGINX Plus 里配置的 error_log 文件里，并生成如下所示的日志条目。其中 js: 前缀表示从 JavaScript 代码中获得的日志条目。
2016/09/08 17:44:48 [info] 41325#41325: *84 js: timepos = 0.373333, hashpos = 0.840858
最后，我们比较散列值在输出区间中的位置和切换时间窗口的当前位置，并返回相应的 upstream 组的名字。
总结
在这篇文章里，我们介绍了如何使用 nginScript 复杂的编程式配置循序渐进地切换客户端到新的服务器。通过部署自定义逻辑来实现可控地选择合适的上游组，这只是 nginScript 提供的众多解决方案里一个特性。
