Nginx 中如何利用 Nginx 进行多业务场景负载配置-Nginx-PHP中文网

nginx 多业务负载核心是“分而治之”，按域名或路径分离流量至不同 upstream，结合请求特征（如 uri、user-agent）精细化路由，并为各业务匹配合适负载算法（轮询、ip_hash、least_conn等），辅以独立健康检查与降级能力。

nginx 中如何利用 nginx 进行多业务场景负载配置

Nginx 做多业务场景负载配置，关键不是堆策略，而是按业务特性“分而治之”——把不同业务流量拆开、隔离、定向分发。同一套 Nginx 实例完全可以支撑多个业务（如官网、API 服务、后台管理、静态资源），只需在 upstream 和 location 层级做合理划分。

按业务域名或路径做流量分离
这是最常用也最清晰的方式。不同业务用不同 server 块或同一 server 下不同 location 区分：

官网（www.example.com）→ 转发到 frontend_pool
API（api.example.com 或 /api/）→ 转发到 api_pool
后台系统（admin.example.com）→ 转发到 admin_pool
静态资源（/static/、/img/）→ 可直接本地 serve，或转发到 cdn_pool

示例配置片段：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

http {
    upstream frontend_pool {
        server 192.168.1.10:8080;
        server 192.168.1.11:8080;
    }
    upstream api_pool {
        server 192.168.1.20:3000 weight=2;
        server 192.168.1.21:3000 weight=1;
        ip_hash;  # API 若需登录态保持（如 JWT cookie 不跨节点校验），可启用
    }
    upstream admin_pool {
        server 192.168.1.30:8000;
        # 加 max_fails/fail_timeout，后台系统更敏感，需快速剔除故障节点
        server 192.168.1.31:8000 max_fails=2 fail_timeout=15s;
    }

    server {
        listen 80;
        server_name www.example.com;
        location / {
            proxy_pass http://frontend_pool;
            proxy_set_header Host $host;
        }
    }

    server {
        listen 80;
        server_name api.example.com;
        location / {
            proxy_pass http://api_pool;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }

    server {
        listen 80;
        server_name admin.example.com;
        location / {
            proxy_pass http://admin_pool;
            proxy_set_header Host $host;
        }
    }
}

按请求特征做精细化路由
对同一域名下的混合流量，可通过 location + 正则或 map 模块实现分流：

/api/v1/order/ → 订单服务集群（order_pool）
/api/v1/user/ → 用户服务集群（user_pool）
/healthz → 直接返回 200，不转发（健康探针）
User-Agent: mobile → 转发到 mobile_frontend_pool

简单示例：

map $request_uri $backend {
    ~^/api/v1/order/     order_pool;
    ~^/api/v1/user/      user_pool;
    default              api_pool;
}

upstream order_pool { server 192.168.1.40:8081; }
upstream user_pool  { server 192.168.1.41:8082; }

location /api/ {
    proxy_pass http://$backend;
}

为不同业务匹配合适的负载算法
不能所有 upstream 都用轮询。要结合业务状态和后端能力选策略：