基于nginx实现上游服务器动态自动上下线——不需reload

upstream rs2 {
    server 127.0.0.1:11111;
    upsync 192.168.21.14:8500/v1/kv/upstreams/rs2/ upsync_timeout=6m upsync_interval=500ms upsync_type=consul strong_dependency=off;
    upsync_dump_path /usr/local/nginx/conf/servers/servers_rs2.conf;

    check interval=1000 rise=2 fall=2 timeout=3000 type=tcp default_down=false;
}

server {
        listen 80;
...

说明：

• 推荐使用http方式检测，http比tcp方式更准确，该检测方式为nginx_upstream_check_module提供，功能强大，参数简单解释：每隔1秒进行1次健康检查，每次超时时间为3秒，连续2次健康检查成功则认为这个上游服务健康，将会被上线或一直保持在线；连续2次健康检查失败则认为这个上游服务不健康，将会被剔除下线。“/health.htm”是上游服务的健康检查接口，通过它判断服务是否健康。具体参数解释可参考：http://tengine.taobao.org/document_cn/http_upstream_check_cn.html
• 参数简单解释：nginx-upsync-module模块会每隔0.5秒向consul数据库检查一次配置，每次超时时间为6分钟。具体参数解释可参考：https://github.com/weibocom/nginx-upsync-module
• nginx会在/usr/local/nginx/conf目录下面创建servers子目录，该子目录下会自动创建相关server配置文件。

到此，nginx配置修改完成。

三、创建upstream数据（consul键值对）

可以通过web页面或者脚本创建upstream数据，方法如下：

1. web页面操作

如果需要创建目录，在要创建的字段后面加上”/”即可，如：upstreams/ 。

“Key/Value” 中必须先创建”upstreams”目录（后面有字母s），然后再创建对应的server名称，截图如下：

2. 命令行操作

使用命令行时不需要先创建”upstreams/”目录，命令会自动创建目录以及server数据。

下面以上游服务Java1（IP为192.168.20.100，端口号为8080，upstream分组名称为rs1）为例：

添加记录

curl -X PUT http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token

上述命令执行后，会形成一条nginx的upstream默认配置信息，即：

server 192.168.20.100:8080 weight=1 max_fails=2 fail_timeout=10s;

可以通过下面命令自定义权重等值：

curl -X PUT -d "{\"weight\":100, \"max_fails\":2, \"fail_timeout\":10}" http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token
# 或者 
curl -X PUT -d '{"weight":100, "max_fails":2, "fail_timeout":10}' http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token

删除记录

curl -X DELETE http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token

更新权重

curl -X PUT -d "{\"weight\":100, \"max_fails\":2, \"fail_timeout\":10}" http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token
# 或者 
curl -X PUT -d '{"weight":100, "max_fails":2, "fail_timeout":10}' http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token

下线服务

curl -X PUT -d "{\"weight\":2, \"max_fails\":2, \"fail_timeout\":10, \"down\":1}" http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token
# 或者
curl -X PUT -d '{"weight":2, "max_fails":2, "fail_timeout":10, "down":1}' http://192.168.21.14:8500/v1/kv/upstreams/rs1/192.168.20.100:8080?token=$token

查看upstream rs1下面有哪些上游服务器

curl http://192.168.21.14:8500/v1/kv/upstreams/rs1?recurse

推荐使用命令行操作，建议将命令行组装成脚本实现DevOps

四、一点感悟

在改造该动态发现方案期间，遇到了很多问题，最棘手的一个问题是测试环境种nginx一直报错，upstream数据始终无法完整下载，经过各种排查还是没有发现问题，中间我怀疑过是consul的问题，换成了etcd还是同样的报错，最后通过抓包跟踪，发现是Linux内核参数配置不当，导致队列溢出tcp三次握手失败，影响nginx与consul通信。

很多方案理论上是没有问题的，甚至说有人已经成功运用了，但是实际上亲自实施的话还是会遇到各种各样的问题，有些甚至是致命的，这时候就需要耐心的解决。希望大家在看到这篇文章的时候也去动手试试，如果遇到了问题请静下心来耐心排查。

还有一个是，很多人说运维是不产生价值的，我认为这么说是不对的，运维需要体现的价值有很多，SRE就是其中的一种。