宣布推出 NGINX Plus R16

[ngx_snippet 名称='table-style-blog']
我们很高兴地宣布NGINX Plus Release 16 (R16)现已推出。 今天的发布是推进 NGINX 技术愿景最重要的发布之一。 借助 R16，NGINX Plus 现在可以作为所有应用的单一、弹性的入口和出口层。 这意味着您可以将负载均衡器、API 网关和 WAF 的功能整合到跨任何云的单个软件包中。

今天我们采访的许多公司都拥有这些组件，但通常来自不同的供应商。 由于运营团队必须单独管理每个点解决方案，因此这会增加成本和复杂性。 由于每个额外的跳跃都会增加额外的延迟和故障点，因此它也会降低性能和可靠性。

借助NGINX Plus R16中的新功能，您可以开始整合和简化您的基础设施，并朝着为传统和现代应用构建弹性入口/出口层的方向发展。 NGINX Plus R16包含新的集群功能、增强的 UDP 负载均衡和 DDoS 缓解功能，使其成为昂贵的F5 BIG-IP硬件和其他负载均衡基础设施的更完整替代品。 对全局速率限制的新支持进一步使 NGINX Plus 成为许多 API 网关解决方案的轻量级替代方案。 最后，新支持“随机两种选择”负载均衡，使 NGINX Plus 成为在 Kubernetes 等扩展或分布式环境中平衡微服务流量负载的理想选择。

NGINX Plus R16 新功能概述

NGINX Plus R16的新功能包括：

• 集群感知速率限制——在NGINX Plus R15中，我们引入了状态共享模块，允许在 NGINX Plus 集群之间同步数据。 在此版本中，状态共享扩展到速率限制功能，使您能够指定跨 NGINX Plus 集群的全局速率限制。 全局速率限制是 API 网关的一个重要功能，也是 NGINX Plus 的一个非常流行的用例。
• 集群感知键值存储- 在NGINX Plus R13中，我们引入了键值存储，例如，可用于创建动态 IP 地址拒绝列表或管理 HTTP 重定向。 在此版本中，键值存储现在可以在集群之间同步，并包含一个新的超时参数，以便可以自动删除单个键值对。 通过新的同步支持，键值存储现在可用于提供动态 DDoS 缓解、分发经过身份验证的会话令牌或构建分布式内容缓存(CDN)。
• 随机两种选择负载均衡——当对负载均衡器进行集群时，重要的是使用不会无意中导致单个后端服务器过载的负载均衡算法。 随机两种选择负载均衡对于扩展集群来说非常有效，并且将成为 Kubernetes 的 NGINX Ingress Controller 的下一个版本中的默认方法。
• 增强的 UDP 负载均衡– 在NGINX Plus R9中我们首次引入了 UDP 负载均衡。 初始实现仅限于 UDP应用，这些应用程序期望客户端与服务器每次交互时都发送一个 UDP 数据包（例如 DNS 和 RADIUS）。 NGINX Plus R16可以处理来自客户端的多个 UDP 数据包，使我们能够支持更复杂的 UDP 协议，例如 OpenVPN、IP 语音 (VoIP) 和虚拟桌面基础设施 (VDI)。
• AWS PrivateLink 支持– AWS PrivateLink是亚马逊用于在虚拟私有云中创建安全 VPN 隧道的技术。 通过此版本，您现在可以对 AWS PrivateLink 数据中心内的流量进行身份验证、路由、负载平衡以及优化流量的流动方式。 此功能建立在对PROXY 协议 v2 的新支持之上。

其他增强功能包括对 OpenID Connect 不透明会话令牌、加密会话动态模块、NGINX JavaScript 模块更新等的支持。 NGINX Plus R16基于 NGINX Open Source 1.15.2，包含开源版本中的所有功能。

在NGINX Plus R16的开发过程中，我们还为 Kubernetes 的官方 NGINX Ingress Controller（NGINX Plus 的一个突出用例）添加了许多重要的增强功能。

在NGINX Conf 2018上了解有关NGINX Plus R16和所有 NGINX 事宜的更多信息。 我们将举办专门的会议、演示并邀请专家来深入了解所有新功能。

行为方面的重要变化

