管理内部 API 的最佳实践

一些面向消费者的 API 非常普及，已经成为家喻户晓的名字——例如谷歌地图和 Stripe——但内部 API 才是 API 经济的真正动力。

内部 API（指仅向组织内的客户和开发人员公开的 API）是企业数字化转型工作的重要支柱。 构建内部 API 通常是数字产品和服务开发的第一步。 事实上，根据 IDC 最近的调查《API——数字业务成败的决定因素》 ，支持应用和产品的内部集成是企业 API 开发计划的首要任务之一。

为什么内部 API 很重要？ 内部 API 有哪些好处？ 而至关重要的是，什么是管理它们的最优架构？ 本博客解答了这些问题，以帮助您安全、大规模地交付内部 API。

为什么内部 API 很重要？

内部 API 通过开放组织的不同后端系统供业务线 (LOB) 内的其他开发人员使用，解锁数据孤岛并建立桥梁。 例如，制造商的营销组织可能需要了解供应链组织所使用的系统，以确定是否对某些产品和型号打折，以瞄准正确的细分市场并实现收入最大化。

内部 API 如何打破孤岛？ 它们提供一个通用接口，支持使用 HTML 或 JSON 等标准格式进行数据交换。 不仅构建 API 简单快捷，使用 API 也同样简单快捷。 与此相比，使用专有数据库连接器和神秘的数据交换协议从数据存储库中检索信息。 通过减少摩擦，API 可显著提高生产力。 这些 API 不会暴露给外部开发人员和第三方。 内部 API 流量在组织内 - 因此在公司防火墙内。

内部 API 的好处

内部 API 可加快产品上市时间并减少软件开发的时间和成本。 让我们详细了解一下这些好处。

运营效率

内部 API 提供了一个易于使用的抽象层，用于连接业务的各个部分，并提供了适应不断变化的需求的灵活性。 整个组织的开发人员可以从通用的内部 API 池中获取数据，而不是为每个 LOB 的应用创建孤立的技术堆栈。 这消除了重复并减少了软件开发时间，从而提高了开发人员和 IT 的工作效率。

记录系统的开发

内部 API 促进了记录系统的发展，该系统是组织中关键数据元素的权威来源。 为了确保数据完整性，对于给定的信息必须有一个（且只有一个）记录系统。 如果每个 LOB 都有自己的数据，甚至有稍微不同的版本，就会导致差异和混乱。 内部 API 是访问此单一事实来源的有效机制。

节省成本

效率带来成本节省——无需在每个 LOB 内构建具有大量定制的专有平台。 也没有必要构建或购买本质上是点工具的昂贵连接器和集成。

例如，爱沙尼亚联邦政府运营着X-Road，这是一个无缝连接所有政府机构的数据交换平台。 爱沙尼亚公民甚至不需要携带驾驶执照，因为可以从人口登记处和车辆登记处快速检索这些信息 - 尽管这两个数据存储库是分开的。 世界银行的这份报告保守估计，通过简化信息获取方式，X-Road 仅在一年内（2014 年）就为爱沙尼亚政府和公民节省了 280 万个工时。

内部 API 管理指南

让我们了解一些管理内部 API 的最佳实践。

使用 API 管理工具

为了有效地定义、发布、保护、监控和分析面向内部和外部的 API，您需要一个API 管理解决方案。 还需要一个开发人员门户，让内部开发人员能够快速了解已发布的 API。

确保高性能

微服务是一种正在获得广泛关注的软件开发新架构方法。 许多企业要么重新设计其现有的内部应用，要么使用该框架构建新的应用程序。 在微服务架构中，API 是客户端与基于微服务的应用之间以及组成应用的微服务之间的通信手段。 当 API 客户端从后端应用请求资源时，API 网关会将流量路由到适当的微服务。 API 网关还会对调用进行身份验证并应用速率限制，以防止外部参与者设法突破公司防火墙时可能发生的攻击。

微服务比单片应用“更频繁”，微服务之间存在大量“东西”流量。 因此，选择一个能够以高吞吐量（每秒请求数）处理并快速提供响应的高性能网关非常重要。 客户端请求通常会产生对不同微服务的多个 API 调用，因此 API 网关处即使一个调用的延迟也可能产生连锁效应并导致非常高的延迟。

不要通过公司网络之外的云路由呼叫

虽然第一代基于云的解决方案提供了完整的生命周期 API 管理，但它们并不适合处理内部 API。 由于它们的架构将数据平面（处理 API 流量的 API 网关）和控制平面（执行 API 管理功能）紧密耦合，因此在运行时每个内部 API 调用都必须通过 API 管理解决方案的云进行路由。 这有两个缺点：

• 增加延迟——跳转到云端来处理内部 API 调用是迂回的，并不可避免地会影响性能。
• 违反企业零信任政策——由于内部 API 调用必须路由到云端，因此需要在防火墙上打漏洞。 这使得企业网络容易受到攻击和破坏，并带来不必要的复杂性。

出于安全原因，内部 API 流量必须保留在公司防火墙后面，这样就可以阻止将调用路由到外部云。 即使对于在自己的私有云环境中托管应用和 API 的企业来说也是如此。

NGINX 能提供什么帮助？

NGINX 有几种方法帮助您管理内部 API。

• NGINX 因其性能而闻名。 据独立技术研究分析机构 GigaOm 称，即使请求速率超过每秒 30,000 个，NGINX 也能够在 30 毫秒内端到端处理 API 调用。 在我们的博客上了解有关基准测试结果的更多信息。 我们发布了一个参考架构，其中包含提供实时 API 的详细指南。
• NGINX 和 NGINX Plus 是专为容器设计的，是开发微服务的首选基础设施。 NGINX 和 NGINX Plus 占用空间约为 2 MB ，可在受支持的 Linux 服务器（裸机、云或虚拟）上运行，或直接在由 Kubernetes 和其他平台协调的 Docker 容器中运行。

• NGINX API 管理解决方案的创新架构专为扩展而设计。 NGINX 通过将 API 网关（NGINX Plus）与 API 管理软件（NGINX Controller [现为 F5 NGINX Management Suite] ）分离来支持分布式 API 管理。 两者之间没有运行时依赖关系，这确保了 API 流量的处理不会产生不必要的开销，例如额外的脚本、数据库调用或其他控制平面逻辑。

  解耦架构为您在部署控制器[NGINX 管理套件]和 NGINX Plus API 网关提供了最大的灵活性 - 您可以在本地、公共云中部署它们，如果您的企业网络扩展到云端，甚至可以跨多个公共云部署它们。 内部 API 调用不需要通过公司网络外部的云进行路由，因为处理 API 流量的 NGINX Plus API 网关可以在公司防火墙后面独立部署。

你们有内部 API 吗？ 或者您计划开发内部 API？ 您是否通过云路由您的内部 API？ 我们很乐意在下面的评论中听到您的意见。 与此同时，立即开始免费试用 NGINX Controller [NGINX 管理套件] 30 天，或者联系我们讨论您的用例。