NGINX Plus R20 正式发布

NGINX | 2019年12月03日

我们很高兴地宣布，NGINX Plus Release 20（R20）现已发布。NGINX Plus集负载均衡器、内容缓存、Web服务器和API网关于一体。NGINX Plus基于NGINX Open Source构建，提供专属增强功能和屡获殊荣的支持服务。

NGINX Plus R20 在R19速率限制和键值存储增强功能的基础上进一步改进。新增功能包括：

实时监控和记录受速率限制的流量；配置速率限制后，NGINX Plus API现在会报告立即放行、延迟处理或拒绝的请求数量。还可以配置访问日志，使其包含各个请求的速率限制状态信息。
连接限制功能增强，R19和此版本中引入的速率限制增强功能现已扩展至连接限制。
键值存储中的前缀匹配：键值存储中的键可以与指定前缀（字符串开头的字符）进行匹配。动态请求路由是其中一个重要用例。
按上游组进行 DNS 解析，现在可以为每个使用可解析主机名表示组内后端服务器的上游组指定一组不同的 DNS 服务器。
其他PROXY Protocol变量：新变量可捕获客户端最初连接的代理服务器的IP地址和端口。
HTTP/2安全性改进：多项变更提升了HTTP/2流量的整体安全性，包括更准确地检测客户端的错误或无效行为，以及更稳健地实现某些指令。

重要行为变更

已废弃的API：NGINX Plus R13（发布于2017年8月）引入了全新的NGINX Plus API<.htmlspan>，用于指标收集和上游组的动态重新配置，取代了此前实现这些功能的Status和Upstream Conf API。正如当时所宣布的那样，这些已弃用的API在相当长一段时间内仍可使用并获得支持，直至NGINX Plus R16。如果配置中包含status或upstream_conf指令，则在升级到R20时必须将其替换为api指令。如需有关迁移到新NGINX Plus API的建议和帮助，请参阅我们博客上的迁移指南，或联系我们的支持团队。
新增支持的操作系统：
- CentOS 8.0+
- FreeBSD 12.1
- Red Hat Enterprise Linux 8.1
- Ubuntu 19.10（“Eoan Ermine”）

有关受支持平台的更多信息，请参阅NGINX Plus和动态模块的技术规格。

新功能详解

实时监控和记录限速流量

NGINX Plus R20引入了多项功能，便于运维和DevOps团队实时监控限速活动，并准确确定哪些客户端已超出速率限制。
NGINX Plus始终支持灵活定义需要限速的客户端请求类型以及超量请求的处理方式。每个请求将按以下方式之一处理：

已放行，无延迟（因为请求速率低于限制值或处于配置的突发大小范围内）
延迟，直至放行该请求不会导致超出速率限制（也称为“限流”）
拒绝，并返回HTTP错误响应代码

在以前的版本中，NGINX Plus仅在错误日志中记录请求被延迟或拒绝的情况，并采用如下标准化条目：

2019/12/02 11:42:12 [error] 57#57: *339 limiting requests, excess: 0.600 by zone "my_limit", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.0", host: "www.example.com:80"

由于消息格式采用非结构化形式且不可配置，从错误日志中提取有用信息可能并不容易。此外，如果速率限制以错误日志条目中未记录的消息特征为依据，例如HTTP标头或身份信息，则必须在访问日志中找到对应条目，才能准确确定哪个客户端超出了速率限制。新功能解决了这些问题。

来自NGINX Plus API的限流指标

NGINX Plus API新增了一个端点/api/version/http/limit_reqs，用于维护由limit_req_zone指令定义的每个区域中所有限流决策结果的计数器。这些计数器既可用于实时监控限流决策，也可与APM解决方案集成，以提供限流活动的仪表板和警报。

在以下示例中，定义了一个区域：my_limit:

$ curl http://localhost/api/6/http/limit_reqs
{
 "my_limit": {
   "delayed": 540,
   "delayed_dry_run": 12162,
   "passed": 804541,
   "rejected": 63,
   "rejected_dry_run": 1209
 }
}

请注意，这些计数器还包括以试运行模式处理的过量请求条目。该模式在NGINX Plus R19中引入。

在访问日志中记录限速活动

实时指标非常有助于了解NGINX Plus处理过量请求的时间，但无法说明这些请求由谁生成。为解决这一问题，NGINX Plus R20提供了一个新的$limit_req_status变量，用于记录请求的速率限制状态：DELAYED、DELAYED_DRY_RUN、PASSED、REJECTED或REJECTED_DRY_RUN。

然后，可以在日志格式中加入其他变量，用于唯一标识客户端、URI及其他相关信息。在以下配置中，系统根据JSON Web Token（JWT）验证结果（第1行），对每个客户端强制实施每秒10个请求的严格速率限制。超出限制的请求将被拒绝（第16行），并记录到单独的日志文件中（第21行）。该日志文件还包含$jwt_claim_sub变量，用于捕获sub声明（第4行）。

正在加载代码示例…

以下是reject.log文件中的示例条目：

time=1575289305.350 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTEDtime=1575289305.395 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED
time=1575289305.402 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED

连接限制功能增强

