NGINX Plus与Microsoft Azure负载均衡器

NGINX | 2021年6月25日

［编辑注：本文已更新，以反映截至2021年6月NGINX Plus和Azure负载均衡服务所支持的功能。本文还提及了NGINX Plus API，该API取代了原文中提到的独立动态配置模块，后者现已弃用。］

使用Microsoft Azure的客户有三种负载均衡方案：NGINX Plus、Azure负载均衡服务，或将NGINX Plus与Azure负载均衡服务结合使用。本文旨在提供充分的信息，帮助您做出选择，并介绍如何结合使用NGINX Plus和Azure Load Balancer，构建具备丰富第7层功能的高可用HTTP负载均衡器。

概述

Microsoft Azure为用户提供两种负载均衡器选择：Azure Load Balancer用于基本的TCP/UDP负载均衡（在第4层，即网络层），Azure Application Gateway用于HTTP/HTTPS负载均衡（在第7层，即应用层）。这些解决方案虽然适用于简单的使用场景，但缺少NGINX Plus标配的许多功能。

以下是NGINX Plus与Azure负载均衡产品的总体比较：

功能	NGINX Plus	Azure Load Balancer	Azure Application Gateway	NGINX Plus与Azure Load Balancer
HTTP和HTTPS负载均衡	✅	❌	✅	✅
HTTP/2负载均衡	✅	❌	✅	✅
WebSocket负载均衡	✅	❌	✅	✅
TCP/UDP负载均衡	✅	✅	❌	✅
负载均衡方法	高级	简单	简单	高级
会话持久性	高级	简单	简单	高级
HTTP健康检查	高级	简单	简单	高级
TCP/UDP健康检查	高级	简单	❌	高级
SSL/TLS终止	✅	❌	✅	✅
速率和连接限制	✅	❌	❌	✅
URL重写和重定向	✅	❌	✅	✅
URL请求映射	✅	❌	✅	✅
主动-主动NGINX Plus集群	❌	❌	❌	✅

下面来了解一下NGINX Plus与Azure负载均衡服务之间的部分差异、各自的独特功能，以及NGINX Plus如何与Azure负载均衡器协同工作。

NGINX Plus 与 Azure 负载均衡服务对比

负载均衡方法

除默认的轮询方法外，NGINX Plus还提供多种负载均衡方法供您选择：

最少连接，每个请求都会发送到活动连接数最少的服务器。
最短时间，每个请求都会发送到评分最低的服务器。该评分根据平均延迟和活动连接数的加权组合计算得出。
IP 哈希：每个请求都会发送到根据该请求的源IP地址确定的服务器。
通用哈希，每个请求都会发送到由用户定义的键确定的服务器。该键可以包含文本和NGINX 变量的任意组合，例如与源 IP 地址和源 端口标头字段或URI对应的变量。
随机，每个请求都会发送到随机选择的服务器。当包含two参数时，NGINX Plus会随机选择两台服务器，然后根据配置使用最少连接算法（默认）或最短时间算法从中选择一台。

通过为每台后端服务器分配不同的权重值，可以扩展所有这些方法。有关这些方法的详细信息，请参阅《NGINX Plus 管理指南》。

Azure Load Balancer提供一种负载均衡方法，即哈希。默认情况下，该方法使用基于源 IP 地址、源 端口、目标 IP 地址、目标 端口和协议标头字段的键来选择后端服务器。

Azure Application Gateway仅提供轮询方法。

会话持久性

会话持久性，也称为粘性会话或会话亲和性。当后端服务器之间不共享客户端状态，而应用要求将特定客户端的所有请求持续发送到同一台后端服务器时，就需要使用会话持久性。

NGINX Plus支持三种高级会话持久性方法：

