选择合适的 API 网关模式，实现有效的 API 交付

原文作者：Elle Poole Sidell of F5

原文链接：选择合适的 API 网关模式，实现有效的 API 交付

转载来源：NGINX 官方网站

---

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

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 代理则负责处理和路由入站和出站的通信。

此模式使用边缘网关管理：

如欲了解本文后续内容，请点击《选择合适的 API 网关模式，实现有效的 API 交付》查看后续内容。

---

NGINX 唯一中文官方社区 ，尽在 nginx.org.cn

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源：

• 开源社区官网：https://www.nginx.org.cn/
• 微信公众号：https://mp.weixin.qq.com/s/XVE5yvDbmJtpV2alsIFwJg