• 由统一的NGINX Plus API取代和弃用的上游 Conf 和 Status API 已被删除。 2017 年 8 月， NGINX Plus R13引入了全新的NGINX Plus API，用于动态重新配置上游组和监控指标，取代之前实现这些功能的上游 Conf 和状态 API。 正如当时宣布的那样，弃用的 API 仍然可用，并在相当长的一段时间内得到支持，但这段时间已经结束了。 如果您的配置包括upstream_conf和/或status指令，则必须在升级到R16的过程中将它们替换为api指令。

  有关迁移到新NGINX Plus API 的建议和帮助，请参阅我们博客上的过渡指南，或联系我们的支持团队。

• 停止对已停产操作系统版本的支持- NGINX Plus 不再支持Ubuntu 17.10 (Artful) 、FreeBSD 10.3 或 FreeBSD 11.0。

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

• NGINX New Relic 插件已更新为使用新的NGINX Plus API ，现在是一个开源项目。 更新后的插件适用于 R13 及以上版本的所有 NGINX Plus，但不再受 NGINX, Inc. 的支持或维护。

新功能详情

集群感知速率限制

NGINX Plus R15引入了zone_sync模块，使得运行时状态可以在集群中的所有 NGINX Plus 节点之间共享。

第一个同步功能是粘性学习会话持久性。 NGINX Plus R16将状态共享扩展到速率限制功能。 当部署在集群中时，NGINX Plus 现在可以对传入的请求应用一致的速率限制，无论请求到达集群的哪个成员节点。 通常称为全局速率限制，在集群中应用一致的速率限制与 API 网关用例特别相关，将 API 交付到服务级别协议 (SLA)，以防止客户端超过指定的速率限制。

NGINX Plus 状态共享不需要或使用主节点——所有节点都是对等的，并在全网状拓扑中交换数据。 NGINX Plus 状态共享集群必须满足三个要求：

• 所有集群节点之间的网络连接
• 同步时钟
• 每个节点上启用zone_sync模块的配置，如以下代码片段所示。

流 { 解析器 10.0.0.53 有效=20s; 服务器 { 监听 10.0.0.1:9000; zone_sync ; zone_sync_server nginx-cluster.example.com:9000 解析; } }

zone_sync指令可以实现集群中共享内存区域的同步。 zone_sync_server指令标识集群中的其他 NGINX Plus 实例。 NGINX Plus 支持 DNS 服务发现，因此可以通过主机名识别集群节点，从而使所有节点上的配置相同。 请注意，这是一个最小配置，没有生产部署所需的安全控制。 有关更多详细信息，请参阅NGINX Plus R15 公告和zone_sync模块的参考文档。

一旦在所有节点上都实施了此配置，只需将新的同步参数添加到limit_req_zone指令即可在整个集群中应用速率限制。 通过以下配置，NGINX Plus 根据客户端的 IP 地址对每个客户端施加每秒 100 个请求的速率限制。

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync ; # 集群感知服务器 { listen 80; location / { limit_req zone=per_ip; # 在此处应用速率限制 proxy_pass http://my_backend; } }

此外，状态共享集群解决方案独立于基于keepalived的高可用性解决方案，以实现网络弹性。 因此，与该解决方案不同，状态共享集群可以跨越物理位置。

集群感知键值存储

NGINX Plus R13 引入了轻量级内存键值存储作为原生 NGINX 模块。 该模块随 NGINX Plus 一起提供，支持无需安装额外软件组件即可配置需要简单数据库存储的解决方案。 此外，键值存储通过NGINX Plus API进行控制，以便可以通过 REST 接口创建、修改和删除条目。

NGINX Plus 键值存储的用例包括动态 IP 地址拒绝名单、动态带宽限制和身份验证令牌缓存。

使用NGINX Plus R16，键值存储现在具有集群感知能力，以便条目可以在集群中的所有节点之间同步。 这意味着使用 NGINX Plus 键值存储的解决方案可以部署到各种集群环境 - 主动 - 被动、主动 - 主动以及广泛分布。

至于其他集群感知功能，您只需将sync参数添加到已配置为状态共享的集群的keyval_zone指令（使用zone_sync和zone_sync_server指令）即可配置键值存储的同步。

键值存储也得到了扩展，可以为添加到键值存储的每个键值对设置超时值。 当指定的超时时间过去时，此类条目将自动过期并从键值存储中删除。 配置同步键值存储时，超时参数是必需的。

使用 NGINX Plus 键值存储实现动态 DDoS 防护

