Nginx Upstream 详解：负载均衡与反向代理核心

在现代高并发、高可用的互联网应用架构中，Nginx 凭借其卓越的性能和灵活的配置，已成为事实上的标准 Web 服务器、反向代理服务器和负载均衡器。无论您是搭建简单的网站、复杂的微服务架构，还是构建 API 网关，Nginx 都扮演着至关重要的角色。而 Nginx 实现反向代理和负载均衡的核心机制，正是其强大的 upstream 模块。

本文将深入探讨 Nginx 的 upstream 模块，详细解析其在构建高性能、可伸缩的应用程序架构中所扮演的关键角色，以及如何利用它来实现反向代理和各种负载均衡策略。

1. 什么是 Nginx Upstream？

简单来说，upstream 在 Nginx 配置中定义了一组后端服务器（Backends）。这些后端服务器可以是运行应用程序的 Web 服务器（如 Apache, Tomcat, Node.js 应用）、应用服务器、数据库服务器，或者是任何能够响应网络请求的服务。Nginx 作为客户端接收到请求后，会根据配置将这些请求转发给 upstream 中定义的某个或某组后端服务器进行处理。

upstream 块通常定义在 Nginx 配置文件的 http 块内，用于指定一个或多个后端服务器的地址和相关参数。其基本语法结构如下：

“`nginx
http {
# … 其他 http 配置 …

upstream backend_servers {
    # 在这里定义一组后端服务器
    server backend1.example.com:8080;
    server backend2.example.com:8080;
    server 192.168.1.100:9000;
    # ... 还可以添加更多 server 指令 ...

    # 还可以配置负载均衡方法和 upstream 级别的参数
    # load_balance_method;
    # upstream_parameter;
}

# ... 其他 http 配置 ...

}
“`

这里的 backend_servers 是您为这组后端服务器指定的名称，这个名称可以在 Nginx 的 server 或 location 块中使用，通过 proxy_pass 或其他代理指令引用。

server 指令是 upstream 块中最基本的组成部分，用于定义一个具体的后端服务器。它的基本格式是 server address [parameters];，其中 address 可以是域名或 IP 地址，后面跟可选的端口号。如果没有指定端口，则默认使用 80 端口。parameters 用于配置该服务器在负载均衡组中的权重、状态、连接限制等属性，我们将在后面详细介绍。

upstream 的核心价值在于：

抽象后端服务： 它将一组提供相同服务的后端服务器抽象为一个逻辑单元。前端 Nginx 只需知道这个单元的名称，而无需关心具体是哪台服务器在处理请求。这使得后端服务器可以灵活地进行增加、移除或替换，而无需修改前端 Nginx 的代理配置。
负载均衡的基础： upstream 块是实现负载均衡的前提。当 upstream 中定义了多个 server 时，Nginx 可以使用不同的算法将客户端请求分发到这些服务器上。
实现反向代理： upstream 定义了请求最终要被转发到的目的地。通过 proxy_pass 指令引用 upstream 名称，Nginx 就能将接收到的客户端请求透明地转发给后端服务器，并将后端服务器的响应返回给客户端。

2. Nginx 作为反向代理的核心

在理解 upstream 之前，通常会先接触到 Nginx 的反向代理功能。反向代理位于客户端和后端服务器之间，客户端发送请求到反向代理，反向代理再将请求转发给内部网络的后端服务器，并将后端服务器的响应返回给客户端。

为什么需要反向代理？

安全性： 隐藏后端服务器的真实 IP 地址和结构，保护内部网络。
负载均衡： 将请求分发到多个后端服务器，提高系统的处理能力。
SSL/TLS 卸载： 在反向代理层处理 SSL/TLS 加密解密，减轻后端服务器的负担。
缓存： 缓存静态资源或动态响应，加速访问速度。
压缩： 压缩响应数据，节省带宽。
统一入口： 为客户端提供一个单一的访问入口，简化客户端配置。
高可用性： 当某个后端服务器故障时，反向代理可以将请求转发到其他健康的服务器。

在 Nginx 中配置反向代理，通常会使用 server 和 location 块来匹配请求，然后使用 proxy_pass 指令将请求转发出去。

