openresty域名动态解析

　工作中使用openresty，使用第三方服务API通过域名访问。但是，域名通过DNS解析出来之后，在openresty是有

很多时候我们会在 Nginx 配置文件里配置上一些域名，比如配置我们的上游服务器。

对于这类域名，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 服务。

Nginx 核心提供了一套供运行时使用的 DNS 解析机制，它充分契合 Nginx 的事件模型，同样是异步非阻塞的，并且提供了缓存机制。http、stream 和 mail 模块分别提供了配置指令（比如 http 模块提供的 resolver），供我们配置相关 DNS server 地址等信息。

下面这个简单的反向代理配置，就会在进行代理前解析 www.baidu.com 这个域名。

注意如果直接在 proxy_pass 指令里写明需要代理的域名（即不使用变量的方式），那么域名解析就会发生在配置解析阶段了，即上面所讲的过程。这其实也是一种实现动态 upstream 的方式。

这套运行时 DNS resolver 其实是一个 DNS client 的角色，由它自己组织查询报文并发送给目标 DNS 服务器，同时支持解析 IPv6 地址（从 1.5.8 开始），支持反向地址解析和 SRV 解析。它把对每个域名的解析抽象为一棵红黑树的节点，包括任何必要的信息。同时这棵红黑树也充当着缓存，查询时会以域名作为 key，如果对应缓存是新鲜的，即会复用缓存，并且会对解析得到的地址顺序进行一定的回转后再提供给上层使用。如果没有缓存或者缓存过期，新的 DNS 请求会被构建并且发送。

当然，很多时候这套运行时的 DNS resolver 也不能完全满足需求：

  使用 OpenResty 做反向代理的传统模式是在配置文件的 upstream{ } 块里书写多个服务器定义集群。这种方式不够灵活，增加服务器必须手动修改配置后重启 OpenResty，会影响正常服务。

  OpenResty 的 “balancer_by_lua” 指令让动态负载均衡称为可能，它替代了原生的 hash/ip_hash/least_conn 等算法，不仅可以让自由定制负载均衡策略，还可以随意调整后端服务器的数量，完全超越了 upstream 系列指令，实现了接近商业版 Nginx Plus 的功能。

   “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，它必须显式加载后才能使用，即：

ngx.balancer 提供四个函数：

 这几个函数的的用法都很简单，动态负载均衡的重点其实是服务器列表的维护和选择算法，这些工作通常应该在 “balancer_by_lua” 之外完成，ngx.balancer 只是最后的执行者。

 下面的代码是 ngx.balancer 的典型用法，使用了固定的服务器列表和随机数来选择后端，实际应用应该替换为动态更新的数据和更有意义的算法：

 另一种实现方式是把负载均衡算法的主要计算工作放在 “access_by_lua” 等阶段里完成，这样更加灵活，计算出的后端服务器地址等数据放在 ngx.var 或 ngx.ctx 里传递，“balancer_by_lua” 阶段只需要少量的代码：

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;

}