您可以结合 NGINX Plus 的新集群功能来构建复杂的解决方案来防御 DDoS 攻击。 当 NGINX Plus 实例池部署在主动集群中或分布在广域网中时，恶意流量可以到达其中任何一个实例。 该解决方案使用同步速率限制和同步键值存储来动态响应 DDoS 攻击并减轻其影响，如下所示。

• 集群感知速率限制会捕获每秒发送超过 100 个请求的客户端，无论哪个 NGINX Plus 节点接收该请求。
• 当客户端超出速率限制时，其 IP 地址将通过调用NGINX Plus API添加到“sin bin”键值存储中。sin bin 在整个集群中同步。
• 无论哪个 NGINX Plus 节点接收来自 sin bin 中客户端的进一步请求，它们都会受到非常低的带宽限制。 限制带宽比直接拒绝请求更好，因为它不能明确地向客户端发出 DDoS 缓解措施正在生效的信号。
• 十分钟后，客户将被自动从禁闭室中移除。

以下配置显示了此动态 DDoS 缓解解决方案的简化实现。

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # 集群感知速率 limitlimit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # 集群感知“sin bin”带有 
# 10 分钟 TTL
keyval $remote_addr $in_sinbin zone=sinbin; # 使用 
# 匹配的客户端 IP 地址填充 $in_sinbin

server {
listen 80;
location / {
if ($in_sinbin) {
set $limit_rate 50; # 限制不良客户端的带宽
}

limit_req zone=per_ip; # 在此处应用速率限制
error_page 429 = @send_to_sinbin; # 过多的客户端被移动到 
# 此位置
proxy_pass http://my_backend;
}

location @send_to_sinbin {
rewrite ^ /api/3/http/keyvals/sinbin break; # 设置 URI 
# “sin bin” key-val
proxy_method POST;
proxy_set_body '{"$remote_addr":"1"}';
proxy_pass http://127.0.0.1:80;
}

location /api/ {
api write=on;
# 控制对 API 的访问的指令
}
}

随机两种选择负载平衡

应用交付和 API 交付环境使用扩展或分布式负载均衡层来接收客户端请求并将其传递给共享应用环境的情况越来越普遍。 当多个负载均衡器将请求传递给同一组后端服务器时，使用不会无意中使各个后端服务器过载的负载均衡方法非常重要。

在主动配置中部署的 NGINX Plus 集群或具有多个入口点的分布式环境是常见场景，它们会给传统的负载平衡方法带来挑战，因为每个负载平衡器无法完全了解已发送到后端服务器的所有请求。

容器化集群内部的负载平衡具有与横向扩展主动主动部署相同的特性。 部署在具有多个 Ingress 资源实例的副本集中的 Kubernetes Ingress 控制器也面临着如何有效地将负载分配给提供集群中每个服务的 pod 的挑战。

工作负载差异对分布式负载均衡的有效性有很大影响。 当每个请求对后端服务器施加相同的负载时，测量每个服务器对之前请求的响应速度是决定下一个请求发送到何处的有效方法。 NGINX Plus 独有的最少时间负载均衡方法就可以实现这一点。 但是，当后端服务器上的负载是可变的（例如，因为它同时包含读取和写入操作）时，过去的性能无法很好地预测未来的性能。

在分布式环境中平衡负载的最简单方法是随机选择后端服务器。 随着时间的推移，负载会趋于平均，但这是一种粗略的方法，可能会不时向各个服务器发送大量流量。

随机负载均衡的一个简单变体，已被证明可以改善负载分配，就是随机选择两个后端服务器，然后将请求发送给负载最低的服务器。 比较两个随机选择的目的是避免做出错误的负载均衡决策，即使做出的决策不是最佳的。 通过避开负载较大的后端服务器，每个负载均衡器可以独立运行，同时仍能避免向各个后端服务器发送流量高峰。 因此，该方法具有随机负载均衡的优势和计算效率，但负载分布明显更好。

NGINX Plus R16引入了两种新的负载平衡方法，随机和随机两种选择。 对于后者，您可以进一步指定 NGINX Plus 比较哪个负载指示指标来决定两个选定的后端中的哪一个接收请求。 下表列出了可用的指标。

* 所有基于时间的指标均为 NGINX Plus 独有的

以下代码片段展示了使用random two指令（ HTTP ， Stream ）进行 Random with Two Choices 负载平衡配置的简单示例。

