什么是 API 网关 (API Gateway) ？

应用程序编程接口 (API) 是一组规则或协议，使软件应用程序能够交换数据、特性和功能。API 可帮助企业使用内部和第三方服务，而无需为每个服务构建自定义整合。根据 Postman 2025 年的 《API 状态报告》，超过八成的公司已在某种程度上采用了 API 优先策略，其中 25% 的公司认为自己完全采取了 API 优先策略。

API 网关在现代 IT 环境中发挥着关键作用，通过简化 API 交互，并帮助应用程序访问各种服务（通过这些服务各自的 API），甚至包括使用不同编程语言开发、托管在不同平台上或部署在云、边缘和本地部署环境。

API 网关既可以为访问第一或第三方应用程序的内部用户提供服务，也可以为外部用户提供服务，例如客户或业务合作伙伴。在联合系统中，企业使用多个网关来根据 API 组或用户类型实施不同的安全协议和标准。

API 网关通常具有两个主要的架构层：

• 控制平面处理配置和管理，设置安全策略、记录和监控 API 请求以及定义路由规则。
   

• 数据平面实时路由 API 请求，同时执行控制平面设置的路由准则、安全协议和数据约束。

从客户端向 API 发出的数据请求称为 API 调用。API 网关接收 API 调用（有时称为 API 请求），将其路由到一个或多个后端服务，收集请求的数据，并通过单个组合响应将其传递给客户端。否则，客户端就需要直接与多个 API 交互才能访问每个相关的服务或数据源。

例如，医疗保健系统可能会利用 API 网关帮助患者通过面向用户的应用程序连接到多个后端服务。患者可以使用笔记本电脑或手机查看医疗记录、预约就诊、支付费用和发送消息。API 网关充当单一入口点（或端点），因此用户无需在多个平台之间导航即可访问每项服务。它还支持加密、强制授权和其他安全措施，以帮助保护敏感的患者数据。

在深入了解 API 网关的实现方式之前，了解它们与 API 本身的区别非常重要。API 是一组规则和协议，使不同的软件应用能够进行通信，通常通过基于网络的 HTTP 或 HTTPS 协议实现。它们就像办公楼内的楼层，每一层代表一种特定的服务。要检索数据，客户端必须访问相应的楼层才能访问内部的服务。

同时，API 网关就像办公大楼的前门，客户必须通过它才能到达各楼层。在许多配置中，网关还充当门卫的角色：它会检查访客的凭据，以确定他们有权访问哪些楼层。它不是让客户自己深入了解每个楼层，而是代表他们检索请求的信息或服务，并将其作为单个包返回给他们。

API 网关可帮助组织为用户提供一致、安全和满意的 API 体验。主要职能和职责包括：

作为统一的 API 端点，网关接收来电，对其进行身份验证，根据组织策略进行处理并将它们路由到相应的后端服务。然后，网关对结果进行汇总并以组合形式返回给 API 客户端（通常是面向用户的应用程序或网站）。这一过程使用户能够通过单个 API 调用提出多个请求，并收到一个内聚的响应。在某些配置中，网关与工作流编排层协同工作，该层可以协调多步骤的自动化任务，从而简化业务功能。

API 管理是在企业内部创建、发布和管理 API 的可扩展流程。根据多云公司 f5 的说法，现代组织通常会同时管理 数千个 API，这使得可见性、控制和治理成为持续的挑战。API 网关通过集中管理任务（例如请求路由、版本控制、负载平衡和流量管理）来简化这种复杂性。它们还可以通过生成 API 调用日志并与分析工具集成来提高 API 可观测性，使团队能够更深入地洞察分析 API 使用模式。

API 安全是指保护 API 免受滥用、恶意攻击和其他网络安全威胁的实践和程序。API 网关通过管理身份验证、授权以及其他权限和访问控制来帮助执行 API 安全协议。它们使用传输层安全 (TLS) 和开放授权 (OAuth) 等加密协议来帮助维护安全网络并促进安全连接。

