NGINX 唯一中文官方社区，前往 nginx.org.cn。

据行业分析机构 451 Group 指出，目前企业拥有的 API 的平均数量超过 15,000 个。显然，这一数字远高于平台运营团队可以用电子表格跟踪的 API 的平均数量。即使将 API 跟踪的责任分配给各个业务部门，考虑到 API 数量的惊人的增长速度，这仍然是一项艰巨的任务。

2021 年，F5 工程师和技术专家 Rajesh Narayanan 为这个问题创造了一个新词：API 蔓延（API sprawl）。“API 蔓延”一词的含义正如其名——即世界各地的企业中的API数量的加速增长，而这也给 API 的管理和防护带来了巨大挑战。这一问题有多严重？据 Narayan 估计，到 2030 年，全球部署和运行的 API 将超过 10 亿个。

现代应用在开发方式方面的变化加速了 API 的蔓延。微服务的兴起、用于系统内部通信的 API 的不断增加，以及多云和混合云架构的快速增加，都使得我们需要更多地使用 API 在应用之间进行通信。例如，作为容器编排的事实标准的 Kubernetes 就是使用 API 来实现所有的内部通信的。新的基础架构类型（如 severless 架构）也意味着 API 可以在几乎所有环境中运行。同时还有更多种类的 API 技术需要管理——REST、GraphQL 和 gRPC 都已被广泛使用，而更多的 API 查询协议也将很快出现。

更糟糕的是，网络罪犯绝对会乐于见到 API 蔓延。他们越来越多地将 API 作为他们精确攻击的目标，原因是 API 通常没有得到仔细的管理，而且默认配置的访问权限相对开放。

为了消除这种问题，必须以程序化、规模化的解决方案来应对 API 管理、发现和防护方面的挑战。不过在您能够有效应对 API 蔓延之前，您需要先了解该问题在您的组织机构中的严重程度。以下六个明显迹象表明您遇到了 API 蔓延问题。

API 蔓延的典型症状是不知道在所有环境中都运行着哪些 API，这通常是由于松散的 API 管理策略导致的——在这种策略下，团队无需注册仅在内部使用的 API（即所谓的“影子 API”）。

您的首要任务是准确盘点现有的 API。但由于 API 的添加和弃用通常极为频繁，想要“准确盘点”就需要不断地进行统计。合理的解决方案是通过编程式的方式进行盘点并持续进行 API 发现，类似于网络扫描和资产发现。

从理论上讲，结构化的 API 审批流程也有所助益。但在现实中，对于 API 创建和版本管理等任务，不断“左移”的企业会想要缩减繁重的审批流程。对于这些企业来说，将 API 清单盘点作为 CI/CD 的一部分来构建流程通常是一种很好的方法，尤其是当 API 用于微服务和其他更现代的应用架构时。

在现代基础架构环境中，仅仅知道 API 的存在还远远不够——还需要知道每个 API 的位置。端点可能会在不同基础架构形式的容器间互为镜像——横跨多个云平台、在混合云中，或者在像是 serverless 这样的多种服务中。

安全团队需要掌握 API 的位置信息，从而正确配置策略和防护措施并运行 API 安全测试。如果您需要在多个环境中运行 API，这也会影响您对于 API 网关和其他 API 流量管理方式的选择。理想情况下，您会希望有一个适用全局的 API 网关解决方案，以便能够在不同环境中实现具有一致性的 API 流量管理和防护。

如果您不知道 API 由谁负责，当 API 出现问题时，就不知道该找谁处理。通常情况下，当构建 API 的人或团队调岗或者离职时，那些对于平稳运营来说不可或缺的 API 就会成为“孤儿”。有时，API 所有权的转移非常明确——但更常见的情况是，这个过程会被跳过或通过非正式手续完成。

为每个 API 分配所有权是清单盘点过程的一部分，它至关重要，因为这样可以确立问责制，帮助责任人合理地管理和防护他们负责的 API。

当多个团队有相似但不完全相同的需求，通常会发生任务重合的情况，而且有人会说：“我们会通过构建自己的 API 来满足我们的需求，这样，我们就可以掌控自己的命运！”

但是，拥有多个类似 API 会增加不必要的技术债务。因此，衡量有多少应用或服务需要使用 API，并将其作为关键性能指标 (KPI) 之一非常重要。跟踪这些指标有助于最大程度地提高每个 API 的可重用性。整合 API 的另一种方法是转换到像是 GraphQL 一类的更灵活的形式。

文档对于经验传递、新员工入职培训和组织弹性至关重要。可惜的是，编写和维护文档通常是工程师最痛恨的事情。

过时的 API 文档通常表明 API 正在蔓延——因为这说明团队创建和更新 API 的速度太快，所以没时间更新文档——或者他们可以看似合理地这么解释他们不更新文档的行为。在最坏的情况下，过时的文档标示着其中提到的 API 是无人维护的孤儿。

庆幸的是，API 往往有清晰定义的结构，使其易于理解。良好的 API 管理解决方案通常包含一个工具，用于帮助开发人员根据 API 规范自动生成文档。最常见的例子之一是 OpenAPI 规范。它使用标准格式来描述 API，这样，人类和计算机就可以在无需访问源代码或其他文档的前提下发现和理解 API 的功能。

有好消息？安全团队会在发布前检查所有 API。坏消息呢？由于 API 负责人在开发过程中没有遵循 API 安全最佳实践，或者没有进行充分的测试，因此未通过检查，代码被送回返工。

还有更好的消息？制定一套一致的通用规则和最佳实践来帮助开发人员实现绝大部分的要求，并不是那么难的事情——基本方法包括了实施速率限制、加密外部流量，以及要求对密钥再生进行重新授权等。大多数企业还可以使用高级 Web 应用防火墙 (WAF) 或其他工具对 API 网关实施额外的保护，以抵御 OWASP 列出的 10 种最常见 API 攻击。

以上六个迹象只是 API 蔓延现象的一部分预警。我们要明确一点——API 蔓延是开发人员自主性和微服务 DIY 思维的自然产物。借助现代开发工具和像 GitHub Copilot 这样的代码自动化能力，构建新的 API 正变得越来越轻松可行。

应对 API 蔓延的工作没有止境。部署 API 管理解决方案和 API 网关可以发挥强大的助推作用——如果开发人员不针对 API 使用 APIM（API Management，即 API 管理）解决方案，网关可能会关闭他们的 API——这一要求很苛刻，但对安全防护来说很必要。

幸运的是，应对蔓延所采取的措施大多与常见的 API 管理方法一致。随着时间的推移，这些措施可以消除技术债务，并避免在开发过程后期或发布后通过补充的安全措施修复 API，最终让开发速度得到提高。

如果说 API 是企业的生命线，则 API 蔓延是对企业健康状况的最大威胁之一。谨慎且主动的 API 蔓延控制措施会带来巨大的回报，并且最终会提高开发人员的满意程度。

NGINX 唯一中文官方社区，前往 nginx.org.cn。

更多 NGINX 相关的技术干货、互动问答、系列课程、活动资源： 开源社区官网 | 微信公众号