nginx openresty DNS resolver配置实例，通过配置resolver解决proxy_pass中使用变量参数，高性能负载均衡 NGINX Plus 中 RESTful API

nginx openresty DNS resolver配置实例
nginx openresty 通过配置resolver解决proxy_pass中使用变量参数
nginx openresty 配置proxy_pass转发的/路径
NGINX Plus 中 RESTful API
高性能负载均衡
- HTTP 负载平衡
- TCP 和 UDP 负载平衡
- 负载均衡方法
- 使用 NGINX Plus 限制连接
- 会话持久性
- 主动健康检查
- 使用 DNS 的服务发现

nginx openresty DNS resolver配置实例

nginx 通过 proxy_pass 和 upstream server 通信的时候需要手动指定 resolver。某些时候 DNS 解析失败就会出现这个错误：

domain.com could not be resolved.

可以指定多个 DNS 并重置域名 TTL 延长 nginx 解析缓存来保障解析成功率：

resolver 5.5.5.5 114.114.114.114 valid=300s;

如果还有解析错误，可以用 dnsmasq 在本地自建 DNS，顺带还有加速解析的好处：

#/etc/dnsmasq.conf
domain-needed
bogus-priv
cache-size=51200
listen-address=127.0.0.1#server=223.5.5.5
resolv-file=/etc/resolv.conf

另外需要注意的是 proxy_pass 并不是每次请求都会进行解析，如果 upstream IP 频繁变动，需要强制解析:

# via http://forum.nginx.org/read.php?2,215830,215832
resolver 127.0.0.1;
set $backend "foo.example.com";
proxy_pass http://$backend;

https://forum.nginx.org/read.php?2,215830,215832

Re: Does Nginx honor DNS TTLs for proxy upstreams?
Previous Message Next MessageForum List Message List New Topic Print View
Maxim Dounin
September 26, 2011 05:38AM
Hello!On Mon, Sep 26, 2011 at 04:42:07AM -0400, csg wrote:> I have a short question on Nginx's proxy module. In our setup we reverse
> proxy specific requests to the server of an external partner via
> proxy_pass. Over the weekend the partner updated DNS but Nginx wasn't
> catching up the change and still sent traffic to the old server despite
> the fact the TTL of the record was little enough.
>
> An additional obstacle might be that in our case we have for example
>
> proxy_pass http://foo.example.com;
>
> where foo.example.com is a CNAME to bar.example.com (TTL of 1 hour)
> which is a A record (TTL of 60 seconds).
>
> Does Nginx honor DNS changes for upstream proxies or are lookups only
> done once on startup? If not, will the TTL being honor even if it has to
> traverse a list of CNAME records until it hits an A record?No, domain names statically configured in config are only looked
up once on startup (or configuration reload).> Both configuration directives, resolver and resolver_timeout are not
> set, therefore the default of 30 seconds should apply (if that is
> relevant here).These are not relevant for "proxy_pass http://foo.example.com;".
Resolver is only used for proxy_pass with variables, i.e.
something likeresolver 127.0.0.1;
set $backend "foo.example.com";
proxy_pass http://$backend;In such setup ip address of "foo.example.com" will be looked up
dynamically and result will be cached for 5 minutes.Maxim Dounin_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

nginx openresty 通过配置resolver解决proxy_pass中使用变量参数

比如url为：localhost/redirect/2?destip=wiki.jikexueyuan.com

nginx.conf配置：