速率限制，即为每个用户允许一定数量的请求，可以防护 分布式拒绝服务 (DDoS) 攻击。最后，API 网关负责对系统中的每个 API 进行管理和监督，防止出现偏差、影子 API 和其他安全漏洞。

API 网关可以监测和记录 API 请求、响应和错误。然后，企业使用这些分析数据来更好地了解 API 流量和性能、改进故障排除并加强安全性。日志和指标不仅提升了可见性，帮助团队快速识别错误和安全威胁，还提供了错误产生的原因和过程的背景信息，有助于系统的长期健康。

API 网关可以提高企业内部效率，帮助后端服务实现高性能和高可用性，并为用户提供更可靠、响应更及时的体验。响应压缩使网关能够将大型响应转换为较小的文件，从而减少带宽消耗和加载时间。缓存帮助企业在本地存储常用数据，提高性能的同时，降低成本和服务器负载。最后，虽然企业通常出于安全目的实施速率限制，但这一策略也有助于提升系统稳定性，防止服务器过载，并确保 API 访问的公平分配。

虽然它们具有核心功能，但 API 网关的部署可能会根据架构和实施方式有所不同。常见框架包括：

微服务架构是一种高级软件开发方法，可将应用程序分成较小的、独立运行的部分。每个微服务负责单一功能，可以自主部署和扩展。同时，服务可以通过 API 轻松通信，作为大型程序的模块化构建块。根据 2023 年的 Gartner 报告，近四分之三的组织使用微服务，还有 23% 的组织计划在未来实施该框架。

在微服务环境中，API 网关通常负责处理南北向流量，将来自外部客户端的 API 调用路由到相应的后端服务。它们通常与服务网格协同工作，服务网格主要处理东西向流量，即微服务环境内服务之间的通信。但也有一些例外，API 网关可以配置为路由内部流量，尤其是在现代环境中。但网关往往位于单独的架构层中，而服务网格则与每个服务一起部署或整合，以促进和管理内部连接。

在微服务环境中，API 网关发挥着关键作用，使组织能够通过单次 API 调用返回所请求的资源。例如，电子商务公司可能为产品信息、定价和库存提供单独的服务。通过 API 网关，企业可以通过一个请求从每个服务中获取信息或访问功能。随着微服务环境变得越来越复杂，企业不断新增服务和 API，这种简化的工作流显得尤为有用。

Kubernetes 是一个开源编排系统，帮助企业在容器化环境中部署、扩展和管理服务，在这些环境中，应用程序被打包为轻量级容器，并包含其依赖项。Kubernetes 经常用于微服务架构，尽管它也可以支持单体架构、无服务器架构和其他框架。该编排平台在现代 云基础设施中发挥着关键作用，使开发者能够一次构建应用程序并在任何地方部署。

API 网关可以通过多种方式与容器化 Kubernetes 聚类进行交互：

• 当部署在多个 Kubernetes 集群前面时，API 网关可以充当负载均衡器，将流量引导到正确的集群，以免任何一个实例过载。
  

• 当部署在单个 Kubernetes 集群的边缘时，API 网关可以充当入口控制器。入口控制器将流量引导至 Kubernetes 聚类，到达所请求的服务，然后再次返回。
  

• 当部署在 Kubernetes 聚类中时，API 网关可以与服务网格配合工作，服务网格负责内部容器化服务之间的通信。这种整合可以提升负载均衡、服务发现、流量路由以及端到端的加密。

在无服务器模型中，开发者无需直接与支撑其应用程序的服务器进行交互。相反，云供应商负责配置和管理服务器，因此开发人员可以只专注于编写和部署代码。

在无服务器环境中，API 网关的工作方式与微服务环境中的网关类似。但它们不是从长时间运行的服务中检索数据，而是根据客户端请求触发事件（启动特定操作的指令）。这种方法有助于确保应用程序仅在需要时运行，从而提高安全性和效率。

