F5 NGINX Plus：负载均衡

HTTP 负载均衡

在对 HTTP 流量进行负载均衡时，NGINX Plus 会终止每个 HTTP 连接并单独处理每个请求。您可以去除 SSL/TLS 加密、检查并修改请求、使用速率限制功能排列请求，以及选择负载均衡策略。

为提高性能，NGINX Plus 可自动对 HTTP 事务进行各种优化，包括 HTTP 协议升级、长连接 (keepalive) 优化、内容压缩和响应缓存等转换。

使用 NGINX Plus 可轻松实现 HTTP 流量的负载均衡：

http {
    upstream my_upstream {
        server server1.example.com;
        server server2.example.com;
    }

    server {
        listen 80;
        location / {
            proxy_set_header Host $host;
            proxy_pass http://my_upstream;
        }
    }
}

首先使用 server 指令指定一台虚拟服务器，然后指定流量的 listen 端口。使用 location代码块匹配客户端请求的 URL，再使用 proxy_set_header 指令设置 Host请求头，并包含 proxy_pass 指令，然后将请求转发到上游组。（upstream代码块定义了 NGINX Plus 用来均衡流量的服务器。）

如需了解更多信息，请参阅使用 NGINX 和 NGINX Plus 进行负载均衡的相关介绍。

TCP 和 UDP 负载均衡

NGINX Plus 还能对 TCP 应用（如 MySQL）和 UDP 应用（如 DNS 和 RADIUS）进行负载均衡。对于 TCP 应用，NGINX Plus 会先终止 TCP 连接，然后创建新的连接到系统后端。

stream {
    upstream my_upstream {
        server server1.example.com:1234;
        server server2.example.com:2345;
    }

    server {
        listen 1123 [udp];
        proxy_pass my_upstream;
    }
}

此处的配置和针对 HTTP 的配置很相似：使用 server 指令指定虚拟服务器，再使用listen关键字指定流量端口，并使用proxy_pass将请求传至 upstream 组。

有关 TCP 和 UDP 负载均衡的更多信息，请参阅《NGINX Plus 管理指南》。

负载均衡的方式

NGINX Plus 为 HTTP、TCP 和 UDP 提供多种应用负载均衡方法。所有方法能够选择分配给每个上游服务器的流量权重。

• 轮询（Round Robin，默认使用）：在上游服务器之间按顺序分配请求。
• 最少连接数：将请求转发给活动连接数最少的服务器。
• 最少响应时间：根据响应时间和活跃连接数的综合计算结果，将请求转发给负载最少的服务器。NGINX Plus 的独有功能。
• 哈希 (Hash)：根据特定的键值（如客户端 IP 地址或请求 URL）分配请求。如果上游 (upstream) 服务器集群发生变化，NGINX Plus 可选择应用一致的哈希值，从而尽量避免重新分配负载。
• IP 哈希（仅限 HTTP）：根据客户端 IP 地址的前三个八位字节进行请求分配。
• Random with Two Choices：随机选择两台服务器，并将请求转发给活跃连接数较少的服务器（即“最少连接数”方法）。若使用 NGINX Plus，也可以支持“最少响应时间”方法。

使用 NGINX Plus 限制连接数

您可以限制 NGINX Plus 与上游 HTTP 或 TCP 服务器建立的连接数，或与 UDP 服务器建立的会话数。当与服务器的连接或会话数超过定义的限制时，NGINX Plus 就会停止建立新的连接或会话。

在下方的配置代码片段中，webserver1 的连接数限制为 250，webserver2 的连接数限制为 150。queue 指令指定了 NGINX Plus 放在操作系统监听队列中的多余连接数量上限，每个连接最多 30 秒；其他多余请求将被丢弃。

upstream backend {
    zone backends 64k;
    queue 750 timeout=30s;

    server webserver1 max_conns=250;
    server webserver2 max_conns=150;
}

当服务器上的活跃连接数低于其限制时，NGINX Plus 会从队列中向其发送连接。限制连接数有助于确保为客户端请求提供一致、可预测的服务，即使在流量激增时也能做到如此。

会话保持

您可以配置 NGINX Plus 以识别用户会话，并将会话中的所有请求发送到同一上游服务器。当应用服务器将状态存储在本地时，这一点至关重要——原因在于一旦将进行中的用户会话请求发送到其他服务器，就会出现严重错误。当应用在集群中共享信息时，会话保持有助于能提高性能。

除了 NGINX 开源版支持的基于哈希的会话保持（即“哈希”和“IP 哈希”两种负载均衡方法）外，NGINX Plus 还支持基于 Cookie 的会话保持，包括sticky cookie。NGINX Plus 会将会话 Cookie 添加到 upstream 组对指定客户端的第一个响应中，以安全识别发送响应的服务器。随后的客户端请求也会包含同样的 Cookie，NGINX Plus 会根据它将请求路由到同一上游服务器：

upstream backend {
    server webserver1;
    server webserver2;

    sticky cookie srv_id expires=1h domain=.example.com path=/;
}

