应对 API 泛滥的五种方法（以及为何应当关注 API 泛滥问题）

Rajesh Bavanantham of F5

NGINX 产品管理总监

Veena Raja Rathna of F5

高级产品经理

Andrew Stiefel of F5

产品营销经理

2022-08-17

本篇是有关 API Connectivity Manager 的系列博文（共两篇）的第一篇：

应对 API 泛滥的五种方法（以及为何应关注 API 泛滥）——本篇

API 开发人员体验为何至关重要（即将发布）——第二篇

API 是现代互联网的结缔组织，能够将数据从边缘连接回云端和本地数据中心。根据 F5《2021 年应用策略现状报告》，利用 API 是最受组织青睐的现代化改造方法：

58% 的受访组织添加了一层 API 以启用现代接口
51% 的受访组织选择添加现代应用组件（例如 Kubernetes）
47% 的受访组织选择采用重构的方法（修改应用代码本身）
40% 的受访组织正在向公有云迁移（直接迁移上云），而没有进行现代化升级

在 API 驱动的经济中，API 必须完全可靠。但随着业务和应用的不断扩展，运营复杂性大幅增加。从设计上来看，云原生应用的分布式和去中心化特征愈发明显，其数十、数百甚至数千个 API 无序地分散在云端、本地和边缘等多种环境中。

根据 F5 首席技术官办公室最近的研究，API 持续泛滥对正在进行数字化转型的企业构成重大威胁。但这又意味着什么呢？

什么是 API 泛滥？

“API 泛滥”描述了随着组织数字化转型而出现的两个相互交织的问题：API 数量的激增，以及 API 跨多个架构和团队的散乱分布。

API 泛滥的四大驱动因素：

混合基础架构——当今 81% 的企业跨三种或更多架构运营，包括公有云、本地数据中心和边缘基础架构。
微服务架构——随着新服务的不断上线，微服务架构的日益普及导致 API 端点激增。
持续的软件部署——开发人员可以在短时间内快速开发出数十个 API 或某个 API 的多个版本。
被遗弃的 API——当开发人员转而支持和处理其他项目时，他们会停止管理和维护之前创建的 API。

API 泛滥构成重大威胁

API 泛滥已成为重大问题，尽管这是个不争的事实，但许多企业仍未意识到。要想在未来十年内取得长足发展，企业必须了解并解决 API 泛滥的根本原因。

API 泛滥给企业带来了巨大的运营和安全挑战。随着跨多个团队和环境的 API 端点的激增，API 的防护和管理成为一项严峻的挑战。对于企业而言，API 泛滥通常会带来隐性成本，包括降低开发人员的工作效率、增加返工、减慢审查速度，这类成本很难衡量，等察觉时往往为时已晚。

API 泛滥的主要挑战包括：

无法可视化——在混合架构中，很难通过统一视图查看 API 流量和配置
缺乏明确的事实来源——开发人员难以查找 API 和最新文档
降低的可靠性——错误配置变得更加普遍，容易造成业务中断
加剧的安全威胁——不安全的 API 端点很容易成为攻击目标

如何应对 API 泛滥？

构建弹性 API 基础架构的第一步是，借鉴有关持久 API 所有权和集中式 API 或服务目录的最佳实践，运用整体 API 策略来控制 API 泛滥。接下来，实施 API 管理，以实用且可扩展的方式来简化 API 生命周期管理。

为降低 API 管理的复杂性，NGINX 专门构建了一款管理平面解决方案。API Connectivity Manager 是 F5 NGINX Management Suite 的一部分，提供了一个统一界面来连接、管理和保护 API，无论它们位于何处或由谁构建。

借助 API Connectivity Manager，您可通过执行以下五大策略，有效应对 API 泛滥和大规模管理 API：

实施 API 管理策略
为 API 创建单一事实来源
确保适当的版本控制和文档维护
提供指标和可视化
大规模应用 API 保护

策略 1：实施 API 管理策略

集中管理和控制支持您在单个架构或集群中更轻松地发现、连接和保护 API。API 泛滥问题需要您调整思考方式，将纯粹的分层模型调整为分布式自主扩展模型。

NGINX 可如何提供帮助——借助 API Connectivity Manager，您可以实施灵活的管理模型，在全局策略和细粒度控制之间取得平衡，以便 API 所有者可以管理本地策略。这有助于加快上市时间，同时又不影响以一致的方式对安全性和合规性进行监督。

平台和基础架构团队可通过日志记录、错误响应代码、TLS 配置等全局策略来确保整个企业的 API 一致性。构建和管理 API 的开发人员保留对速率限制、身份验证和授权等服务级别策略的控制权。

策略 2：为 API 查找创建单一事实来源

随着 API 数量和应用复杂性的增长，查找和跟踪可用 API 及其位置变得极其困难。如果 API 隐藏在特定微服务的基础架构中并且未注册，那么负责其他微服务的团队将无法找到这些 API，也无法将其集成到自己的项目中。

NGINX 可如何提供帮助——借助 API Connectivity Manager，您可以创建服务目录和 API 门户，以方便开发人员查找和使用 API。通过在一个集中位置提供有关可用 API 及其使用方法和证书生成工具的信息，打造良好的开发人员门户体验，从而推动 API 的使用。

策略 3：确保适当的版本控制和文档维护

创建用户友好的 API 门户是很好的第一步。然而，当 API 规范在开发周期中发生变化时，就会出现问题。这意味着调用 API 的远程服务也需要更改。如果所有微服务均由同一个团队为同一款应用设计，那么这种方法可能会奏效，但如果 API 是供第三方使用，则无济于事。

同时，文档维护也是一个令开发人员头疼的问题。经过最初的高频使用期，API 门户通常会被束之高阁，充斥着大量不受支持的 API 和过时的文档，给利益相关者和 API 用户带来极大不便和挫败感。

NGINX 将如何提供帮助——借助 API Connectivity Manager，您可以将 API 发布和文档集成到 API 开发人员的无缝工作流中。API 所有者可同时发布 API 并使用 OpenAPI 规范生成文档，从而节省时间并确保每个人都能获取最新文档。

策略 4：提供 API 流量指标和可视化

了解 API 位置及其配置方式是企业面临的最大挑战之一。如果无法以统一的视角查看各种环境中的 API 流量——即使这并非不可能——也很难识别性能问题和安全威胁。

NGINX 可如何提供帮助——借助 API Connectivity Manager，您可通过创建一个统一平台，轻松访问重要指标，从而加快实施最佳实践并确保性能和可靠性。基础架构所有者可以监控 API 流量和配置，执行标准化日志格式，并将数据导出到其首选的监控解决方案。

策略 5：大规模应用 API 保护

超过 90% 的企业在 2020 年遭遇过 API 安全事件。贵组织的威胁面会随着每个新 API 端点的上线而扩大。大规模安全保护不能只是一项附加-特性，必须构建到从规范到代码再到部署的整个生命周期中。

NGINX 可如何提供帮助——借助 API Connectivity Manager，您可以使用两大 API 安全组件来保护 API：API 访问控制和 API 保护。通过 OpenID Connect 使用 JSON Web 令牌 (JWT)、API 密钥或 OAuth 管理身份验证和授权，执行 API 访问控制。在接下来的几个月里，API Connectivity Manager 将增加对 NGINX App Protect WAF 的支持，届时您将能够利用可开箱即用 OWASP API Security Top 10 防护、模式验证等特性，来保护 API 网关并防御常见和高级威胁。