NGINX Plus R16正式发布

Liam Crilly产品管理高级总监

[ngx_snippet name=’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重定向。在此版本中，键值存储现可在集群内同步，并新增了timeout参数，以便自动移除各个键值对。借助新增的同步支持，键值存储现可用于提供动态DDoS缓解、分发经过身份验证的会话令牌，或构建分布式内容缓存（CDN）。
• 二选一随机负载均衡：对负载均衡器进行集群部署时，应使用不会意外导致个别后端服务器过载的负载均衡算法。二选一随机负载均衡对扩展后的集群非常高效，并将成为下一版本NGINX Ingress Controller for Kubernetes的默认方法。
• 增强型UDP负载均衡：NGINX Plus R9首次引入了UDP负载均衡。初始实现仅适用于每次与服务器交互时只接收一个客户端UDP数据包的UDP应用（例如DNS和RADIUS）。NGINX Plus R16可以处理来自客户端的多个UDP数据包，从而支持更复杂的UDP协议，例如OpenVPN、IP语音（VoIP）和虚拟桌面基础架构（VDI）。
• 支持AWS PrivateLink：AWS PrivateLink是Amazon用于创建通往Virtual Private Cloud的安全VPN隧道的技术。此版本现可对AWS PrivateLink数据中心内的流量进行身份验证、路由和负载均衡，并优化流量传输方式。此功能基于新增的PROXY protocol v2支持。

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

在NGINX Plus R16的开发过程中，我们还为官方NGINX Ingress Controller for Kubernetes添加了多项重要增强功能。该控制器是NGINX Plus的一个重要用例。

在NGINX Conf 2018上深入了解NGINX Plus R16及NGINX的方方面面。届时将安排专题会议和演示，并有专家现场深入讲解所有新功能。

重要行为变更

• 已移除由统一的NGINX Plus API取代并弃用的Upstream Conf API和Status API。2017年8月，NGINX Plus R13推出了全新的NGINX Plus API，用于动态重新配置上游组和监控指标，取代了此前实现这些功能的Upstream Conf API和Status API。正如当时所公告的，这些已弃用的API在相当长一段时间内仍可使用并获得支持，但这一支持期现已结束。如果配置中包含upstream_conf和/或status指令，则在升级到R16时，必须将其替换为api指令。如需获取迁移到新NGINX Plus API的建议和帮助，请参阅我们博客上的迁移指南，或联系我们的支持团队。
• 停止支持已终止生命周期的操作系统版本：NGINX Plus不再支持Ubuntu 17.10 (Artful)、FreeBSD 10.3或FreeBSD 11.0。有关受支持平台的更多信息，请参阅NGINX Plus和动态模块的技术规格。
• The NGINX New Relic 插件已更新，现已使用新的NGINX Plus API并成为开源项目。更新后的插件适用于R13及更高版本的所有NGINX Plus，但NGINX, Inc.不再为其提供支持或维护。

新功能详解

集群感知型速率限制

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

首个实现同步的功能是sticky‑learn 会话持久性。NGINX Plus R16 将状态共享扩展到速率限制功能。部署在集群中时，无论传入请求到达哪个集群成员节点，NGINX Plus 现在都可以对其应用一致的速率限制。这通常称为全局速率限制。在整个集群中应用一致的速率限制尤其适用于 API 网关用例，可按照服务级别协议（SLA）交付 API，防止客户端超过指定的速率限制。

NGINX Plus状态共享不需要也不使用主节点；所有节点均为对等节点，并通过全网状拓扑交换数据。NGINX Plus状态共享集群必须满足以下3项要求：

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

stream {    resolver 10.0.0.53 valid=20s;

    server {
        listen 10.0.0.1:9000;
        zone_sync;
        zone_sync_server nginx-cluster.example.com:9000 resolve;
    }
}

The zone_sync指令用于在集群中同步共享内存区。zone_sync_server指令用于标识集群中的其他NGINX Plus实例。NGINX Plus支持DNS服务发现，因此可通过主机名识别集群节点，使所有节点使用相同的配置。请注意，这是最低限度的配置，不包含生产部署所需的安全控制措施。有关更多详细信息，请参阅NGINX Plus R15公告以及zone_sync模块的参考文档。

在所有节点上完成此配置后，只需将新的sync参数添加到limit_req_zone指令，即可在整个集群中应用速率限制。使用以下配置时，NGINX Plus会根据客户端的IP地址，将每个客户端的速率限制为每秒100个请求。

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware
server {
    listen 80;
    location / {
        limit_req zone=per_ip; # Apply rate limit here
        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指令中，即可配置键值存储同步。

键值存储还新增了为添加到其中的每个键值对设置超时值的功能。指定的超时时间结束后，此类条目会自动过期并从键值存储中移除。配置同步键值存储时，必须指定timeout参数。

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

可以结合NGINX Plus的新集群功能，构建一套完善的DDoS攻击防护解决方案。当一组NGINX Plus实例部署在双活集群中或分布在广域网中时，恶意流量可能会到达其中任一实例。该解决方案使用同步速率限制和同步键值存储，动态响应DDoS攻击并减轻其影响，具体如下。

• 集群感知型速率限制可识别每秒发送超过100个请求的客户端，无论请求由哪个NGINX Plus节点接收。
• 当客户端超过速率限制时，系统会调用NGINX Plus API，将其IP地址添加到“隔离区”键值存储中。该隔离区会在整个集群中同步。
• 对于来自“隔离区”中客户端的后续请求，无论由哪个NGINX Plus节点接收，都将施加极低的带宽限制。限制带宽比直接拒绝请求更合适，因为这样不会向客户端明确表明DDoS缓解措施已生效。
• 10 分钟后，客户端将自动从隔离区中移除。

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

limit_req_zone   $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware rate limitlimit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # Cluster-aware "sin bin" with 
                                             # 10-minute TTL
keyval $remote_addr $in_sinbin zone=sinbin;  # Populate $in_sinbin with 
                                             # matched client IP addresses

server {
    listen 80;
    location / {
        if ($in_sinbin) {
            set $limit_rate 50; # Restrict bandwidth of bad clients
        }

        limit_req zone=per_ip;            # Apply the rate limit here
        error_page 429 = @send_to_sinbin; # Excessive clients are moved to 
                                          # this location
        proxy_pass http://my_backend;
    }

    location @send_to_sinbin {
        rewrite ^ /api/3/http/keyvals/sinbin break; # Set the URI of the 
                                                    # "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;
        # directives to control access to the API
    }
}

随机二选一负载均衡

在应用交付和API交付环境中，使用可扩展或分布式负载均衡层接收客户端请求，并将其转发到共享应用环境的做法日益普遍。当多个负载均衡器将请求转发到同一组后端服务器时，应采用不会意外导致单台后端服务器过载的负载均衡方法。

采用双活配置部署的NGINX Plus集群，或具有多个入口点的分布式环境，都是常见场景。由于每个负载均衡器无法全面掌握已发送到后端服务器的所有请求，这些场景可能会给传统负载均衡方法带来挑战。

容器化集群内部的负载均衡与横向扩展的主动-主动部署具有相同的特征。部署在副本集中的Kubernetes Ingress控制器包含多个Ingress资源实例，同样面临如何将负载有效分配到为集群中各项服务提供支持的Pod这一挑战。

受益于“随机二选一”负载均衡的集群拓扑

工作负载差异会显著影响分布式负载均衡的效果。当每个请求给后端服务器带来的负载相同时，可以通过衡量各服务器响应先前请求的速度，有效判断下一个请求应发送到哪台服务器。NGINX Plus独有的最短时间负载均衡方法正是采用这种方式。但当后端服务器的负载不断变化时（例如，同时包含读写操作），过去的性能并不能很好地反映未来的性能。

在分布式环境中实现负载均衡，最简单的方法是随机选择一台后端服务器。随着时间推移，负载会趋于均衡，但这种方法较为粗略，可能会不时导致流量突增并集中涌向个别服务器。

随机负载均衡有一种简单的变体，且已证实可以改善负载分布：随机选择两台后端服务器，然后将请求发送到负载较低的服务器。比较两个随机选项的目的是避免做出不当的负载均衡决策，即使最终决策并非最优。通过避开负载较高的后端服务器，每个负载均衡器都可以独立运行，同时避免流量峰值集中到个别后端服务器。因此，这种方法既具备随机负载均衡的优势和计算效率，又能实现经验证更优的负载分布。

NGINX Plus R16引入了两种新的负载均衡方法：Random和Random with Two Choices。对于后者，还可以进一步指定NGINX Plus要比较的负载指标，以决定将请求发送到选中的两个后端中的哪一个。下表列出了可用指标。

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

以下代码片段展示了使用random two指令的二选一随机负载均衡配置简单示例（HTTP、Stream）。

upstream my_backend {    zone my_backend 64k;
    server 10.0.0.1;
    server 10.0.0.2;
    server 10.0.0.3;
    #...
    random two least_time=last_byte; # Choose the quicker response time from two random choices
}

server {
    listen 80;
    location / {
        proxy_pass http://my_backend; # Load balance to upstream group
    }
}

请注意，二选一随机方法仅适用于多个负载均衡器将请求转发到同一组后端的分布式环境。当NGINX Plus部署在单台主机上或采用主动-被动部署时，请勿使用此方法。在这些情况下，单个负载均衡器可以全面掌握所有请求，使用轮询、最少连接和最短时间方法可获得更好的效果。

增强型UDP负载均衡

NGINX Plus R9新增了对UDP流量代理和负载均衡的支持，使NGINX Plus能够部署在DNS、syslog、NTP和RADIUS等常用UDP应用前端，为应用服务器提供高可用性和可扩展性。初始实现仅适用于客户端每次与服务器交互时只发送一个UDP数据包的UDP应用。

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

NGINX Plus是一款软件负载均衡器，可在同一实例上同时对UDP、TCP、HTTP和HTTP/2这4种常用Web协议进行负载均衡。

支持PROXY Protocol v2

NGINX Plus R16新增了对PROXY protocol v2（PPv2）标头的支持，并可检查标头中的自定义类型-长度-值（TLV）。

PROXY协议供NGINX Plus和Amazon负载均衡器等第7层代理使用，用于将连接信息传输到位于另一组第7层代理或NAT设备之后的上游服务器。之所以需要该协议，是因为代理转发连接时，源IP地址和端口等部分连接信息可能会丢失，而且并非总能通过注入HTTP标头来传输这些信息。旧版NGINX Plus支持PPv1标头；NGINX Plus R16新增了对PPv2标头的支持。

将PPv2与Amazon Network Load Balancer配合使用

One use case for the PPv2 header is connections that are relayed by Amazon’s Network Load Balancer (NLB), which may appear to originate from a private IP address on the load balancer. NLB prefixes each connection with a PPv2 header that identifies the true source IP address and port of the client’s connection. The true source can be obtained from the $proxy_protocol_addr variable, and you can use the realip module to overwrite NGINX’s internal source variables with the values from the PPv2 header.

将PPv2与AWS PrivateLink结合使用

AWS PrivateLink是Amazon用于创建通往虚拟私有云（VPC）的安全VPN隧道的技术。该技术通常用于发布在提供商VPC中运行的提供商服务，并将其提供给一个或多个客户端VPC。与提供商服务的连接源自提供商VPC中运行的NLB。

在许多情况下，提供商服务需要知道每个连接的来源，但PPv2标头中的源IP地址实际上没有意义，因为它对应的是客户端VPC中无法路由的内部地址。AWS PrivateLink NLB使用PPv2 TLV记录将源VPC ID添加到标头中：0xEA。

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

NGINX Plus R16 的其他新功能

OpenID Connect不透明会话令牌

The NGINX Plus OpenID Connect参考实现已扩展为支持不透明会话令牌。在此用例中，JWT身份令牌不会发送给客户端，而是存储在NGINX Plus键值存储中，并以随机字符串代替。当客户端提供该随机字符串时，系统会用它换取JWT并进行验证。由于键值存储中的条目现在可以设置超时值，并可在集群中同步，此用例已从原型/实验阶段升级为生产级。

加密会话动态模块

The Encrypted Session社区模块基于带MAC的AES‑256，为NGINX变量提供加密和解密支持。该模块现已在NGINX Plus存储库中作为受支持的NGINX Plus动态模块提供。

NGINX JavaScript模块增强功能

R16中的NGINX JavaScript模块扩展了JavaScript语言的支持范围。HTTP JavaScript模块经过简化，现在可通过单个对象（r）访问与每个请求关联的请求和响应属性。此前，请求对象（req）和响应对象（res）相互独立。经过此次简化，HTTP JavaScript模块与使用单个会话对象（s）的Stream JavaScript模块保持一致。此项更改完全向后兼容，现有JavaScript代码无需修改即可继续运行。不过，建议修改现有JavaScript代码以利用这一简化方式，并在今后编写的代码中采用该方式。

JavaScript语言支持现包括：

• 字符串方法：bytesFrom（）、padStart()和padEnd()
• 其他方法：getrandom() 和 getentropy()
• 二进制字面量

JavaScript模块的完整变更列表记录在变更日志中。

新增$ssl_preread_protocol变量

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

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

Kubernetes Ingress Controller 增强功能

NGINX Plus可管理各种环境中的流量，其中一个重要用例是充当Kubernetes Ingress负载均衡器。NGINX开发了一款Ingress控制器解决方案，可自动配置NGINX Plus，并为所有NGINX Plus订阅用户提供全面的集成支持。（所有NGINX Open Source用户和NGINX Plus客户均可在GitHub上找到开源实现，并且正式版本会定期发布。）

NGINX Plus可对Kubernetes流量执行SSL终止、路由和负载均衡

在NGINX Plus R16开发期间，官方NGINX Ingress Controller for Kubernetes新增了多项重要增强功能：

• Prometheus支持支持用户将NGINX和NGINX Plus指标直接导出到Kubernetes上的Prometheus。
• 支持Helm chart，可简化Ingress控制器的安装和管理。
• 支持对gRPC流量进行负载均衡，可为基于gPRC的应用提供高可用性和可扩展性。（在1.2.0版本中新增。）
• Kubernetes Pod主动运行状况检查可快速检测Pod故障和网络连接故障。
• 多租户、可合并的配置可实现关注点分离，让各团队独立管理同一Web应用的不同路径，同时由运维团队继续控制前端侦听器和SSL配置。
• 精细化JWT身份验证可按路径进行配置，从而更深入地控制富应用的身份验证。
• 直接管理配置模板，可大幅简化NGINX配置自定义更改的开发和测试。

可使用ConfigMaps（用于嵌入NGINX配置）或通过编辑基础模板进一步扩展NGINX Ingress Controller。这样，用户在为运行于Kubernetes上的应用创建流量管理策略时，便可使用NGINX的全部功能。

有关更多详细信息，请参阅博客文章《NGINX Ingress Controller for Kubernetes 1.3.0版发布公告》。

升级或试用NGINX Plus

NGINX Plus R16新增了集群功能、全局速率限制和一种新的负载均衡算法，并包含多项错误修复。如果您正在运行NGINX Plus，我们强烈建议尽快升级到R16。升级后可获得多项修复和改进，也有助于NGINX, Inc.在您需要提交支持工单时提供帮助。

升级前，请仔细查看本博文中介绍的新功能和行为变更。

如果您尚未试用过NGINX Plus，不妨亲自体验一下。它可用于Web加速、负载均衡和应用交付，也可用作获得全面支持的Web服务器，并提供增强的监控和管理API。立即开始30天免费试用，亲自了解NGINX Plus如何帮助您交付应用并实现扩展。

关于作者

Liam Crilly产品管理高级总监

Liam Crilly 的更多博客文章