1。 proxy_pass http://www.example.com 此方法仅在配置加载后解析一次，持续缓存，后续并不主动更新域名对应的IP，且启动或加载配置时候，如果解析不了，则无法启动。因此有很大局限性，比如在paas里用svc，云上用elb
2. 咋upstream里使用域名，如下，这种方式和第一种类似，缓存解析，只有reload配置或重启时候才会更新解析,且无法解析时候会导致无法启动。但是好处是可以使用upstream里的功能参数，例如配置负载均衡算法等
|
1 2 3 4 5 6 7 8 9 10 11 |
upstream backends { least_conn; server backends.example.com:8080 max_fails=3; } server { location / { proxy_pass http://backends; } } |
3。在proxy_pass里使用变量，这种方法是第一种的增强，解决了自动更新解析的问题， 必须指明resolver，不能使用系统自带，这种方法 但无法配置类似第2种里的LB算法等。 默认缓存A记录的TTL时间，如果想独立控制缓存时间，则使用valid参数
|
1 2 3 4 5 6 7 8 |
resolver 8.8.8.8 valid=10s; server { location / { set $servers github.com; proxy_pass http://$servers; } } |
4. 那如何既能使用upstream 来定义server group实现复杂配置，同时又能满足动态实时解析更新呢。nginx plus具有这样的能力，resolve参数是nginx plus特有功能。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
resolver 10.0.0.2 valid=10s; upstream backends { zone backends 64k; server backends.example.com:8080 resolve; } server { location / { proxy_pass http://backends; } } |
5. 如果企业应用大量使用srv记录注册服务信息，例如k8s内，那么nginx plus也支持使用srv记录来发现服务配置，例如优先级，权重，端口号。 优先级可用于控制配置backup server，权重可用于lb分配
|
1 2 3 4 5 6 7 8 9 10 11 12 |
resolver 10.0.0.2 valid=10s; upstream backends { zone backends 64k; server backends.example.com service=_http._tcp resolve; } server { location / { proxy_pass http://backends; } } |
6. 最后一种动态更新后端的方法就是使用nginx plus的api来直接动态修改
https://www.nginx.com/blog/dns-service-discovery-nginx-plus/
https://www.nginx.com/blog/load-balancing-kubernetes-services-nginx-plus/
