既然软件负载平衡器是现代DevOps驱动的组织中的标准，那么我们为自己创造了什么新的挑战呢?我们如何应对“代理扩张”的复杂性?我们可以在不损害性能、稳定性和功能的情况下进行整合吗?

web和应用程序交付领域的大多数专业人士都熟悉硬件应用程序交付控制器(ADC)市场的发展轨迹。硬件adc开始是智能的、负载均衡的路由器，并迅速发展成为交付高流量或业务关键应用程序的标准方式。

在不断增加收入的压力下，硬件ADC厂商将一个又一个特性捆绑到他们的设备中——SSL VPN?虚拟桌面代理吗?链路负载均衡?当然，我们可以做到!硬件设备变得越来越复杂和笨重，用户发现拥有和操作这项基本技术的成本越来越高。

在现代企业中，软件正在取代硬件adc

随着硬件adc在自身的重压下开始崩溃，DevOps团队转向重量更轻的软件替代品，以满足他们的应用程序交付需求。基于软件的解决方案使用熟悉的开源技术——NGINX反向代理、ModSecurity web application firewall (WAF)、Varnish缓存、HAProxy负载均衡器——取代了硬件替代品。软件可以在每个应用程序的基础上轻松有效地部署，直接控制应用程序所有者，并支持DevOps团队支持的敏捷交付过程。

如果你调查一下这些部署中的一种，你会发现类似的情况并不少见:

应用程序团队为他们的应用程序创建复杂的应用程序交付层

软件生态系统充满了针对DevOps工程师所面临的每个问题的单一目的和点解决方案。每个新的用例都使用构建在反向代理上的一组新的解决方案来解决。例如，API网关产品的出现是因为需要管理API流量、应用路由、身份验证、速率限制和访问控制策略来保护基于API的服务。

软件必须超越点解决方案

点解的爆炸式增长显然给DevOps工程师带来了一个问题。他们必须熟悉部署、配置、更新和监视每个解决方案的过程。故障排除变得更加复杂，特别是当问题产生于不同解决方案之间的交互时。

历史似乎在重演:就像特定用途的硬件设备的激增导致了在单个ADC上整合许多功能一样，DevOps团队现在需要通过将软件功能整合到一个平台上来降低复杂性和简化他们的基础设施。但是这一次，避免以前使用硬件负载平衡器所犯的错误是很重要的。如果统一的解决方案性能不佳，操作复杂，或者在每个应用程序的基础上部署成本高得令人望而却步，那么它就没什么用。

使用NGINX和NGINX Plus合并应用程序交付堆栈

大多数DevOps工程师已经非常熟悉NGINX，这是一个开源web服务器和反向代理，它提供了世界上最繁忙的网站，比任何其他解决方案都多。

组织使用开源NGINX构建各种特定的解决方案，从分布式内容交付网络(CDNS，如CloudFlare、CloudFront和MaxCDN)到本地API网关。NGINX也是许多开源和商业点解决方案的核心，包括商业负载平衡器和来自Kong和3scale的API网关。

NGINX Plus是由开源NGINX背后的团队开发的。它通过将多个功能(身份验证、反向代理、缓存、API网关、负载平衡等等)合并到一个软件平台中，从而消除了对复杂的点解决方案链的需求。它可以很容易地通过认证模块进行扩展，以添加WAF(带有用于ModSecurity、hidden Security和Wallarm的模块)、高级身份验证(Curity、Forgerock、IDFConnect、Ping Identity)和可编程性(NGINX JavaScript、Lua)等功能。

NGINX Plus整合了SSL、WAF、缓存、API网关、负载平衡等功能

变成一个单一的平台

NGINX Plus对DevOps工程师的好处远远不止于功能的整合。丰富的RESTful API提供了对NGINX Plus及其负载平衡后端服务器的健康状况和性能的深入了解。动态重新配置和服务发现集成简化了NGINX Plus在云或Kubernetes等流体环境中的操作。NGINX Plus中的集群功能使您能够以可靠的HA方式跨集群分发流量和共享运行时状态。

在不损害性能的情况下实现整合

建立在开源NGINX之上的第三方解决方案不具备NGINX附加功能、api和集群的优势。此外，许多解决方案依赖于第三方语言(Lua是最流行的)来实现它们的附加功能。Lua是一种非常强大的语言，但它对NGINX造成了不可预测的性能损失，这在很大程度上取决于第三方扩展的复杂性。

NGINX Plus不会损害开源NGINX的高性能或轻量级特性。核心NGINX Plus二进制文件的大小只有1.6 MB，能够在工业标准硬件上每秒处理超过100万次请求、70 Gbps吞吐量和65,000个新的SSL事务，具有现实的、生产就绪的配置。新的功能是由核心的NGINX团队在过程模块中实现的，就像在开源的NGINX中一样，因此您可以确保每个特性的性能、稳定性和质量。

API网关用例

DevOps团队可以使用NGINX Plus来满足许多用例，API gateway就是一个突出的例子。下表显示了NGINX Plus作为API网关如何满足管理来自外部源的API请求并将其路由到内部服务的许多需求。

作为一个统一的解决方案，NGINX Plus还可以轻松地管理web流量，在协议(HTTP/2和HTTP、FastCGI、uwsgi)之间进行转换，并提供一致的配置和监视接口。NGINX Plus足够轻量级，可以部署在容器环境中，或者作为一个资源占用最少的sidecar。

使用NGINX Plus增强API网关解决方案

开源NGINX最初是作为HTTP (web)流量的网关开发的，其配置的基本类型是用HTTP请求表示的。这些与您期望配置API网关的方式相似，但并不相同，因此DevOps工程师需要了解如何将API定义映射到HTTP请求。

对于简单的api，这很简单。对于更复杂的情况，我们最近的三部分系列博客描述了如何将一个复杂的API映射到NGINX Plus中的服务，然后处理许多常见的API网关任务:

1. 重写API请求
2. 正确应对错误
3. 管理用于访问控制的API密钥
4. 检查JWT令牌以进行用户身份验证
5. 速度限制
6. 强制执行特定的请求方法
7. 应用细粒度访问控制
8. 控制请求的大小
9. 验证请求的身体
10. 路由、验证、检查和保护gRPC流量

• Rewriting API requests
• Correctly responding to errors
• Managing API keys for access control
• Examining JWT tokens for user authentication
• Rate limiting
• Enforcing specific request methods
• Applying fine‑grained access control
• Controlling request sizes
• Validating request bodies
• Routing, authenticating, checking, and protecting gRPC traffic

结论

由于DevOps团队严重依赖软件组件来交付和操作他们的应用程序，硬件adc已经被边缘化。开源NGINX被认为是大多数应用程序交付栈的关键部分。

许多软件组件的单一用途或点解决方案功能可能导致多层应用程序交付堆栈。尽管这些栈是由“最好的”组件构建的，但是操作起来很复杂，很难排除故障，并且具有不一致的性能和可伸缩性。NGINX Plus将此功能聚合到一个软件平台上。

NGINX Plus可以应用于各种各样的问题，比如API交付，使用经过验证的、熟悉的、不影响性能或稳定性的技术。

原文：https://www.nginx.com/blog/consolidating-your-api-gateway-and-load-balancer-with-nginx/

本文：

讨论：请加入知识星球或者小红圈【首席架构师圈】