Nginx多级代理高可用架构分三层：接入层负责TLS终结与全局路由，中间层实现服务发现与灰度分流，后端层完成协议适配与熔断；需结合主动/被动健康检查、进程守护、GitOps配置管理及跨机架部署，并确保任意层故障时上层可无感降级。
利用 Nginx 构建多级代理层的高可用负载均衡架构，核心在于分层解耦、健康检查、故障自动转移和流量精细化调度。不是简单堆叠多个 Nginx 实例，而是让每一层承担明确职责：接入层负责 TLS 终结与全局路由，中间层做服务发现与灰度分流，后端层对接真实应用或更细粒度网关。关键不在“多级”，而在“每级可控、可观、可退”。
第一级：接入层（Global Ingress）——统一入口与安全管控
部署在 DMZ 或边缘节点，面向公网，只做最轻量的处理：
- 终止 HTTPS，复用 SSL 会话，卸载 TLS 计算压力
- 基于 Host、URI 前缀或请求头做一级路由（如 api.example.com → 中间层集群，static.example.com → CDN 或对象存储）
- 启用 upstream 的 keepalive 连接池，避免频繁建连；配置 proxy_next_upstream error timeout http_502 http_503 http_504 实现基础容错
- 通过 geo / map 模块识别地域或运营商，将流量导向就近的中间层集群（如北京集群、广州集群）
第二级：中间层（Service Mesh Edge）——动态服务发现与策略路由
该层不直连业务 Pod，而是对接注册中心（如 Consul、Nacos）或通过脚本定期拉取后端列表，实现服务拓扑感知：
- 使用 nginx-upsync-module 或 OpenResty + Lua 动态更新 upstream，避免 reload 配置导致连接中断
- 按版本标签（v1/v2）、权重（weight=80）、Header（X-Canary: true）实现灰度发布
- 对关键接口开启 limit_req（漏桶限流）和 mirror（流量镜像到测试环境）
- 记录 $upstream_addr $upstream_status $upstream_response_time 到独立日志，用于链路追踪与异常定位
第三级：后端代理层（Application Gateway）——贴近应用的协议适配与熔断
部署在应用同可用区，负责最后一跳。这一层可复用业务团队维护的 Nginx 实例，也可由 Service Mesh Sidecar 替代：
- 根据 上游传递的 x-service-name 或 path 规则，转发到本地 Pod IP+Port（配合 Kubernetes Headless Service 或 DNS SRV 记录）
- 配置 proxy_timeout 精细控制（如 read_timeout=3s，防止慢下游拖垮整条链路）
- 启用 proxy_cache 缓存静态资源或幂等查询结果（注意 Cache-Control 和 Vary 头）
- 结合 lua-resty-balancer 实现自定义负载策略（如最小活跃连接数、响应时间加权）
高可用增强要点
单靠 Nginx 配置无法保证高可用，需配套机制：
- 健康检查必须主动+被动结合：主动 check（interval=2s rise=2 fall=3）探测 /healthz；被动依据 upstream_status 自动摘除连续失败节点
- 所有层级 Nginx 进程需由 systemd 或 supervisor 管理，崩溃后秒级拉起；配置 worker_rlimit_nofile 和 epoll + multi_accept on 提升吞吐
- 配置变更走 GitOps 流水线：Ansible + Nginx config template + Confd 监听 etcd 变更，杜绝手工 reload
- 每个 upstream 至少 2 个节点跨机架/可用区部署，DNS 解析不指向单点 VIP，而是直接解析到多台 Nginx 的内网 IP
不复杂但容易忽略：真正的高可用不取决于某一层多强，而在于任意一层失效时，上层能否无感降级（比如中间层全挂，接入层可 fallback 到备用集群或返回缓存页），以及运维能否 5 分钟内定位是哪一级哪一节点出了问题。监控要覆盖每层 upstream 的成功率、P95 延迟、连接数、重试次数——这些指标比 “Nginx 是否在运行” 重要得多。