无服务器和微服务可以结合形成混合架构，其中每个服务以无服务器部署的方式运行（而非容器化或虚拟机部署），这有可能降低成本并提升可扩展性，尤其适用于可变的工作量。

并非每个 API 管理实施看起来都一样。组件可能会因系统复杂性、架构方式和预期用例而有所不同，尽管这些区别并不总是清晰的，一些组件的角色和功能可能会重叠。

入口控制器 是一个 Kubernetes 原生的软件组件，充当反向代理，根据一组入口规则将外部 HTTP 流量路由到 Kubernetes 聚类内的服务。入口控制器通常具有负载平衡功能，可智能地将流量导向不同的服务，以帮助确保网络的稳定性。此外，它们还可以动态调整其路由行为，以适应新的部署和配置更新。

尽管 Kubernetes 入口控制器执行一些与 API 网关相同的功能，但 API 网关的范围通常更广，包含更多高级管理工具，例如审计、记录、访问控制和安全性。此外，虽然 API 网关可以支持多种配置，但入口控制器特定于 Kubernetes 环境。

服务网格是一个基础设施层，可促进内部服务之间的通信，使它们能够有效地分享数据和函数。虽然控制平面（设置配置和策略）是集中式的，但数据平面通过轻量级 Sidecar 代理分布在每个服务中。这些代理位于每个服务实例旁，执行控制平面策略，包括安全、日志记录、路由和加密。相比之下，API 网关通常位于网络边缘，处于与客户端和所管理 API 分离的独立架构层中。

尽管服务网格可以帮助内部服务交换数据和信息，但它们仍然需要一种与外部流量交互的方式。在这种情况下，一个名为入口网关的特殊组件充当网状网络的入口点，处理外部流量路由，同时维护安全性和性能策略。API 网关和服务网格通常结合使用，API 网关处理面向公众的交互，而服务网格促进服务之间的连接。

API 环境越复杂，API 接收的流量越大，API 网关能提供的价值就越大。除了将流量路由到后端服务之外，API 网关还可以：

API 网关可以优化流量路由，从而降低延迟并提升用户体验。速率限制对客户端的请求数量设定上限，并阻止过量请求。请求节流通过减缓、延迟或排队请求来管理流量峰值。负载均衡可以帮助企业根据实时指标确定服务器的健康状况，并相应地调整路由路径。这些策略共同保护后端服务免受过载或损害，最大限度地缩短响应时间，并有助于提供更快、更可靠的服务。

API 网关可以帮助组织在规模扩大时平衡 API 流量和工作量。网关可以与自动化系统集成，根据流量需求实时添加或删除实例，使开发人员能够专注于核心业务逻辑和 API 开发而不是管理。

API 网关还可以通过定义和执行一致的安全策略以及在网络中分配流量，加速 DevOps 部署。这种集中式控制使团队能够在不影响整个生态系统的情况下独立扩展或更新服务，从而提升资源分配效率和创新速度。

最后，由于网关可以有效管理 API 的多个版本，因此开发人员可以在部署之前测试多次迭代，或为特定用例维护旧 API 版本的实例。

虽然 API 各自具有不同的角色和职责，但它们通常共享一些通用的工作流程。例如，许多 API 调用都经过相同的授权和验证过程以符合安全协议。每个 API 都可能受到相同的记录和监控策略的约束，这些策略用于深入了解使用率和流量。如果 API 是付费使用的，那么每次调用可能都需要路由到计费服务。API 网关可以协调并自动化这些任务，使开发者在每次 API 调用时无需手动执行。

API 网关还支持安全套接层 (SSL) 终止，这是一种在网关处解密敏感数据（如密码和信用卡号码）的方法，从而将这一性能密集型任务从各个 API 中卸载出来。最后，当同一服务器上部署了应用程序的多个版本时，API 网关可以通过读取请求头、URL 路径和查询参数，无缝地将流量引导到相应的版本。

