工作中使用openresty,使用第三方服务API通过域名访问。但是,域名通过DNS解析出来之后,在openresty是有
配置解析阶段
很多时候我们会在 Nginx 配置文件里配置上一些域名,比如配置我们的上游服务器。
upstream example.com {
server test.example.com;
}
对于这类域名,Nginx 会在配置解析阶段就将其解析出来,接下来(请求处理过程)使用的都是当时解析得到的 IP。Nginx 核心有一个函数 ngx_parse_url
,负责对 url 格式进行分析,包括解析出主机名,端口号以及 URL path 等。针对 IPv4 的情况,它会调用 ngx_parse_inet_url
进行具体的解析任务,如果必要,最终它会调用到 ngx_inet_resolve_host
进行域名解析,ngx_inet_resolve_host
大多情况下会使用 getaddrinfo 进行解析,最终向 /etc/resolv.conf 下所配置的 DNS server 发起解析请求。
归纳来说这个解析过程有两个特点,一是使用了系统配置的 DNS server;二是解析过程是同步且阻塞的,因此这种解析方式仅在 Nginx 配置解析阶段会被使用。另外这种解析方式的缺点就是只解析一次,所以如果在 Nginx 运行过程中域名解析发生了改变也是无法感知到的,除非手动重启 Nginx 服务。
运行时 DNS resolver
Nginx 核心提供了一套供运行时使用的 DNS 解析机制,它充分契合 Nginx 的事件模型,同样是异步非阻塞的,并且提供了缓存机制。http、stream 和 mail 模块分别提供了配置指令(比如 http 模块提供的 resolver),供我们配置相关 DNS server 地址等信息。
下面这个简单的反向代理配置,就会在进行代理前解析 www.baidu.com 这个域名。
location / {
set $myupstream www.baidu.com;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://${myupstream}/index.html;
}
注意如果直接在 proxy_pass
指令里写明需要代理的域名(即不使用变量的方式),那么域名解析就会发生在配置解析阶段了,即上面所讲的过程。这其实也是一种实现动态 upstream 的方式。
这套运行时 DNS resolver 其实是一个 DNS client 的角色,由它自己组织查询报文并发送给目标 DNS 服务器,同时支持解析 IPv6 地址(从 1.5.8
开始),支持反向地址解析和 SRV 解析。它把对每个域名的解析抽象为一棵红黑树的节点,包括任何必要的信息。同时这棵红黑树也充当着缓存,查询时会以域名作为 key,如果对应缓存是新鲜的,即会复用缓存,并且会对解析得到的地址顺序进行一定的回转后再提供给上层使用。如果没有缓存或者缓存过期,新的 DNS 请求会被构建并且发送。
当然,很多时候这套运行时的 DNS resolver 也不能完全满足需求:
- 无法配置主备 DNS 服务器地址,我们在 resolver 指令里配置的地址都会按顺序被轮询到。
- 无法在 DNS 服务器故障或者网络质量不佳的情况下复用陈旧的缓存,这可能导致上层服务不可用。
- 每个 Nginx worker 进程独享解析缓存.
运行时 balancer_by_lua_file
使用 OpenResty 做反向代理的传统模式是在配置文件的 upstream{ } 块里书写多个服务器定义集群。这种方式不够灵活,增加服务器必须手动修改配置后重启 OpenResty,会影响正常服务。
OpenResty 的 “balancer_by_lua” 指令让动态负载均衡称为可能,它替代了原生的 hash/ip_hash/least_conn 等算法,不仅可以让自由定制负载均衡策略,还可以随意调整后端服务器的数量,完全超越了 upstream 系列指令,实现了接近商业版 Nginx Plus 的功能。
使用方式
upstream dyn_backend { # 动态上游集群 server 0.0.0.0; # 占位用,无实际意义 balancer_by_lua_file service /proxy/balancer .lua; # 执行负载均衡的 Lua 代码 keepalive 10; # 需在 balancer 指令之后 } |
“balancer_by_lua” 也是一个比较特殊的执行阶段,在这里不能使用 ngx.sleep、ngx.req.* 或 coocket,同时应当尽量避免大计算量操作或磁盘读写,否则会导致阻塞。
动态负载均衡使用的服务器列表通常存储在外部的 Redis 或 MySQL 里,由于不能直接使用 cosocker,所以在 “balancer_by_lua” 里也就不能操作这些服务器。但这并不是什么大问题,完全可以在其他的阶段(例如 access_by_lua、ngx.timer)里访问服务器获取列表、解析域名,然后放在 ngx.ctx 或全局模块里传递过来。
支持版本
This directive was first introduced in the v0.10.0
release.
功能接口
在 “balancer_by_lua” 里除了基本的 ngx.* 功能接口外,主要使用的是库 ngx.balancer,它必须显式加载后才能使用,即:
local balancer - require "ngx.balancer" -- 显式加载 ngx.balancer 库
ngx.balancer 提供四个函数:
- set_current_peer:设置使用的后端服务器,必须是 IP 地址,不能是域名;
- set_timeouts:设置后端的连接和读写超时时间,单位是秒;
- set_more_tries:设置连接失败后的重试次数;
- get_last_failure:获取上一次连接失败的具体原因。
这几个函数的的用法都很简单,动态负载均衡的重点其实是服务器列表的维护和选择算法,这些工作通常应该在 “balancer_by_lua” 之外完成,ngx.balancer 只是最后的执行者。
下面的代码是 ngx.balancer 的典型用法,使用了固定的服务器列表和随机数来选择后端,实际应用应该替换为动态更新的数据和更有意义的算法:
local servers = { -- 简单的服务器列表,IP 地址 {"127.0.0.1", 80}, -- 实际上应该从 Redis {"127.0.0.1", 81}, -- 等服务器里动态加载 } balancer.set_timeouts(1, 0.5, 0.5) -- 后端的连接和读写超时时间 balancer.set_more_tries(2) -- 连接失败后最多在重试 2 次 local n = math.random(#servers) -- 这里使用随机算法作为示例 local ok, err = balancer.set_current_peer( -- 设置使用的后端服务器 servers[n][1], servers[n][2]) -- 使用 IP 地址和端口号 if not ok then -- 检查是否设置成功 ngx.log(ngx.ERR, "failed to set peer: ", err) return ngx.exit(500) end
另一种实现方式是把负载均衡算法的主要计算工作放在 “access_by_lua” 等阶段里完成,这样更加灵活,计算出的后端服务器地址等数据放在 ngx.var 或 ngx.ctx 里传递,“balancer_by_lua” 阶段只需要少量的代码:
local server = ngx.ctx.server -- 之前计算得到的后端服务器 if balancer.get_last_failure() then -- 后端出错,需要重新选择 server = ... -- 重新计算后端服务器 end local ok, err = balancer.set_current_peer(server[1], server[2]) -- 通常无需在计算,直接设置,IP 地址和端口号
动态域名使用
upstream dynamicBackend { server 0.0.0.1; # just an invalid address as a place holder balancer_by_lua_file 'conf/dynamic_domain/balancer_handle.lua'; keepalive 100; # connection pool }
location / {
proxy_connect_timeout 5s;
proxy_send_timeout 10s;
proxy_read_timeout 30s;
#默认值为0:重试次数不受限制
proxy_next_upstream_tries 2;
#默认情况下只有GET请求会重试(基于这样的考虑:只有GET请求才是幂等)
proxy_next_upstream error timeout non_idempotent;
access_by_lua_file 'conf/access_handle.lua';
log_by_lua_file 'conf/log_handle.lua';
proxy_pass $proxy_scheme://dynamicBackend;
}