nginx扩展集群转发逻辑的核心是合理利用upstream模块、lua脚本和动态resolver，而非编写新模块；通过upstream配置负载策略（如ip_hash、weight）、access_by_lua_block动态选上游、resolver实现dns动态解析，并避免将复杂业务逻辑置于nginx层。
在 Nginx 中扩展集群转发逻辑，核心不是“写模块”，而是合理利用现有官方模块与配置能力，结合少量定制逻辑（如 Lua 或动态 resolver），实现灵活、可控、可维护的集群路由策略。
用 upstream + 自定义负载均衡策略 实现基础集群转发
Nginx 原生 upstream 模块已支持多种负载均衡方式（round-robin、least_conn、ip_hash、hash 等），配合 server 指令的权重、max_fails、fail_timeout 等参数，可满足多数集群场景。关键在于根据业务特征选择合适策略：
- 需会话保持 → 用
ip_hash或hash $cookie_session_id consistent - 后端节点性能差异大 → 显式设置
weight，例如server 10.0.1.10:8080 weight=3; - 服务健康依赖主动探测 → 配合
health_check（需启用 stream 或 http 模块的 health check 功能）或第三方模块如 nginx_upstream_check_module
用 ngx_http_lua_module 注入动态转发逻辑
当静态 upstream 无法满足需求（如按请求头灰度路由、按用户 ID 分片、调用外部鉴权服务后再选节点），Lua 是最轻量、高兼容的扩展方式：
- 安装时需编译含 lua-nginx-module（OpenResty 默认集成，原生 Nginx 需手动添加）
- 在
location中用access_by_lua_block或rewrite_by_lua_block修改$upstream_addr或$proxy_host，再通过proxy_pass http://$backend动态转发 - 示例：根据 header 中的 region 选择上游集群
access_by_lua_block {
if ngx.var.http_region == "cn" then
ngx.var.backend = "backend_cn"
elseif ngx.var.http_region == "us" then
ngx.var.backend = "backend_us"
else
ngx.var.backend = "backend_default"
end
}
proxy_pass http://$backend;
用 resolver + 变量域名 支持服务发现式集群
当后端节点由注册中心（如 Consul、Nacos、Kubernetes Service）动态管理时，避免硬编码 IP，改用 DNS 解析 + 变量：
- 配置
resolver（推荐使用集群内 DNS，如 kube-dns 或 CoreDNS） - 将 upstream server 替换为变量形式，例如
proxy_pass http://$upstream_service; - 配合
proxy_next_upstream和重试机制，提升 DNS 变更后的容错性 - 注意：Nginx 默认缓存 DNS 结果，可通过
resolver ... valid=5s;控制 TTL，避免节点变更延迟
避免常见误区：不是所有逻辑都该放 Nginx 层
过度依赖 Nginx 做复杂路由或状态判断，会降低可测试性与可观测性：
- 需要频繁更新的规则（如 AB 测试流量比例）→ 推荐下沉到网关层（如 Envoy、Spring Cloud Gateway）或业务侧
- 涉及多步外部调用（如查 DB、调 API）→ Nginx 不适合做协调者，应由前置服务统一处理
- 日志与链路追踪需透传 → 确保
proxy_set_header正确传递 trace-id、user-id 等字段
