内部API管理实践指南

NGINX | 2020年9月02日

一些面向消费者的API应用广泛，已成为家喻户晓的品牌，例如Google Maps和Stripe。但真正推动API经济发展的，是内部API。

内部API，即仅向组织内部的客户端和开发人员开放的API，是企业推进数字化转型的关键支柱。构建内部API通常是开发数字产品和服务的第一步。事实上，根据IDC近期发布的调查报告《API：决定数字业务成败的关键因素》，支持应用和产品的内部集成是企业API开发计划的优先事项之一。

内部API为何重要？内部API有哪些优势？更关键的是，采用哪种架构来管理内部API更为合适？本博客将解答这些问题，帮助您安全、规模化地交付内部API。

内部API为何重要？

内部API通过开放组织内彼此独立的后端系统，供业务线（LOB）内的其他开发人员使用，从而打通数据孤岛并连接各个系统。例如，制造商的营销部门可能需要了解供应链部门所用系统中的信息，以确定是否对特定产品和型号进行折扣促销，从而精准触达目标细分市场并提高收入。

内部API如何打破信息孤岛？它们提供通用接口，支持使用HTML或JSON等标准格式交换数据。无论是构建还是使用API，都简单快捷。相比之下，使用专有数据库连接器和晦涩的数据交换协议从数据存储库中检索信息则更为复杂。API可减少阻碍，显著提高工作效率。这些API不会向外部开发者和第三方开放。内部API流量仅在组织内部传输，因此位于企业防火墙之内。

内部API的优势

内部API可加快产品上市速度，并减少软件开发所需的时间和成本。下面详细介绍这些优势。

运营效率

内部API提供易于使用的抽象层，可连接企业的各个部分，并能灵活适应不断变化的需求。开发人员无需为每个业务线（LOB）的应用构建孤立的技术栈，而是可以在整个组织内利用共享的内部API池访问数据。这样可以避免重复工作、缩短软件开发时间，从而提高开发人员和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 ms内完成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流量时不会产生额外脚本、数据库调用或其他控制平面逻辑等不必要的开销。解耦架构让您可以灵活选择Controller［NGINX Management Suite］和NGINX Plus API网关的部署位置；您可以将其部署在本地、公有云中，如果企业网络已扩展到云端，甚至还可以跨多个公有云部署。处理API流量的NGINX Plus API网关可以独立部署在企业防火墙后，因此内部API调用无需经由企业网络之外的云进行路由。

您是否已有内部API，或正计划开发内部API？是否通过云路由内部API？欢迎在下方评论区分享您的情况。与此同时，可立即开始免费试用NGINX Controller 30天[NGINX Management Suite]，或联系我们，讨论您的用例。