Consul服务发现与Nginx动态Upstream自动配置实战

服务发现架构设计与Consul核心组件

在微服务架构中，服务实例的动态扩缩容和故障迁移使得静态配置Nginx Upstream的方式越来越难以维护。Consul作为HashiCorp推出的服务发现与配置管理工具，通过Agent、Server和Service三个核心角色实现服务注册、健康检查和KV配置存储，能将Nginx的Upstream配置从静态文件转变为实时动态更新。

Consul服务发现的核心流程：服务启动时向本地Consul Agent注册，Agent将注册信息同步到Server集群，健康检查持续验证服务可用性，消费方通过DNS或HTTP API查询可用实例列表。当服务实例下线或健康检查失败时，Consul自动将其从可用列表中摘除。

Consul集群部署与服务注册

以三节点Consul Server集群加应用节点Agent的拓扑为例：

# Server节点配置 /etc/consul.d/server.json
{
  "node_name": "consul-server-1",
  "server": true,
  "bootstrap_expect": 3,
  "data_dir": "/opt/consul/data",
  "bind_addr": "10.0.1.11",
  "client_addr": "0.0.0.0",
  "ui_config": {"enabled": true},
  "retry_join": ["10.0.1.11", "10.0.1.12", "10.0.1.13"],
  "autopilot": {
    "max_trailing_logs": 500,
    "cleanup_dead_servers": true,
    "last_contact_threshold": "5s"
  }
}

服务注册通过JSON配置文件或HTTP API完成：

# 服务注册配置 /etc/consul.d/web-api.json
{
  "service": {
    "name": "web-api",
    "port": 8080,
    "tags": ["v2", "production"],
    "check": {
      "http": "http://127.0.0.1:8080/health",
      "interval": "10s",
      "timeout": "3s",
      "deregister_critical_service_after": "30s"
    }
  }
}

# 或通过API注册
curl -s --request PUT http://localhost:8500/v1/agent/service/register -d '{
  "ID": "web-api-10.0.2.21",
  "Name": "web-api",
  "Address": "10.0.2.21",
  "Port": 8080,
  "Check": {
    "HTTP": "http://10.0.2.21:8080/health",
    "Interval": "10s"
  }
}'

deregister_critical_service_after参数确保服务实例长时间不可用时自动从注册表中移除，避免流量被路由到已死亡的实例。

Consul Template动态生成Nginx Upstream

Consul Template是连接Consul与Nginx的桥梁，它监听Consul的服务变更事件，根据模板文件动态生成Nginx配置并触发reload：

# Nginx Upstream模板 /etc/consul-template/nginx-upstream.ctmpl
upstream web_api {
    {{- range service "web-api" }}
    server {{ .Address }}:{{ .Port }} max_fails=3 fail_timeout=10s;
    {{- end }}
}

server {
    listen 80;
    location /api/ {
        proxy_pass http://web_api;
        proxy_set_header Host host;
        proxy_set_header X-Real-IP remote_addr;
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }
}

Consul Template启动配置：

# /etc/consul-template/consul-template.hcl
consul {
  address = "127.0.0.1:8500"
  retry {
    enabled = true
    attempts = 12
    backoff = "5s"
  }
}

template {
  source = "/etc/consul-template/nginx-upstream.ctmpl"
  destination = "/etc/nginx/conf.d/upstream.conf"
  command = "nginx -s reload"
  perms = 0644
  error_on_missing_key = true
}

当Consul中web-api服务实例发生变化时，Consul Template在2秒内重新渲染配置文件并执行nginx -s reload，实现Upstream的秒级更新。

Nginx动态Upstream运行验证与流量切换

配置生效后，通过以下方式验证动态更新：

# 查看当前Upstream配置
cat /etc/nginx/conf.d/upstream.conf

# 查询Consul中注册的服务实例
curl -s http://127.0.0.1:8500/v1/health/service/web-api?passing | jq '.[].Service | {Address, Port}'

# 模拟服务下线：停止一个实例后观察Nginx配置变化
systemctl stop web-api@10.0.2.21
sleep 15
cat /etc/nginx/conf.d/upstream.conf | grep "10.0.2.21"
# 应无输出，说明已被移除

灰度发布与权重控制进阶配置

Consul的Service Tags和Meta字段支持灰度发布场景。通过为服务实例打上版本标签，在模板中实现按版本路由：

# 注册灰度版本实例
curl -s --request PUT http://localhost:8500/v1/agent/service/register -d '{
  "ID": "web-api-10.0.2.31-v2",
  "Name": "web-api",
  "Address": "10.0.2.31",
  "Port": 8080,
  "Tags": ["v2"],
  "Meta": {"weight": "20"}
}'

对应Nginx模板支持按Tag过滤和权重分配：

upstream web_api_v1 {
    {{- range service "web-api" | byTag "v1" }}
    server {{ .Address }}:{{ .Port }};
    {{- end }}
}

upstream web_api_v2 {
    {{- range service "web-api" | byTag "v2" }}
    server {{ .Address }}:{{ .Port }};
    {{- end }}
}

server {
    listen 80;
    location /api/ {
        split_clients "${remote_addr}" variant {
            90%   v1;
            10%   v2;
        }
        proxy_pass http://web_api_variant;
    }
}

这种方案无需额外引入服务网格组件，在中小规模微服务场景下即可实现零停机发布和按比例流量切换，运维成本远低于全链路Istio方案。