在上方的示例中，NGINX Plus 在客户端的初始响应中插入了一个名为 srv_id 的 Cookie，以识别处理该请求的服务器。当后续请求包含该 Cookie 时，NGINX Plus 会直接将其转发给同一服务器。

NGINX Plus 还支持粘性学习 (sticky learn) 和粘性路由 (sticky rout) 会话保持方法。

注：基于 Cookie 的会话保持是 NGINX Plus 独有的功能。

主动健康检查

默认情况下，NGINX 会对上游服务器的响应执行基本检查，并尽可能重试失败的请求。NGINX Plus 增加了带外应用健康检查（也称为“合成事务”）和慢启动功能，可将新服务器和已恢复的服务器有序添加到负载均衡组中。

这些功能使 NGINX Plus 能够检测并解决更多问题，从而显著提高 HTTP 和 TCP/UDP 应用的可靠性。

upstream my_upstream {
	zone my_upstream 64k;
	server server1.example.com slow_start=30s;
}

server {
    # ...
    location /health {
        internal;
        health_check interval=5s uri=/test.php match=statusok;
        proxy_set_header Host www.example.com;
        proxy_pass http://my_upstream
    }
}

match statusok {
    # Used for /test.php health check
    status 200;
    header Content-Type = text/html;
    body ~ "Server[0-9]+ is alive";
}

在上方的示例中，NGINX Plus 每 5 秒就向 /test.php 发送一次请求。针对这些请求的响应必须满足 match 块中所定义的条件——即返回状态代码为 200 OK且响应正文包含文字”ServerN is alive”——上游服务器才会被认为是处于健康状态。

注：主动健康检查是 NGINX Plus 独有的功能。

使用 DNS 进行服务发现

默认情况下，NGINX Plus 服务器会在启动时解析 DNS 名称，并持久地缓存解析值。当您使用域名（如 example.com）以及server 指令和 resolve 参数来识别一组上游服务器时，NGINX Plus 会定期重新解析域名。如果关联的 IP 地址列表发生变化，NGINX Plus 会立即开始在更新后的服务器组之间进行负载均衡。

要想配置 NGINX Plus 来使用 DNS SRV 记录，请在 server 指令中加入resolver 指令和 service=http 参数，如下所示：

resolver 127.0.0.11 valid=10s;

upstream service1 {
    zone service1 64k;
    server service1 service=http resolve;
}

在上方的示例中，NGINX Plus 每 10 秒查询 127.0.0.11（内置 Docker DNS 服务器）一次，以重新解析域名 service1。

注：使用 DNS 进行服务发现是 NGINX Plus 独有的功能。

NGINX Plus API

NGINX Plus 包含一个具有单一 API 端点的 RESTful API。使用 NGINX Plus API可即时更新上游配置和键值存储，实现零停机时间。

以下配置的代码片段包含 api 指令，以启用对 /api 端点的读写访问。

upstream backend {
    zone backends 64k;
    server 10.10.10.2:220 max_conns=250;
    server 10.10.10.4:220 max_conns=150;
}

server {
    listen 80;
    server_name www.example.org;

    location /api {
        api write=on;
    }
}

在上方示例启用 API 后，可使用以下 curl 命令向现有 upstream 组添加新服务器。该命令使用 POST 方法和 JSON 编码，将服务器的 IP 地址设为 192.168.78.66，权重设为 200，最大同时连接数设为 150。（对于 version 的位置，请用参考文档中指定的 API 最新版本号代替）。

$ curl -iX POST -d '{"server":"192.168.78.66:80","weight":"200","max_conns":"150"}' http://localhost:80/api/version/http/upstreams/backend/servers/

要以 JSON 格式显示所有后端上游服务器的完整配置，则运行：

$ curl -s http://localhost:80/api/version/http/upstreams/backend/servers/ | python -m json.tool
	{
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 0,
      "max_conns": 250,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.2:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 1,
      "max_conns": 150,
      "max_fails": 1,
      "route": "",
      "server": "10.10.10.4:220",
      "slow_start": "0s",
      "weight": 1
      },
      {
      "backup": false,
      "down": false,
      "fail_timeout": "10s",
      "id": 2,
      "max_conns": 200,
      "max_fails": 1,
      "route": "",
      "server": "192.168.78.66:80",
      "slow_start": "0s",
      "weight": 200
      }

要修改现有上游服务器的配置，请使用其内部 ID 进行标识，该 ID 显示在上述输出中的 id 字段中。以下命令使用 PATCH 方法，以 ID 2 重新配置服务器，将其 IP 地址和监听端口设置为 192.168.78.55:80，权重设置为 500，连接限制设置为 350。

$ curl -iX PATCH -d '{"server":"192.168.78.55:80","weight":"500","max_conns":"350"}' http://localhost:80/api/version/http/upstreams/backend/servers/2

您可以访问 NGINX Plus API 的完整 Swagger（OpenAPI 规范）文档：https://demo.nginx.com/swagger-ui/。

注：NGINX Plus API 为 NGINX Plus 的独有功能。