主页 > Linux > nginScript 系列:使用 nginScript 将客户端重定向到新服务器

nginScript 系列:使用 nginScript 将客户端重定向到新服务器

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

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

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

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

(点击放大图像)

nginScript 系列:使用 nginScript 将客户端重定向到新服务器

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

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

我们会在稍后描述完整的配置,不过简单地说,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 + ", 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 提供的众多解决方案里一个特性。

说点什么吧
  • 全部评论(0
    还没有评论,快来抢沙发吧!