上游 my_backend { zone my_backend 64k; 服务器 10.0.0.1; 服务器 10.0.0.2; 服务器 10.0.0.3; #...随机两个least_time=last_byte; # 从两个随机选择中选择更快的响应时间 } 服务器 { listen 80; location / { proxy_pass http://my_backend; # 负载平衡到上游组 } }

请注意，“随机两种选择”方法仅适用于多个负载均衡器将请求传递到同一组后端的分布式环境。 当 NGINX Plus 部署在单个主机上或主动被动部署中时，请勿使用它。 在这些情况下，单个负载均衡器可以全面查看所有请求，并且循环、最少连接和最少时间方法可以提供最佳结果。

增强型 UDP 负载平衡

NGINX Plus R9引入了对代理和负载均衡 UDP 流量的支持，使 NGINX Plus 能够位于流行的 UDP应用（如 DNS、syslog、NTP 和 RADIUS）的前端，以提供应用服务器的高可用性和可扩展性。 最初的实现仅限于 UDP应用，这些应用程序期望客户端每次与服务器交互时都发送一个 UDP 数据包。

使用NGINX Plus R16 ，可以支持多个传入数据包，这意味着可以代理和负载平衡更复杂的 UDP应用。 这些包括 OpenVPN、VoIP、虚拟桌面解决方案和数据报传输层安全性 (DTLS) 会话。 此外，NGINX Plus 对所有 UDP应用（无论是简单还是复杂）的处理也速度明显加快。

NGINX Plus 是唯一一款可在同一实例上同时对四种最流行的 Web 协议（UDP、TCP、HTTP 和 HTTP/2）进行负载平衡的软件负载平衡器。

PROXY 协议 v2 支持

NGINX Plus R16增加了对PROXY 协议 v2 (PPv2) 标头的支持，以及检查标头中的自定义类型长度值(TLV) 值的能力。

PROXY 协议由第 7 层代理（例如 NGINX Plus 和 Amazon 的负载均衡器）用于将连接信息传输到位于另一组第 7 层代理或 NAT 设备后面的上游服务器。 这是必要的，因为当代理中继连接时，某些连接信息（如源 IP 地址和端口）可能会丢失，而且并不总是可以依靠 HTTP 标头注入来传输这些信息。 NGINX Plus 的早期版本支持 PPv1 标头； NGINX Plus R16增加了对 PPv2 标头的支持。

将 PPv2 与 Amazon 网络负载均衡器结合使用

PPv2 标头的一个用例是由 Amazon 网络负载均衡器 (NLB) 中继的连接，这些连接可能看起来源自负载均衡器上的私有 IP 地址。 NLB 在每个连接前添加一个 PPv2 标头，用于标识客户端连接的真实源 IP 地址和端口。 可以从$proxy_protocol_addr变量中获取真实源，并且可以使用realip模块用 PPv2 标头中的值覆盖 NGINX 的内部源变量。

将 PPv2 与 AWS PrivateLink 结合使用

AWS PrivateLink是亚马逊用于创建通向虚拟私有云 (VPC) 的安全 VPN 隧道的技术。 它通常用于发布提供商服务（在提供商 VPC 中运行）并使其可供一个或多个客户端 VPC 使用。 与提供商服务的连接源自在提供商 VPC 中运行的 NLB。

在许多情况下，提供商服务需要知道每个连接的来源，但 PPv2 标头中的源 IP 地址本质上毫无意义，对应于客户端 VPC 中的内部不可路由地址。AWS PrivateLink NLB 使用 PPv2 TLV 记录0xEA将源 VPC ID添加到标头。

NGINX Plus 可以检查 PPv2 TLV 记录，并可以使用$proxy_protocol_tlv_0xEA变量提取 AWS PrivateLink 连接的源 VPC ID。 这使得在 AWS PrivateLink 数据中心内进行身份验证、路由和控制流量成为可能。

NGINX Plus R16 的其他新功能

OpenID Connect 不透明会话令牌

NGINX Plus OpenID Connect 参考实现已扩展以支持不透明会话令牌。 在此用例中，JWT 身份令牌不会发送到客户端。 相反，它被存储在 NGINX Plus 键值存储中，并在其位置发送一个随机字符串。 当客户端提供随机字符串时，它会被交换为 JWT 并进行验证。 此用例已从原型/实验升级到生产级，现在键值存储中的条目可以具有超时值，并可以在集群内同步。

加密会话动态模块

加密会话社区模块基于带 MAC 的 AES-256 为 NGINX 变量提供加密和解密支持。它现在在 NGINX Plus 存储库中作为NGINX Plus 支持的动态模块提供。

NGINX JavaScript 模块增强功能

R16 中的 NGINX JavaScript 模块包括对 JavaScript 语言支持范围的大量扩展。 HTTP JavaScript 模块已经得到简化，因此单个对象( r ) 现在就可以访问与每个请求关联的请求和响应属性。 以前有单独的请求（ req ）和响应（ res ）对象。 这种简化使得 HTTP JavaScript 模块与具有单个会话对象的 Stream JavaScript 模块一致。 此更改完全向后兼容 - 现有的 JavaScript 代码将继续按原样工作 - 但我们建议您修改现有的 JavaScript 代码以利用此简化，并在您将来编写的代码中使用它。

JavaScript 语言支持现在包括：

• 字符串方法： bytesFrom () 、 padStart()和padEnd()
• 附加方法： getrandom()和getentropy()
• 二进制文字

JavaScript 模块的完整更改列表记录在changelog中。

新的$ssl_preread_protocol变量

新的$ssl_preread_protocol变量允许您在使用 TCP（流）代理转发流量时区分 SSL/TLS 和其他协议。 该变量包含客户端支持的最高 SSL/TLS 协议版本。 如果您想通过（例如）在同一端口运行 SSL/TLS 和 SSH 服务来避免防火墙限制，这很有用。

有关更多详细信息，请参阅我们博客上的在同一端口上运行 SSL 和非 SSL 协议。

Kubernetes Ingress Controller 增强功能

NGINX Plus 可以管理广泛环境中的流量，其中一个重要的用例是作为Kubernetes 的入口负载均衡器。 NGINX 开发了一个Ingress 控制器解决方案，可自动配置 NGINX Plus，并且所有 NGINX Plus 订阅者都完全支持此集成。 （所有 NGINX 开源用户和 NGINX Plus 客户都可以在 GitHub 上找到开源实现，并定期发布正式版本。）

在NGINX Plus R16的开发过程中，官方 NGINX Ingress Controller for Kubernetes 增加了许多重要的增强功能：

• Prometheus 支持使用户能够将 NGINX 和 NGINX Plus 指标直接导出到 Kubernetes 上的 Prometheus。
• 对 Helm 图表的支持简化了 Ingress 控制器的安装和管理。
• 对负载平衡 gRPC 流量的支持为基于 gPRC 的应用提供了高可用性和可扩展性。 （在 1.2.0 版本中添加。）
• Kubernetes pod 的主动健康检查可以快速检测 pod 和网络连接中的故障。
• 多租户、可合并的配置允许关注点分离，让团队独立管理同一 Web应用的不同路径，同时操作保留对前端侦听器和 SSL 配置的控制。
• 基于每个路径的细粒度 JWT 身份验证可以对丰富应用的身份验证进行更深入的控制。
• 直接管理配置模板使得开发和测试 NGINX 配置的自定义更改变得更加容易。

NGINX Ingress Controller 可以使用ConfigMaps （嵌入 NGINX 配置）或通过编辑基本模板进行进一步扩展，允许用户在为在 Kubernetes 上运行的应用创建流量管理策略时访问所有 NGINX 功能。

有关更多详细信息，请参阅我们博客上的“宣布发布适用于 Kubernetes 的 NGINX Ingress Controller 1.3.0 版” 。

升级或尝试 NGINX Plus

NGINX Plus R16包括额外的集群功能、全局速率限制、新的负载平衡算法和几个错误修复。 如果您正在运行 NGINX Plus，我们强烈建议您尽快升级到 R16。 您将获得大量修复和改进，这将帮助 NGINX, Inc. 在您需要提出支持单时为您提供帮助。

在继续升级之前，请仔细查看本博客文章中描述的新功能和行为变化。

如果您还没有尝试过NGINX Plus ，我们鼓励您尝试一下——用于 Web 加速、负载均衡和应用交付，或作为具有增强监控和管理 API 的完全支持的 Web 服务器。 您今天即可免费开始使用30 天免费试用版。 亲自了解 NGINX Plus 如何帮助您交付和扩展您的应用。