Nginx 多业务负载核心是“分而治之”，按域名或路径分离流量至不同 upstream，结合请求特征（如 URI、User-Agent）精细化路由，并为各业务匹配合适负载算法（轮询、ip_hash、least_conn等），辅以独立健康检查与降级能力。
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
示例配置片段：
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 都用轮询。要结合业务状态和后端能力选策略：
- 官网前端（无状态、静态为主）→ 轮询或加权轮询（若服务器配置不均）
- 用户中心（含 session 或登录态）→ ip_hash 或 sticky cookie（需 nginx plus 或第三方模块）
- 订单/支付类强一致性服务 → least_conn（连接数少的优先，适合长连接或耗时操作）
- 批量任务接口（如导出、报表）→ 可单独设低权重或限流 upstream，避免挤占主业务资源
配套保障：健康检查与降级能力
多业务共存时，单个 upstream 故障不能影响其他业务：
- 每个 upstream 独立配置 max_fails/fail_timeout，避免误剔
- 关键业务（如支付）可配 backup 服务器，主池全挂时自动切备用
- 配合 nginx 的 stub_status 或 prometheus exporter，按 upstream 统计成功率、延迟，便于监控告警
不复杂但容易忽略。