“`nginx
server {
listen 80;
server_name example.com;

location /app/ {
    # 将匹配到 /app/ 的请求转发到后端服务
    proxy_pass http://localhost:8080;
    # 或者转发到一个 upstream 块定义的后端组
    # proxy_pass http://backend_servers;

    # 常用代理头设置，转发客户端信息给后端
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

# ... 其他 location 块 ...

}
“`

proxy_pass 与 upstream 的结合：

proxy_pass 指令是实现转发的核心。它可以直接指向一个后端服务器地址（如 http://localhost:8080），也可以指向一个 upstream 块定义的后端服务器组名称（如 http://backend_servers）。

当 proxy_pass 指向一个 upstream 名称时，Nginx 会根据该 upstream 块中配置的负载均衡策略，从后端服务器组中选择一个服务器来处理当前请求。这是 upstream 模块在反向代理中发挥作用的关键点——它为 proxy_pass 提供了一个可供选择的后端服务器池，进而实现负载均衡。

示例：

“`nginx
http {
upstream my_backend_app {
server 192.168.1.10:80;
server 192.168.1.11:80;
server 192.168.1.12:80;
}

server {
    listen 80;
    server_name myapp.example.com;

    location / {
        proxy_pass http://my_backend_app; # 将请求转发到 my_backend_app upstream

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

}
“`

在这个例子中，所有发往 myapp.example.com 的请求都会被 Nginx 接收，然后根据 my_backend_app 这个 upstream 块的配置，被转发到 192.168.1.10、192.168.1.11 或 192.168.1.12 这三台服务器之一。默认情况下，Nginx 会使用轮询（Round Robin）的方式在三台服务器之间分发请求。

3. Nginx Upstream 实现负载均衡

负载均衡是 Nginx 的一个核心功能，它通过将客户端请求分发到多台后端服务器，达到提高系统可用性、可伸缩性和性能的目的。当一个后端服务器组（upstream）中有多个服务器时，Nginx 就需要决定将每个新的请求发送给哪台服务器。这个决定过程就是负载均衡算法的作用。

Nginx 提供了多种内置的负载均衡算法，可以通过在 upstream 块中指定相应的指令来选择。

3.1 内置负载均衡方法 (Nginx Open Source)

3.1.1 轮询 (Round Robin) – 默认

这是 Nginx upstream 的默认负载均衡方法。它将请求按顺序循环分配到后端服务器列表中的每一台服务器，直到列表末尾，然后再从头开始。

优点： 配置简单，易于理解，适用于后端服务器性能相近、无特殊需求的场景。
缺点： 不考虑后端服务器的实际负载或响应时间，可能导致某些请求量大的服务器过载。

配置示例： 无需额外指令，只需列出服务器即可。

nginx upstream backend_servers { server 192.168.1.10; server 192.168.1.11; server 192.168.1.12; }
（请求会依次发往 .10 -> .11 -> .12 -> .10 -> …）

3.1.2 加权轮询 (Weighted Round Robin)

加权轮询允许您为 upstream 中的每台服务器指定一个权重（weight）。权重越高的服务器，被分配到请求的概率也越大。这适用于后端服务器性能不一致的场景，可以将更多的请求分配给性能更强的服务器。

优点： 可以根据服务器的处理能力进行流量分配，更合理地利用资源。
缺点： 仍然是基于请求数量的分配，不直接考虑服务器的实时负载。

配置示例： 使用 weight 参数。