由于 API 在现代 IT 基础设施中发挥着至关重要的作用，因此它们经常面临网络攻击的风险，包括 DDoS 攻击、参数篡改、注入攻击和其他威胁。API 网关可以通过速率限制、API 身份验证、请求授权和其他技术来帮助防范这些威胁。

API 网关通常具有集成的身份和访问管理 (IAM) 系统，可以查看谁在尝试与哪些服务进行交互。他们还可以监控 API 使用情况、记录流量并分析指标，以便在攻击发生之前识别可疑行为或漏洞。最后，API 网关可以与应用程序防火墙 (WAF) 等工具配合使用，以监控、过滤和阻止恶意 HTTP 流量。

API 网关支持混合云架构，使用户能够与使用不同协议和数据格式（如表述性状态转移(REST API)、SOAP、gRPC和 WebSocket）的后端服务进行交互。

如果没有 API 网关，API 可能很难手动将 API 调用转换为可访问的格式。网关通过执行数据和协议转换来缓解这一挑战，自动将请求和响应转换为客户端和服务都能理解的格式。

企业还可以在 API 网关和开发者门户（开发者发现和实施新 API 的中央存储库）之间同步文档和访问密钥，以便开发环境准确反映最新的 API 推出和更新。

遗留应用可能成为发展的障碍，尤其是在它们与现代 API 实现（如 SaaS 或 物联网）不兼容时。然而，遗留应用通常值得保留，因为它们包含关键数据和功能，这些内容无法轻易替代。

API 网关使企业能够在现代云环境中重用和改造遗留应用，而无需放弃或从头重建它们。网关的转换功能使企业能够保留遗留应用的原始代码和格式，即使公司其他部分已经迁移到更新的系统。

解耦，即将服务拆分为更小的部分，使 API 网关能够对遗留应用程序来应用速率限制、流量控制等工具，从而帮助现代化其功能并延长其生命周期。这一策略还帮助企业在后台更新服务的同时保持其在线运行。

作为应用程序的入站流量控制中心，API 网关可以提供 API 使用情况和性能的全面视图。自定义图表和仪表板可帮助企业可视化流量模式、吞吐量、响应时间和其他指标。通知功能可在潜在错误和漏洞影响应用程序性能或安全性之前提醒团队注意。

API 网关虽然可以帮助解决复杂的路由问题，但也可能引入新的问题。常见的挑战包括：

API 网关通常有助于简化 API 通信、资源分配和路由请求。然而，错误配置和容量不足可能会产生相反的效果，增加瓶颈的风险并增加系统额外的压力。为了避免服务中断和性能下降，企业在引入新客户和扩展服务时，可以增加资源配置。

API 网关为企业的生态系统引入了额外的层，需要额外的维护、计算和专业知识。开发人员可能会发现，测试新的部署变得更加困难，因为很难在虚拟环境中准确地重新创建 API 网关。这一限制使团队难以提前预测发布可能对系统产生的影响。

一种名为基础设施即代码 (IaC) 的 DevOps 实践可以通过使用配置文件来自动化基础设施管理和标准化，从而帮助应对这些挑战。这种方法简化了维护和配置，有助于 IT 团队最大限度地提高 API 网关的效率，同时降低架构复杂性。

因为 API 网关充当单一入口点，因此网关本身可能成为网络攻击或渗透的潜在途径。威胁和错误也更有可能在多个后端服务中产生级联效应，可能中断 API 流量并损害原本健康的应用程序。

为了降低这种风险，企业可以跨环境和可用性区域维护多个网关实例，帮助确保在一个网关实例脱机时，另一个可以临时取而代之。同样，组织可以使用不同类型的网关，包括边缘网关和服务网格，将路由和管理职责分散到多个入口点。

当组织选择了符合其特定需求的 API 网关，并围绕该网关构建了 API 环境后，迁移到其他供应商可能会既昂贵又耗时。在某些情况下，组织可能会选择自托管开源网关，而不是使用托管服务，以便更精细地控制其配置。但是，如果一个组织选择自托管方案，这种方法对开发团队来说成本可能会更高。