在之前的博文中，我们介绍了 实时 API 在我们日常生活中的重要作用。随着企业寻求提升在数字时代的竞争力，API 成为了重要的 IT 和业务资源。构建正确的底层基础架构不仅可以确保 API 稳定安全，而且还可以确保这些 API 满足实时 API 标准，即能够在 30 毫秒（ms）内端到端处理 API 调用。
API 架构大体上可分为两个部分：数据平面（即API 网关）和控制平面（包括策略和开发人员门户服务器）。实时 API 架构主要取决于 API 网关。作为处理 API 流量的代理，API 网关是性能链中的关键一环。
API 网关可执行各种功能，包括验证 API 调用、将请求路由到正确的后端、应用速率限制以防止系统超载，以及处理错误和异常。决定实施实时 API 后，您是否考虑过 API 网关架构的主要特征？以及您如何部署 API 网关？
本文将为您解答这些问题，并提供一个我们从与 NGINX 的几家大型高需求客户的合作经验中提炼出来的实时 API 参考架构。我们将对 API 管理解决方案进行全面描述，深入介绍负责确保满足实时性能阈值的 API 网关。.
实时 API 参考架构
我们的实时 API 参考架构主要包含六个组件：
- API 网关。一个快速的轻量级数据平面组件，用于处理 API 流量。这是实时架构中最关键的一个组件。
- API 策略服务器。一个解耦的服务器，用于配置 API 网关以及提供 API 生命周期管理策略。
- API 开发人员门户。一个解耦的 Web 服务器，为使用 API 的开发人员提供快速入门文档。
- API 安全服务。一个独立的 Web 应用防火墙 (WAF) 和欺诈检测组件，在 API 网关内置的基本安全机制之上增添了一层防护。
- API 身份服务。一项独立的服务，为身份和访问管理设置身份验证和授权策略，并与 API 网关和策略服务器相集成。
- DevOps 工具。一个独立的工具集，用于将 API 管理集成到 CI/CD 和开发人员流水线中。
当然，实时 API 参考架构还可能包含 API 用户、API 端点以及路由器、交换机、虚拟机和容器等各种基础架构组件。这些都按需包含在参考架构中，作为企业中的常见基础架构，本文对它们不再赘述。我们将重点介绍对创建全面实时 API 架构来说必不可少的上述六个组件。
API 网关
当部署在微服务架构中时，API 网关的功能包括请求路由、身份验证、TLS 终止、速率限制和服务发现。为确保高可用性，需要部署 API 网关集群来管理每个开放 API 的应用的流量。为有效分配 API 流量，需要在集群的前端部署一个负载均衡器。负载均衡器根据位置（接近客户端应用）或处理 API 的能力来选择 API 网关。API 网关会将请求转发给后端。为了获得最佳性能，请遵循下方“实时 API 网关特征和架构指南”一节中详细介绍的最佳实践。
API 策略服务器
这是控制平面，允许开发人员和 DevOps 团队定义、发布和保护 API，并允许 IT 运营团队监控和分析 API。API 策略服务器可用于配置到后端服务的请求路由，并配置细粒度的访问控制策略，以指定用户对已发布 API 的访问权限（例如只读和读写）以及允许使用资源的用户或客户端应用类型。
此外，API 策略服务器还可用于配置 API 网关以及所有需要被暴露出来使用的 API。为了获得实时性能，该组件必须与处理 API 流量的 API 网关数据平面完全分离（请参见图 2）。如果数据平面依赖策略服务器进行身份验证、速率限制以及将每个 API 调用路由到相应的后端，那么由 API 用户发起的 API 调用将需要经过此控制平面（在某些情况下还会经过相关的数据库），这会因额外开销而导致延迟增加。
API 开发人员门户
该组件可帮助使用您 API 的开发人员快速入门。开发人员门户（或“开发门户”）提供了所有已发布的 API 的目录、每个 API 的文档以及示例代码。为了提高性能和可用性，开发人员门户与控制平面分离开来，并分别托管在各自的 Web 服务器上。分布式开发人员门户允许多个实例跨不同云、地理位置或可用区域分布。这可以提高开发人员的访问能力，而且由于它已与数据平面解耦，因此不会影响 API 调用的处理效率。
API 安全服务
API 的安全通常需要使用高级 Web 应用防火墙 (WAF) 来检测各种攻击。它必须提供高可信签名，并且能够避免由于 JSON 格式错误、空请求或不符合 gRPC 协议的请求而出现的漏洞。它需要支持高级 API 安全防护，包括路径执行、方法执行、数据类型验证和完整模式验证。该组件需要为网关集群和负载均衡器提供保护。
许多组织还部署了 API 欺诈检测组件，以更深入地了解 API 调用的逻辑，从而确定其是否为恶意或异常调用。欺诈检测通常是一项独立功能，但也可以绑定到 API 网关或 WAF 层中进行实施。
请务必注意，API 安全防护会难以避免地引入延迟，这可能会导致 API 处理用时超过实时 API 性能阈值 30 毫秒。在 API 的安全性与绝对性能之间，我们建议组织评估哪个更为重要。我们之所以在该参考架构中引入 API 安全防护，是为了提供边缘或外围安全设备可能无法提供的 API 特定防护。
API 身份服务
该组件提供访问和授权策略来保护 API 和后端资源。我们建议的最佳实践是集成领先的身份管理提供商（例如 Okta 和 Ping Identity）的产品，以确保对 API 的安全访问。这些解决方案支持您创建和管理访问策略，根据最终用户和客户端应用属性来决定开放或阻断访问。
就本参考架构而言，我们的假设是此类身份服务已经被部署好了，这里只是为了全面介绍 API 架构才提及它们。
DevOps 工具
必须提供声明式 API 接口以实现全面的 API 生命周期管理，包括创建、发布、网关配置和监控。这支持自动创建 API 和更改网关配置。通过与自动化平台（例如 Ansible）和 CI/CD 工具箱（例如 Jenkins）无缝集成，可以加快 API 的发布速度。
尽管这种形式的自动化本身不会影响 API 调用的处理性能，但对于确保变更的快速以及变更成为开发过程中的一部分至关重要。如果发生会影响性能的问题，例如 DDoS 攻击或 API 客户端配置错误，CI/CD 集成可确保您快速解决问题并重新配置 API 网关，以将性能恢复到可接受的水平。
实时 API 网关特征和架构指南
NGINX 已经与来自金融服务、零售、娱乐和软件行业的一些大型组织合作并为其构建了 API 架构。这些客户的架构规模已扩展到了每月需要处理数千亿次API调用，并且所有调用的延迟均不到 30 毫秒。通过与这些客户的合作，我们总结了以下六个 API 网关最佳实践，它们是我们实时 API 参考架构的基础。
部署高可用性 API 网关
为了确保快速响应，首先必须保证 API 网关能够正常运行。您必须使用 API 网关集群来提高可用性。一个包含两个或多个 API 网关的集群可提高 API 的可靠性和弹性。必须提供一种机制在所有网关之间共享运行状态（例如速率限制），以便能够实施一致有效的控制。
对于 API 网关进行身份验证但不授权
身份验证是指验证用户或调用实体是否是其声称的身份。授权是指确定授予用户哪些特权或访问级别。
授权需要进行额外处理（通常使用 JSON Web Token (JWT)），以确定客户端是否有权访问特定资源。例如，一款电子商务应用可能向所有客户授予对产品和价格信息的只读权限，但仅向部分用户授予读写权限。考虑到这种细粒度的访问控制，最好由处理 API 调用本身的后端服务执行授权，因为它具有关于请求的必要上下文。API 网关将授权委派给后端业务逻辑层后，无需再执行查找操作，因此可缩短响应时间。API 网关仍然可以执行此功能，但可能会影响实时性能。
支持动态身份验证
在网关中预配置身份验证信息（无论使用 API 密钥还是 JWT）可以极大地减少运行时的额外查找。因此，身份验证几乎瞬间即可完成。
带熔断器的快速失败 (Fail Fast) 机制
实施熔断器可防止级联故障。我们来举例说明一下——假设某个 API 调用由包含多个微服务的后端处理。其中一个微服务，我们称之为微服务 A，用于执行数据库查找。当数据库查找失败时，微服务 A 需要很长时间才能返回错误。这会严重影响当前 API 调用以及后续 API 调用时的 API 响应时间。
熔断器可有效解决这个问题。设置指定时间内可以发生的故障次数限制。当超过该阈值时，电路跳闸，后续所有调用都会立即出错。任何客户端应用或用户都不会因资源耗尽而被挂起。
不要在 API 网关层执行转换
数据转换（例如将 XML 格式的请求有效负载转换为 JSON）往往需要大量的计算。我们可将此工作分配给另一个服务。在 API 网关执行转换会大幅增加 API 调用的延迟。
尽可能使用 gRPC
gRPC 是 Google 推出的一个现代开源远程程序调用框架，因其广泛的语言支持和简单的设计受到越来越多用户的欢迎。gRPC 依赖于 Protocol Buffer，Google 称之为“用于序列化结构化数据的语言中立且平台中立的可扩展机制”。由于 gRPC 使用 HTTP/2 作为传输协议，因此它自动继承了 HTTP/2 的所有优点，例如数据压缩和 TCP 连接上的多路复用请求。多路复用技术允许客户端和服务器通过单个 TCP 连接并行发送多个请求和响应。HTTP/2 还支持服务器推送，它允许服务器抢先将资源推送到客户端，并预期客户端可能很快会请求这些资源。在客户端请求资源之前进行推送有助于减少往返的延迟。这些特性可加快对客户端应用的响应速度并提高网络利用率。
NGINX 可提供哪些帮助？
NGINX Plus 专为实时交付 API 而设计。它支持：
- 高可用性集群，允许共享状态信息，例如集群中所有实例的速率限制。
- 使用 API 密钥和 JWT 进行身份验证。
- NGINX Plus 键值存储中的内存 SSL/TLS 证书存储。此技术可用于预配置授权信息，例如 API 密钥或 JWT。
- gRPC。
高性能也是 NGINX API 管理解决方案的一个基本特性。与传统 API 管理解决方案不同，NGINX API 管理解决方案的数据平面（NGINX Plus 作为 API 网关）对控制平面（NGINX Controller API 管理模块）无运行时依赖性。由于 API 调用必须跨数据库、模块和脚本，因此紧密耦合的控制和数据平面会显著增加延迟。通过将数据平面和控制平面相分离，可以缩短对 API 调用的平均响应时间，从而降低复杂性并最大限度提高性能。
NGINX App Protect 是一种可提供企业级安全性的 DevOps 友好型 WAF，可以为 API 网关和负载均衡器提供安全防护。NGINX Plus 作为多合一负载均衡器、反向代理和 API 网关，可确保高可用性和高性能，同时降低复杂性和工具蔓延。
您能否提供实时 API？您可免费下载我们的电子书《NGINX 实时 API 手册》，或则 联系我们的 API 专家，申请免费评估 API 性能。