除了对请求进行速率限制外，NGINX Plus还支持使用Limit Connections模块限制客户端连接。您可以定义一个客户端可与NGINX Plus建立的独立连接数（使用HTTP/2时，则为并发请求数）。通常通过远程IP地址（即变量$remote_addr或$binary_remote_addr）来识别客户端，但如果远程IP地址无法明确标识客户端或可能由多个客户端共享，则可以使用其他变量（例如，使用$jwt_claim_sub表示JWT中的用户名）。

NGINX Plus R20扩展了连接限制功能，采用了与以下版本中引入的速率限制增强功能相同的增强功能：NGINX Plus R19和本版本

使用limit_conn_dry_run指令的试运行模式
在NGINX Plus API端点进行实时监控：/api/version/http/limit_conns
新增变量$limit_conn_status，用于捕获每个请求的连接限制决策（PASSED、REJECTED或REJECTED_DRY_RUN），其用法可参照在访问日志中记录速率限制活动中对$limit_req_status变量的说明

以下配置会对并发连接数超过10个的客户端实施低带宽限制。

正在加载代码示例…

键值存储中的前缀匹配

借助NGINX Plus的内存键值存储，可以使用NGINX Plus API根据请求属性动态配置流量管理。示例用例包括动态将IP地址加入拒绝列表、动态限制带宽以及缓存身份验证令牌。

NGINX Plus R20新增了按指定前缀（字符串开头的字符）匹配键的支持，为键值存储带来了一系列新的用例。例如，通过按URI前缀（基础路径）而非精确URI匹配键，可以创建动态路由表，将每个基础路径映射到一个上游组，从而替代或补充由location指令定义的静态映射。

要启用前缀匹配，请在type=prefix指令中添加新的keyval_zone参数。在以下配置中，keyval指令将Cache-Control指令（例如max-age或no-cache）与各URI前缀相关联；当NGINX Plus将请求转发到上游服务器时，add_header指令会将Cache-Control响应标头设置为该值。

正在加载代码示例…

我们使用NGINX Plus API，在键值存储中为每个基础路径（在本例中，是以Cache-Control响应标头的值。/images/或/reports/开头的路径）进行定义：

$ curl -i -X POST --data '{"/images/":"max-age=3600", "/reports/":"no-cache"}' http://localhost:8080/api/6/http/keyvals/pathsHTTP/1.1 201 Created
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:36:31 GMT
Content-Length: 0
Location: http://localhost:8080/api/6/http/keyvals/paths/
Connection: keep-alive

当我们使用键值存储中存在的基础路径发出请求时，响应中会包含我们设置的“Cache-Control”标头：

$ curl -I http://localhost/images/sample.jpgHTTP/1.1 200 OK
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:27:39 GMT
Content-Type: image/jpeg
Content-Length: 120847
Connection: keep-alive
Cache-Control: max-age=3600

由于键值存储可以在NGINX Plus实例集群中同步，因此每次API调用只需发送到一个实例。与协调配置文件的更改相比，这大大简化了集群配置更改的自动化流程。

按上游组进行 DNS 解析

使用NGINX Plus在多个上游服务器之间执行负载均衡时，可以通过指定可解析为多个IP地址的主机名来定义上游组的成员。这对于上游组成员可能频繁变化的动态或自动扩缩容环境尤其有用。

要完成这些动态上游组的配置，还需添加resolver指令，用于指定NGINX Plus为查询与该主机名关联的IP地址而使用的一个或多个DNS服务器。在以前的版本中，resolver指令适用于包含该指令的上下文（http、server或location）中由proxy_pass指令引用的所有上游组。现在，使用NGINX Plus R20可以为每个上游组指定不同的DNS解析器。

这种新的灵活性在DevOps环境中尤其有用。应用团队可以自行管理更多应用交付基础设施，包括DNS服务器和服务注册中心，而不必依赖集中式共享服务。

仍可在顶层http上下文以及server和location块中定义全局解析器。如果upstream块不包含resolver指令，则与之前的版本一样，该块会继承包含proxy_pass指令且该指令引用此上游组的上下文或块中的resolver设置。

在以下示例中，website上游组使用全局解析器，而mobile_app使用自己的解析器：

正在加载代码示例…

请注意，我们在两个status_zone参数（在NGINX Plus R19中引入）均添加到resolver指令中，用于收集解析器活动的错误指标及其他指标。

PROXY Protocol服务器元数据变量

PROXY Protocol是一种机制，借助该机制，第4层代理可将原始客户端连接的相关信息传递给下一个处理客户端请求的代理或负载均衡器。如果需要获取客户端的IP地址，这一点尤为重要。例如，可使用least_conn指令限制每个客户端建立的连接数，或仅记录真实客户端的IP地址。与之前的版本一样，$proxy_protocol_addr变量会捕获此信息。

在应用环境中部署多个第 4 层代理时，NGINX Plus有时还需要知道客户端最初连接的代理服务器的IP地址和端口。PROXY Protocol元数据包含这些信息，NGINX Plus R20新增了用于捕获这些信息的变量：

这些变量同时适用于HTTP模块和Stream（TCP/UDP）模块，并支持PROXY Protocol版本1和版本2。请注意，使用这些变量前，必须在proxy_protocol指令中添加listen参数，以明确启用NGINX Plus处理PROXY Protocol。