Sticky Cookie：NGINX Plus会在上游组向指定客户端返回的第一个响应中添加会话Cookie。此Cookie用于标识处理该请求的后端服务器。客户端会在后续请求中包含此Cookie，NGINX Plus据此将客户端请求定向到同一台后端服务器。
Sticky Learn：NGINX Plus会监控请求和响应，以查找会话标识符（通常为Cookie），并据此确定同一会话中后续请求所使用的服务器。
Sticky Route：可以配置路由值与后端服务器之间的映射，使NGINX Plus能够监控请求中的路由值，并选择匹配的后端服务器。

NGINX Plus还提供两种基本的会话持久性方法，它们通过上述两种负载均衡方法实现：

IP 哈希，根据请求的 IP 地址确定后端服务器。
哈希：根据用户定义的键确定后端服务器，例如Source IP Address和Source Port，或URI。

Azure Load Balancer支持与NGINX Plus Hash方法等效的功能，但键仅限于特定组合，由Source IP Address、Source Port、Destination IP Address、Destination Port和Protocol标头字段组成。

Azure Application Gateway支持与NGINX Plus Sticky Cookie方法等效的功能，但存在以下限制：无法配置Cookie的名称、到期日期、域、路径，也无法配置HttpOnly或Secure Cookie属性。

注意：使用Azure Load Balancer、NGINX Plus IP Hash方法，或使用键中包含Source IP Address的NGINX Plus Hash方法时，只有客户端的IP地址在整个会话期间保持不变，会话持久性才能正常工作。但客户端的IP地址并非总能保持不变，例如，移动客户端从WiFi网络切换到蜂窝网络时。为确保请求继续发送到同一后端服务器，建议使用上文列出的一种高级会话持久性方法。

健康检查

Azure Load Balancer和Azure Application Gateway支持基本的应用运行状况检查。您可以指定负载均衡器请求的URL；如果收到预期的HTTP 200 返回代码，负载均衡器会将后端服务器视为运行状况良好。您可以指定运行状况检查频率，以及将服务器视为运行状况不佳前的超时时间。使用Azure Application Gateway时，还可以自定义预期的响应代码，并与响应正文的内容进行匹配。

NGINX Plus通过高级健康检查扩展了此功能。除了指定要使用的URL外，还可以使用NGINX Plus在请求中插入标头、检查不同的响应代码，以及检查响应的标头和正文。

NGINX Plus中一个实用的相关功能是“慢启动”。NGINX Plus会逐步增加新服务器或近期恢复的服务器所承受的负载，避免连接过多导致服务器不堪重负。如果后端服务器需要一定的预热时间，并且在刚显示为健康状态时立即承接全部应分配的流量会导致故障，此功能会很有帮助。

NGINX Plus还支持对TCP和UDP服务器进行健康检查，并允许指定要发送的字符串以及要在响应中查找的字符串。

Azure Load Balancer支持TCP运行状况检查，但无法提供这种级别的监控。

SSL/TLS终止

NGINX Plus支持SSL/TLS终止，Azure Application Gateway也支持此功能，但Azure Load Balancer不支持。

连接数和速率限制

使用NGINX Plus，可以配置多种限制，以控制进出NGINX Plus实例的流量，包括限制入站连接、与后端节点的连接、入站请求速率以及NGINX Plus向客户端传输数据的速率。

Azure Application Gateway和Azure Load Balancer不支持速率限制或连接数限制。不过，可以使用其他Azure服务配置并启用速率限制。

协议支持以及URL重写和重定向

NGINX Plus、Azure Application Gateway和Azure Load Balancer均支持以下功能：

HTTP/2，NGINX Plus自2016年以来一直可接受来自客户端的HTTP/2请求。Azure则在更晚些时候才添加WebSocket支持。
WebSocket，NGINX Plus自2014年起便可接受来自客户端的WebSocket连接。Azure则在较晚时候才添加了WebSocket支持。
URL重写和请求重定向：可在将请求传递到后端服务器之前更改其URL。这意味着，无需修改向客户端公布的URL，即可在内部更改请求路径和文件位置。还可以重定向请求，例如将HTTP请求的协议从HTTP更改为HTTPS。