nginx upstream backend_servers { server 192.168.1.10 weight=5; # 这台服务器将获得 5 份请求 server 192.168.1.11 weight=2; # 这台服务器将获得 2 份请求 server 192.168.1.12 weight=3; # 这台服务器将获得 3 份请求 server 192.168.1.13; # 默认权重为 1 }
（在每 11 个请求中，约有 5 个发往 .10，2 个发往 .11，3 个发往 .12，1 个发往 .13）

3.1.3 IP Hash

IP Hash 算法根据客户端的 IP 地址计算出一个哈希值，并将同一个客户端 IP 的请求始终转发到同一台后端服务器。这对于需要保持会话（session persistence）的应用非常有用，例如某些不使用共享存储的购物车应用。

优点： 保证同一客户端的请求始终发往同一服务器，解决会话保持问题。
缺点： 如果客户端 IP 范围不均衡（例如所有请求都来自同一个大型 NAT 后），可能导致负载不均衡。后端服务器故障时，受影响的客户端将无法访问，直到服务器恢复或被标记为 down。

配置示例： 在 upstream 块中添加 ip_hash; 指令。

nginx upstream backend_servers { ip_hash; server 192.168.1.10; server 192.168.1.11; server 192.168.1.12; }

注意： 如果使用 IP Hash，当有服务器需要移除时，应该先将其标记为 down (如 server 192.168.1.12 down;)，然后在 Nginx Reload 或 Restart 后再彻底移除，以尽量减少对受影响客户端会话的影响。添加新服务器通常没有这个问题。

3.1.4 最少连接 (Least Conn)

最少连接算法将请求发送到当前活动连接数最少的后端服务器。这是一种更动态的负载均衡方法，因为它考虑了服务器的实时状态（连接数）。

优点： 更倾向于将请求分配给当前负载较低的服务器，有助于均衡服务器的连接压力。
缺点： 不直接考虑请求的处理时间，连接数少不代表处理能力强或响应速度快。

配置示例： 在 upstream 块中添加 least_conn; 指令。

nginx upstream backend_servers { least_conn; server 192.168.1.10; server 192.168.1.11; server 192.168.1.12; }

3.2 Nginx Plus 提供的负载均衡方法

Nginx Plus（商业版）提供了更多高级的负载均衡方法，这些方法在处理复杂应用和高流量场景时更加强大和灵活。

Least Time (最少时间): 将请求发送到平均响应时间最短且连接数最少的服务器。这是一种非常有效的负载均衡方法，因为它同时考虑了服务器的响应速度和当前负载。
Random (随机): 随机选择一个服务器。可以结合 least_conn 或 least_time 参数，在随机选择的两个服务器中选择连接数或响应时间最少的那个。
Generic Hash (通用哈希): 根据用户指定的键（文本、变量或它们的组合）来计算哈希值，然后将请求发送到对应的服务器。比 IP Hash 更灵活，可以基于 Cookie、URI 参数等进行哈希，用于更精细的会话保持或其他基于内容的路由。

这些高级方法不在标准的 Nginx Open Source 版本中，如果需要使用，需要考虑 Nginx Plus。

4. Upstream Server 参数详解

除了基本的地址和端口，server 指令还支持一系列参数，用于更精细地控制服务器在 upstream 组中的行为。这些参数大大增强了 Nginx 负载均衡的灵活性和可靠性。

nginx upstream backend_servers { server address [parameters]; # ... more servers ... }

常用的 server 参数包括：

weight=number: 设置服务器的权重，默认为 1。权重越高，被分配到的请求越多（主要用于加权轮询）。
nginx server 192.168.1.10 weight=10; server 192.168.1.11 weight=1;
max_fails=number: 在 fail_timeout 时间段内，如果与服务器通信失败的次数达到 number 次，则将该服务器标记为不可用。默认为 1。设置为 0 则不进行健康检查（不基于失败次数标记为 down）。这里的失败通常指连接不上、发送请求失败或没有收到响应头部。
nginx server 192.168.1.10 max_fails=3;
fail_timeout=time:
- 当服务器在 fail_timeout 时间内失败次数达到 max_fails 时，该服务器将被标记为不可用，持续时间为 fail_timeout。
- 如果服务器被标记为不可用，Nginx 会在 fail_timeout 时间后尝试重新连接它。
  默认值为 10 秒。
  nginx server 192.168.1.10 max_fails=3 fail_timeout=20s; # 20秒内失败3次则标记为down 20秒
backup: 将服务器标记为备份服务器。当所有非 backup 服务器都不可用时，请求才会被发送到 backup 服务器。这对于提供基本的备用服务非常有用。
nginx server 192.168.1.10; # 主服务器组 server 192.168.1.11; server 192.168.1.12 backup; # 备份服务器
down: 将服务器标记为永久不可用。通常用于临时维护，可以在不删除配置的情况下将服务器移除出负载均衡列表。
nginx server 192.168.1.10; server 192.168.1.11 down; # 暂时移除这台服务器 server 192.168.1.12;
max_conns=number: (Nginx Plus 特性) 限制与服务器的最大并发连接数。当达到限制时，请求将被转发到其他服务器或排队等待。
resolve: (Nginx Plus 特性或需要 Resolver 配置) 允许 Nginx 动态解析服务器的域名，而不是在启动或 Reload 时静态解析。这对于后端服务器地址经常变化（例如在云环境或容器化环境中）非常有用。需要配合 resolver 指令使用。
route="string": (Nginx Plus 特性) 为服务器定义一个路由字符串，可以与 proxy_set_header X-Route $upstream_route; 等配合使用，用于更复杂的路由逻辑。
drain: (Nginx Plus 特性) 在 Nginx Plus R12 及以后版本可用。用于实现优雅下线。当一个服务器被标记为 drain 时，新的请求不会再发往这台服务器，但已有的连接会继续处理，直到连接关闭。这允许服务器完成当前任务后安全退出。

5. Upstream 健康检查

保障后端服务器的健康是负载均衡有效性的关键。Nginx 提供了两种健康检查方式：被动健康检查和主动健康检查。

被动健康检查 (Passive Health Checks): 这是 Nginx Open Source 版本内置的功能，通过 max_fails 和 fail_timeout 参数来实现。Nginx 会记录与后端服务器通信失败的次数。如果在指定时间内失败次数达到上限，Nginx 就认为该服务器不健康，并在 fail_timeout 指定的时间内不再向其发送请求。时间到后，Nginx 会尝试向该服务器发送一个请求，如果成功则恢复该服务器，否则继续标记为 down。这种方式简单有效，但它是“被动”的，只有在Nginx尝试连接服务器并失败后才会触发。
主动健康检查 (Active Health Checks): 这是 Nginx Plus 提供的功能。Nginx Plus 会定期（独立于客户端请求）向后端服务器发送特定的健康检查请求（例如发送 HTTP 请求到指定的 URL，检查响应状态码或内容）。如果服务器未能在规定时间内响应或响应不符合预期，Nginx Plus 会将该服务器标记为不健康。主动健康检查提供了更及时、更灵活的健康状态监控，可以更早地发现并隔离故障服务器。

对于 Nginx Open Source 用户，理解 max_fails 和 fail_timeout 的作用至关重要，合理配置它们可以有效处理后端服务器的暂时性故障。

示例 (结合 max_fails 和 fail_timeout):

nginx upstream backend_servers { server 192.168.1.10:8080 weight=5 max_fails=3 fail_timeout=15s; server 192.168.1.11:8080 weight=5 max_fails=3 fail_timeout=15s; server 192.168.1.12:8080 backup; # 备份服务器不进行max_fails/fail_timeout检查 (默认行为，除非明确指定) }
这个配置意味着，如果在 15 秒内，与 192.168.1.10 或 192.168.1.11 的通信失败了 3 次，Nginx 会将这台服务器标记为 down，并在接下来的 15 秒内不再向其发送请求。15 秒后，Nginx 会再次尝试连接它。

6. Upstream 与其他 Nginx 功能的结合

upstream 模块与 Nginx 的其他核心功能紧密结合，共同构建强大的应用交付平台。

proxy_set_header: 在转发请求到 upstream 服务器时，通常需要设置一些 HTTP 头部，以便后端服务器能够获取客户端的真实信息（如客户端 IP、Host、协议等）。这些通过 proxy_set_header 指令在 location 或 server 块中配置，作用于发往 upstream 的请求。
nginx proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache: Nginx 的缓存功能可以显著提高应用的响应速度并减轻后端负载。proxy_cache 配置在 http、server 或 location 块中，用于缓存从 proxy_pass 指向的 upstream 服务器获取的响应。
“`nginx
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=10g
inactive=60m use_temp_path=off;

server {
# …
location /static/ {
proxy_pass http://static_backend;
proxy_cache my_cache;
proxy_cache_valid 200 302 10m; # 缓存状态码200和302的响应10分钟
# …
}
}
“`
SSL/TLS 终止: Nginx 可以在反向代理层处理客户端与 Nginx 之间的 SSL/TLS 加密连接，将解密后的请求转发给后端服务器。这减轻了后端服务器的加密/解密负担。配置通常在 server 块中使用 listen 443 ssl; 和 ssl_certificate、ssl_certificate_key 等指令实现。转发给后端时，如果后端使用 SSL，proxy_pass 可以使用 https:// 协议，并且可能需要配置 proxy_ssl_server_name on; 等参数。
超时设置: Nginx 与后端服务器之间的通信有多种超时设置，这些参数通常在 location 或 server 块中与 proxy_pass 一起使用：
- proxy_connect_timeout: Nginx 尝试与后端服务器建立连接的超时时间。
- proxy_send_timeout: Nginx 向后端服务器发送请求的超时时间。
- proxy_read_timeout: Nginx 等待后端服务器发送响应的超时时间。
  合理配置这些超时时间对于防止慢连接或无响应的后端服务器阻塞 Nginx 至关重要。
keepalive: 在 upstream 块中使用 keepalive 指令可以启用 Nginx 与后端服务器之间的持久连接。Nginx 会维护一定数量的空闲长连接，当有新请求到来时，可以直接复用这些连接，而不是重新建立连接。这可以减少连接建立的开销，提高性能，尤其是在请求量大且后端服务器支持 Keep-Alive 时效果显著。
nginx upstream backend_servers { server 192.168.1.10:8080; server 192.168.1.11:8080; keepalive 64; # 在每个 worker 进程中保持最多 64 个空闲的到 upstream 服务器的连接 }

7. 配置最佳实践与注意事项

有意义的 upstream 名称： 使用描述性的名称来命名 upstream 块，例如 app_backends、api_servers、static_assets，以便于理解配置。
正确设置 proxy_set_header： 确保将客户端的真实 IP、Host、协议等信息通过 HTTP 头部正确传递给后端服务器，这对于后端日志记录、请求路由、安全控制以及应用逻辑（如生成正确的回调 URL）至关重要。
合理配置超时： 根据后端服务器的响应时间和网络状况，合理设置 proxy_connect_timeout、proxy_send_timeout 和 proxy_read_timeout。太短可能导致正常请求失败，太长可能导致 Nginx 进程被阻塞。
考虑健康检查： 即使使用 Open Source 版本的被动健康检查，也要根据实际情况调整 max_fails 和 fail_timeout 参数。监控 Nginx 的错误日志，关注与 upstream 服务器通信相关的错误。对于生产环境，如果预算允许，Nginx Plus 的主动健康检查提供了更好的可用性保障。
使用 down 进行维护： 在需要临时移除某个后端服务器进行维护时，使用 down 参数比直接删除配置更方便，维护完成后去掉 down 即可恢复。
IP Hash 的会话保持与服务器变更： 如果依赖 IP Hash 进行会话保持，移除服务器时务必先标记为 down 再移除，以降低对用户会话的影响。增加服务器通常没有问题。
监控： 结合 Nginx 的日志和监控工具（如 Nginx Plus 的实时监控面板、Prometheus + Nginx Exporter 等），监控 upstream 服务器的状态、连接数、请求延迟等指标，及时发现并解决问题。
平滑重启/重载： 修改 Nginx 配置后，优先使用 nginx -s reload 进行平滑重载，而不是 nginx -s restart。重载会加载新的配置但保持原有 worker 进程继续处理请求，直到新的 worker 进程启动并接管连接，从而避免服务中断。

8. 总结

Nginx 的 upstream 模块是构建高性能、高可用、可伸缩 Web 应用架构的基石。它通过定义后端服务器组，并结合灵活的负载均衡算法和丰富的服务器参数，使得 Nginx 能够高效地将客户端请求分发到多个后端服务器，实现反向代理和负载均衡的核心功能。

理解 upstream 的工作原理及其与 proxy_pass 指令的结合，掌握各种负载均衡方法的适用场景，并合理配置服务器参数和健康检查，是充分发挥 Nginx 强大能力的必经之路。无论是优化性能、提升可用性，还是简化架构管理，upstream 模块都扮演着举足轻重的角色。通过深入学习和实践 upstream 的各种配置，您可以构建出更加健壮和高效的应用系统，应对不断增长的流量和业务需求。

希望本文能帮助您全面理解 Nginx Upstream 及其在负载均衡和反向代理中的核心作用。