ProgrammableWeb 的 API 目录自 2005 年以来一直在跟踪外部可用的 API，这个数字在 2019 年 6 月突破了 22,000 大关。在此之前的 4 年里，发布的 API 数量增长了近 60%，这表明 API 经济不仅增长强劲，而且还将持续下去。
API 是许多业务的核心，能够创造巨大的价值和收入。现在，IT 组织要想保持领先，就必须找到一种管理和控制 API 访问的方法，而且这一需求比以往任何时候都迫切。
API 管理的重要性
随着企业开始从单体应用过渡到基于微服务的应用，他们还意识到 API 不仅可以促进高效的数字化通信，还可以成为新的收入来源。例如，Salesforce.com 有一半以上的年收入来自其 API，而 Expedia.com 有近 90% 的收入依赖于 API 经济。
兹事体大，企业不能容忍其 API 架构出现任何闪失，他们必须要确保 API 具备出色的性能、可控性和安全性。
API 网关 ≠ API 管理
虽然“API 网关”和“API 管理”这两个词语有时被互换使用，但要注意其中的区别。
API 网关是 API 访问权限的“门卫”，负责保护和管理 API 使用者与暴露这些 API 的应用之间的流量。API 网关通常负责处理身份验证和授权、请求路由、速率限制以避免系统过载、防护 DDoS 攻击、卸载 SSL/TLS 流量以提高性能以及处理错误或异常。
而 API 管理是指在 API 的整个生命周期内管理 API 的过程，包括定义和发布 API、监控 API 性能、分析使用模式以创造最大业务价值等。
常见的 API 网关部署模式
那么，如何才能有效交付 API 呢？
作为全球首屈一指的 API 网关，NGINX 交付了当今网络上超过一半的 API 流量。虽然模式没有对错之分，但有一些 API 网关模式是最常用的，我们在此进行了总结。
集中式边缘网关
这是最常见的 API 网关模式，采用了传统的应用交付控制器 (ADC) 架构。在这种模式下，网关几乎可以处理所有事情，包括：
- SSL/TLS 卸载
- 身份验证
- 授权
- 请求路由
- 速率限制
- 请求/响应操作
- Facade 路由
当从集中治理的单体应用暴露应用服务时，这种方法非常合适，但对于微服务架构或是总有频繁更改的情况就差点意思了 —— 传统边缘网关都是针对南北向流量进行优化，并不能高效处理分布式微服务环境中产生的大量东西向流量。
双层网关
随着服务逐渐变得小型化和分散化，许多企业转向了双层（多层）网关模式，将多个网关的角色分离开来。
这种方法将安全网关作为第一层，以管理：
- SSL/TLS 卸载
- 身份验证
- 集中式连接和请求日志记录
- 跟踪注入
将路由网关作为第二层，以处理：
- 授权
- 服务发现
- 负载均衡
在一些情况下，我们需要考虑分散的 service 的灵活性和功能独立扩展的需求。双层网关模式最适合这样的情况。但是，当有多个团队管理不同的环境和应用时，这种方法可能会带来问题，因为它不支持分布式控制。
微网关
微网关模式建立在双层网关方法之上，为各个 DevOps 团队提供了专用网关，这不仅可以帮助他们管理 service 之间的流量（东西向流量），而且还支持在不影响其他应用的情况下进行变更。
此模式在边缘提供了以下功能：
- SSL/TLS 卸载
- 路由
- 速率限制
然后企业再为每个 service 添加独立的微网关，以管理：
- 负载均衡
- 服务发现
- 每个 API 的身份验证
尽管微网关的设计初衷是与微服务协同工作，但它们也为实现一致性和可控性增加了阻力。每个微网关可能都有一组不同的策略和安全规则，并且需要整合多个 service 的监控信息和指标。微网关很容易适得其反 —— 原本是为了尽量“小”，结果却往往需要根据业务目标实施全量的 API 配置。
per-pod 网关
per-pod 网关模式将代理网关嵌入到了各个 pod 或容器中，从而完善了微网关模式。网关负责管理到 pod 的入向流量，应用了身份验证和速率限制等策略，然后将请求传递到本地微服务。
per-pod 网关模式不执行任何路由或负载均衡，因此通常与上文提到的任一模式结合部署。具体来说，您可能会使用 per-pod 网关执行以下部分或全部功能：
- pod 中应用的 SSL/TLS 卸载
- 跟踪和指标生成
- 身份验证
- 速率限制和队列
- 错误处理，包括断路器式的错误消息
per-pod 网关通常是轻量级的，并且其配置是静态的。它仅将流量转发到本地微服务实例，因此当应用拓扑发生变化时不需要进行重新配置。如果需要更改其中一项策略，则可以使用新的代理配置重新部署微服务 pod。
Sidecar（边车）网关和 service mesh（服务网格）
Sidecar 网关模式将网关部署为微服务的出入向代理，这允许 service 直接进行相互通信，sidecar 代理则负责处理和路由入站和出站的通信。
此模式使用边缘网关管理：
- SSL/TLS 终止
- 客户端身份验证
- 集中 logging
- 跟踪注入
然后使用 sidecar 代理作为每个 service 的入口点，以提供：
- 出站负载均衡
- 服务发现集成
- 服务间身份验证
- 授权
sidecar 模式显著增加了控制平面的复杂性，因为它只有在了解到整个应用拓扑后才能根据需要执行出站路由和负载均衡，然而应用拓扑却经常有变更。此外它还增加了数据平面的复杂性，因为 sidecar 代理必须透明地拦截来自本地应用的所有出站请求。该模式在基于 sidecar 的 service mesh 模型上最容易实现，此类 service mesh 提供了 sidecar 代理、注入、流量捕获以及模式所需的集成式控制平面。sidecar 代理模式正逐渐成为 service mesh 中最流行（尽管仍需完善）的方法，对从 service mesh 控制平面配置各个代理的多个团队实现基于角色的访问控制。
NGINX 支持有效的 API 交付
如今，技术是实现创新、增长和盈利的主要差异化优势。API 是现代数字业务发展的“核心驱动”，支持企业访问服务和数据，从而为客户、内部用户和合作伙伴提供更出色的体验。您拥有的 API 越多，使用合适的现代 API 管理解决方案来简化、扩展和保护 API 就变得越重要。
NGINX 提供了快捷的 API 管理解决方案，将 NGINX Plus 作为 API 网关的卓越功能和性能与 NGINX Controller 相结合，使团队能够在多云环境中大规模定义、发布、保护、监控和分析 API。
阅读我们的系列博文《将 NGINX 部署为 API 网关》，了解不同用例的详细配置、如何保护生产环境中后端 API 服务的安全以及如何将 NGINX 开源版和 NGINX Plus 部署为 gRPC 服务的 API 网关。