server {listen       80;server_name  localhost;resolver 1.2.4.8;#这个就是做域名解析的，如果你的地址直接是ip则可以不需要这个配置#charset koi8-r;#access_log  logs/host.access.log  main;location / {root   html;index  index.html index.htm;}location  /redirect/1 {rewrite ^(.*)$ http://$arg_dest-ip:$arg_dest-port/$arg_uri/$arg_media-type/$arg_media-id?token=$arg_token？;}location  /redirect/2 {proxy_pass http://$arg_destip/;#$arg_destip就是url中带的参数destip的值#proxy_pass $arg_destip;#proxy_set_header Data $arg_destip;#echo $arg_destip;#proxy_set_header Data $arg_h-Date;#proxy_set_header Authorization $arg_h-Authorization;#proxy_set_header Content-Type $arg_h-Content-Type;#proxy_set_header Content-Length $content_length;}

nginx openresty 配置proxy_pass转发的/路径

请求原地址 ：http://servername/static_js/test.htmllocation ^~ /static_js/
{ proxy_cache js_cache; proxy_set_header Host js.test.com; proxy_pass http://js.test.com/;
}或者 使用rewritelocation ^~ /static_js/
{ proxy_cache js_cache; proxy_set_header Host js.test.com; rewrite /static_js/(.+)$ /$1 break; proxy_pass http://js.test.com;
} 代理成 http://js.test.com/test.htmllocation ^~ /static_js/
{ proxy_cache js_cache; proxy_set_header Host js.test.com; proxy_pass http://js.test.com;
}
代理成 http://js.test.com/static_js/test.htm域名跳转 访问 crm6yy_proxy.xxx.com    跳转到  crm6yy.xxx.comserver {listen 80  ;server_name crm6yy_proxy.xxx.com;location / {proxy_set_header Host $host;proxy_set_header X-Real-Ip $remote_addr;proxy_set_header X-Forwarded-For $remote_addr;proxy_pass http://crm6yy.xxx.com/;}
}    正向代理 场景A 不能上外网B 能上外网 （A和B可以互相访问）C 外面的网站 http://www.baidu.comB上nginx配置如下代码resolver 8.8.8.8;  server {  listen       8090;  location / {  proxy_pass $scheme://$http_host$request_uri;  }  }
使用：在A机器访问：或者 curl -x B:8090 -k "C"或者 export http_proxy="http://B:8090"或者windows下：在internet选项->连接->局域网设置->代理服务器 填入ip及端口即可

NGINX Plus 中 RESTful API

NGINX Plus 包含一个带有单个 API 端点的 RESTful API。使用NGINX Plus API以零停机时间动态更新上游配置和键值存储。

以下配置片段包含api启用对/api端点的读写访问的指令。

upstream backend {zone backends 64k;server 10.10.10.2:220 max_conns=250;server 10.10.10.4:220 max_conns=150;
}server {listen 80;server_name www.example.org;location /api {api write=on;}
}

使用上面示例中启用的 API，您可以使用以下curl命令将新服务器添加到现有上游组。它使用POST方法和 JSON 编码将服务器的 IP 地址设置为 192.168.78.66，其权重为 200，最大同时连接数为 150。

$ curl -iX POST -d '{"server":"192.168.78.66:80","weight":"200","max_conns":"150"}' http://localhost:80/api/version/http/upstreams/backend/servers/

要以 JSON 格式显示所有后端上游服务器的完整配置，请运行：

$ curl -s http://localhost:80/api/version/http/upstreams/backend/servers/ | python -m json.tool{"backup": false,"down": false,"fail_timeout": "10s","id": 0,"max_conns": 250,"max_fails": 1,"route": "","server": "10.10.10.2:220","slow_start": "0s","weight": 1},{"backup": false,"down": false,"fail_timeout": "10s","id": 1,"max_conns": 150,"max_fails": 1,"route": "","server": "10.10.10.4:220","slow_start": "0s","weight": 1},{"backup": false,"down": false,"fail_timeout": "10s","id": 2,"max_conns": 200,"max_fails": 1,"route": "","server": "192.168.78.66:80","slow_start": "0s","weight": 200}

要修改现有上游服务器的配置，请通过其内部 ID 进行标识，该 ID 出现在id上面输出的字段中。下面的命令使用该PATCH方法重新配置ID为2的服务器，设置其IP地址和监听端口为192.168.78.55:80，权重为500，连接限制为350。

$ curl -iX PATCH -d '{"server":"192.168.78.55:80","weight":"500","max_conns":"350"}' http://localhost:80/api/version/http/upstreams/backend/servers/2

高性能负载均衡

参照地址：
https://www.nginx.com/products/nginx/load-balancing/
https://www.nginx.com/blog/dns-service-discovery-nginx-plus/
https://www.nginx.com/blog/openshift-ecosystem-implementing-the-nginx-proxy-model-on-red-hat-openshift/

