Nginx在云原生中作为轻量API网关，专注反向代理与流量入口管理；通过独立upstream、路径剥离、map动态路由、内置限流/CORS/HTTPS及K8s协同实现稳定高效治理。
Nginx 在云原生架构中担任 API 网关核心组件，关键不在于替代专业网关（如 Kong、Spring Cloud Gateway），而在于用好它原生、稳定、低开销的反向代理能力，精准承接微服务流量入口职责。它适合中小规模、快速落地或作为边缘网关/区域网关使用，尤其在 Kubernetes Ingress 能力不足、需更细粒度控制时，Nginx 配置即代码的方式反而更直接可控。
独立 upstream + 路径剥离：构建可维护的路由骨架
每个微服务必须定义专属 upstream 块，而非把后端地址硬写进 location。这样后续加健康检查（max_fails, fail_timeout）、换负载策略（least_conn, ip_hash）或切灰度流量（split_clients 或 map 变量）都不用动路由逻辑。
proxy_pass 末尾斜杠是路径处理的分水岭：
-
proxy_pass http://user-svc/;→/api/users/list被剥离前缀，转发为/list -
proxy_pass http://user-svc;→ 同样请求转发为/api/users/list，后端需匹配完整路径
漏掉这个斜杠是 404 的高频原因。
多维动态路由：支撑版本、租户与环境隔离
云原生场景常需按路径版本（/v1/users）、请求头（X-Tenant-ID）、或查询参数（?env=staging）分流。Nginx 通过 map 指令提前映射变量，再结合 upstream 名称动态拼接，实现零重启切换：
map $request_uri $backend {
~^/v1/.* user-svc-v1;
~^/v2/.* user-svc-v2;
default user-svc-stable;
}
upstream $backend { ... } # 注意：需配合 stream 模块或 use nginx-plus 才支持变量 upstream更通用的做法是用 rewrite 提取路径段 + set 变量 + 多个固定 upstream 分支，兼顾兼容性与清晰度。
轻量级治理能力：限流、CORS、HTTPS 全在配置里完成
- 限流：
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s定义规则，limit_req zone=perip burst=20 nodelay应用到 location，无需 Redis 或外部依赖（高并发下建议配 Redis 后端做分布式限流） - CORS：直接
add_header 'Access-Control-Allow-Origin' '*'，生产环境替换为白名单域名，配合Access-Control-Allow-Methods和Access-Control-Allow-Headers - HTTPS 强制跳转：
return 301 https://$host$request_uri;放在 80 server 块内，简单有效
与云原生生态协同：不取代，但补位
Nginx 不自带服务发现，但在 Kubernetes 中可通过以下方式联动：
- 使用
nginx-ingress-controller（官方维护的 Ingress Controller），自动同步 Service/Ingress 资源 - 自研脚本监听 Endpoints 变化，生成 upstream 配置并热重载（
nginx -s reload） - 在 Istio 等服务网格中，Nginx 可作为边缘网关（Edge Gateway），承接南北向流量，把东西向交给 Sidecar 处理
它不解决所有问题，但把最常发生的路径转发、基础防护、协议终止这些事，做得足够稳、足够快、足够透明。
