nginx 能撑住大规模微服务集群，关键在于合理配置与架构设计：采用多 worker 进程+事件驱动模型提升并发能力，通过 upstream 实现静态服务发现与健康检查，结合路由规则支持灰度与分流，并需配套可观测性与高可用方案。
Nginx 能撑住大规模微服务集群，关键不在“能不能用”，而在“怎么配、怎么搭、怎么管”。它本身不是服务发现组件，也不做熔断限流，但作为边缘网关，它的轻量、稳定和可编程性，让它成为微服务流量入口最务实的选择。
Nginx 的进程模型天然适配高并发场景
主进程只做配置加载和 worker 管理，真正处理请求的是多个独立的 worker 进程。每个 worker 采用事件驱动（epoll/kqueue），单进程就能高效处理数万连接。微服务集群动辄每秒数万请求，这种模型比线程模型更省资源、更少锁竞争。
- worker_processes 建议设为 CPU 核心数，避免上下文切换开销
- worker_rlimit_nofile 必须调高（如 100000），否则大量连接会报 “too many open files”
- 所有 worker 共享监听端口，靠内核层面的 accept 共享机制分发连接，无中心调度瓶颈
upstream 是微服务流量调度的核心载体
它不依赖注册中心，靠静态 IP/DNS 或配合 DNS 动态解析（resolver + variables）对接服务实例。对微服务而言，这就是“手动服务发现”——简单、可控、无额外组件依赖。
- 支持 weight 实现加权轮询，让高配节点多承接流量
- max_fails/fail_timeout 提供基础健康检查，失败后自动摘除节点
- keepalive 32; 复用后端连接，大幅降低微服务侧 TCP 建连压力
- proxy_next_upstream error timeout http_502 http_503 可自动重试，提升请求成功率
路由能力满足业务级流量分发需求
微服务按域拆分，Nginx 能在接入层完成初步分流，把压力留在边缘，不推给内部网关。
- 按路径前缀：location /api/order/ { proxy_pass https://www.php.cn/link/6ad70dd03e050325492decf70a0082b0; }
- 按 Header 或 Cookie 实现灰度：map $http_x_version $backend { default user_v1; "v2" user_v2; }，再 proxy_pass https://www.php.cn/link/7c677ff4c58e458338c5f7e74556735d;
- 按 Host 区分环境：if ($host ~* ^staging.) { set $upstream staging_backend; }
可观测性与高可用必须同步落地
没有监控的 Nginx 是黑盒，没有冗余的 Nginx 是单点。
- access_log 中加入 $upstream_addr 和 $upstream_response_time，能快速定位慢节点或转发异常
- 配合 nginx-vts-exporter 或 OpenResty 的 prometheus 模块，暴露 QPS、5xx 率、上游延迟等核心指标
- Keepalived 绑定 VIP 实现主备切换，两台 Nginx 构成最小高可用单元，避免入口瘫痪
- 不建议单机扛全量流量，应按业务域或区域部署多组 Nginx 集群，解耦风险
不复杂但容易忽略