平衡服务器、客户端和代理之间的网络流量是让客户满意和优化基础架构的关键。借助 NGINX Plus 高性能负载均衡，您可以横向扩展并提供冗余；启用全局服务器负载平衡 (GSLB)、会话持久性和主动健康检查；并动态重新配置您的基础架构，而无需重新启动。NGINX Plus 不仅负载均衡 HTTP 流量，还负载均衡 TCP 和 UDP。

HTTP 负载平衡

在负载均衡 HTTP 流量时，NGINX Plus 会终止每个 HTTP 连接并单独处理每个请求。您可以去除 SSL/TLS 加密，检查和操作请求，使用速率限制对请求进行排队，然后选择负载平衡策略。

为了提高性能，NGINX Plus 可以自动对 HTTP 事务应用广泛的优化，包括 HTTP 协议升级、keepalive 优化以及内容压缩和响应缓存等转换。

使用 NGINX Plus 可以轻松负载平衡 HTTP 流量：

http {upstream my_upstream {server server1.example.com;server server2.example.com;}server {listen 80;location / {proxy_set_header Host $host;proxy_pass http://my_upstream;}}
}

首先使用该server指令指定一个虚拟服务器，然后指定listen用于通信的端口。使用location块匹配客户端请求的 URL，使用指令设置Host标头proxy_set_header，并包含proxy_pass将请求转发到上游组的指令。（该upstream块定义了 NGINX Plus 负载平衡流量的服务器。）

有关更多信息，请查看有关使用 NGINX 和 NGINX Plus 进行负载平衡的介绍。

TCP 和 UDP 负载平衡

NGINX Plus 还可以对 MySQL 等 TCP 应用程序和 DNS 和 RADIUS 等 UDP 应用程序进行负载均衡。对于 TCP 应用程序，NGINX Plus 终止 TCP 连接并创建到后端的新连接。

stream {upstream my_upstream {server server1.example.com:1234;server server2.example.com:2345;}server {listen 1123 [udp];proxy_pass my_upstream;}
}

配置类似于 HTTP：指定一个带有server指令的虚拟服务器，listen用于端口上的流量，以及proxy_pass对upstream组的请求。

有关 TCP 和 UDP 负载平衡的更多信息，请参阅NGINX Plus 管理指南。

负载均衡方法

NGINX Plus 支持许多用于 HTTP、TCP 和 UDP 负载平衡的应用程序负载平衡方法。所有方法都考虑了您可以选择分配给每个上游服务器的权重。

1、Round Robin (the default) – Distributes requests across the upstream servers in order.
2、Least Connections – Forwards requests to the server with the lowest number of active connections.
3、Least Time – Forwards requests to the least‑loaded server, based on a calculation that combines response time and number of active connections. Exclusive to NGINX Plus.
4、Hash – Distributes requests based on a specified key, for example client IP address or request URL. NGINX Plus can optionally apply a consistent hash to minimize redistribution of loads if the set of upstream servers changes.
5、IP Hash (HTTP only) – Distributes requests based on the first three octets of the client IP address.
6、Random with Two Choices – Picks two servers at random and forwards the request to the one with the lower number of active connections (the Least Connections method). With NGINX Plus, the Least Time method can also be used.

Round Robin（默认）——按顺序在上游服务器之间分发请求。
最少连接 - 将请求转发到活动连接数最少的服务器。
最少时间 – 根据结合响应时间和活动连接数的计算，将请求转发到负载最少的服务器。NGINX Plus 独有。
Hash – 根据指定的键（例如客户端 IP 地址或请求 URL）分发请求。如果上游服务器集发生变化，NGINX Plus 可以选择应用一致的哈希来最小化负载的重新分配。
IP 哈希（仅限 HTTP）——根据客户端 IP 地址的前三个八位字节分配请求。
Random with Two Choices –随机选择两台服务器并将请求转发到活动连接数较少的服务器（最少连接方法）。对于 NGINX Plus，还可以使用最少时间方法。

使用 NGINX Plus 限制连接

您可以限制 NGINX Plus 与上游 HTTP 或 TCP 服务器建立的连接数，或与 UDP 服务器的会话数。当与服务器的连接或会话数超过定义的限制时，NGINX Plus 将停止建立新的连接或会话。

在下面的配置片段中，webserver1的连接限制为250，webserver2的连接限制为150。该queue指令指定 NGINX Plus 放置在操作系统侦听队列中的最大额外连接数，每个最多 30 秒；额外的超额请求被丢弃。

upstream backend {zone backends 64k;queue 750 timeout=30s;server webserver1 max_conns=250;server webserver2 max_conns=150;
}

当服务器上的活动连接数低于其限制时，NGINX Plus 从队列中发送连接。限制连接有助于确保一致、可预测的客户端请求服务 - 即使在流量高峰期间也是如此。

会话持久性

您可以配置 NGINX Plus 来识别用户会话并将会话中的所有请求发送到同一个上游服务器。这在应用服务器本地存储状态时至关重要，因为当对正在进行的用户会话的请求发送到不同的服务器时会发生致命错误。当应用程序跨集群共享信息时，会话持久性还可以提高性能。

除了 NGINX 开源支持的基于哈希的会话持久性（哈希和 IP 哈希负载平衡方法），NGINX Plus 还支持基于 cookie 的会话持久性，包括粘性 cookie。NGINX Plus 将会话 cookie 添加到从上游组到给定客户端的第一个响应中，安全地识别哪个服务器生成了响应。后续的客户端请求包括 cookie，NGINX Plus 使用它来将请求路由到同一个上游服务器：

upstream backend {server webserver1;server webserver2;sticky cookie srv_id expires=1h domain=.example.com path=/;
}

在上面的例子中，NGINX Plus在初始客户端响应中插入一个名为srv_id的 cookie来标识处理请求的服务器。当后续请求包含 cookie 时，NGINX Plus 会将其转发到同一服务器。

NGINX Plus 还支持粘性学习和粘性路由持久化方法。

注意：基于 Cookie 的会话持久性是 NGINX Plus 独有的。

主动健康检查

默认情况下，NGINX 对来自上游服务器的响应执行基本检查，并在可能的情况下重试失败的请求。NGINX Plus 添加了带外应用程序健康检查（也称为综合事务）和慢启动功能，以将新的和恢复的服务器优雅地添加到负载平衡组中。

这些特性使 NGINX Plus 能够检测和解决更广泛的问题，显着提高 HTTP 和 TCP/UDP 应用程序的可靠性。

upstream my_upstream {zone my_upstream 64k;server server1.example.com slow_start=30s;
}server {# ...location /health {internal;health_check interval=5s uri=/test.php match=statusok;proxy_set_header Host www.example.com;proxy_pass http://my_upstream}
}match statusok {# Used for /test.php health checkstatus 200;header Content-Type = text/html;body ~ "Server[0-9]+ is alive";
}

在上面的例子中，NGINX Plus每五秒发送一个/test.php请求。该match块定义了响应必须满足的条件才能将上游服务器视为健康：状态代码200 OK和包含文本的响应正文。ServerN is alive

注意：主动健康检查是 NGINX Plus 独有的。

使用 DNS 的服务发现

默认情况下，NGINX Plus 服务器在启动时解析 DNS 名称，持久缓存解析的值。当您使用域名（例如example.com）通过server指令和resolve参数标识一组上游服务器时，NGINX Plus 会定期重新解析域名。如果关联的 IP 地址列表发生了变化，NGINX Plus 会立即开始在更新的服务器组之间进行负载平衡。

要将 NGINX Plus 配置为使用 DNSSRV记录，请在resolver指令中包含指令和service=http参数server，如下所示：

resolver 127.0.0.11 valid=10s;upstream service1 {zone service1 64k;server service1 service=http resolve;
}

在上面的示例中，NGINX Plus 每 10 秒查询 127.0.0.11（内置 Docker DNS 服务器）以重新解析域名service1。

注意：使用 DNS 的服务发现是 NGINX Plus 独有的。