什么是 API 网关 (API Gateway) ？

其功能包括路由与转换客户端请求、聚合响应结果、执行安全策略，并与分析及监控工具进行集成。

应用程序编程接口 (API) 是一组规则或协议，使软件应用能够进行数据、功能与能力的交换。API 能帮助企业在无需为每项服务单独构建集成的情况下，灵活使用内部及第三方服务。根据 Postman 发布的《2025 年 API 状况报告》，超过 80% 的企业已在不同程度上采用 API 优先策略，其中 25% 认为自己已全面转向 API 优先架构。

API 网关在现代 IT 环境中发挥着关键作用，它通过简化 API 交互，帮助客户端应用程序访问各类服务（经由这些服务各自的 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 管理是在企业内部创建、发布和管理 API 的可扩展流程。根据多云企业 F5 的说法，现代组织往往需要同时管理数以千计的 API，这也使得可见性、控制与治理成为持续面临的挑战。

API 网关通过集中化管理请求路由、版本控制、负载均衡以及流量管理等任务，从而简化了整体复杂性。同时，它们通过记录 API 调用日志并与分析工具集成，提升了 API 的可观测性，使团队能够更深入地洞察 API 的使用模式与性能表现。

API 安全是指保护 API 免受滥用、恶意攻击和其他网络安全威胁的实践和程序。API 网关通过管理身份验证、授权及其他权限与访问控制机制，从而帮助执行 API 安全协议。

它们采用传输层安全 (TLS) 与开放授权 (OAuth) 等加密协议，以维护网络安全并确保连接的可靠性与安全性。速率限制机制（即限制单个用户的请求频率）可有效抵御分布式拒绝服务 (DDoS) 攻击。最后，API 网关负责对其权限内的每个 API 进行管理和监督，防止出现偏差、影子 API 和其他安全漏洞。

API 网关可以监测和记录 API 请求、响应和错误。企业利用这些分析数据，更深入地理解 API 流量与性能表现，从而优化故障排查流程，并进一步强化安全防护能力。

日志与指标不仅提升系统可观测性，使团队能够快速识别错误与安全威胁，还能进一步提供错误发生的方式与成因背景。这有助于系统的长期健康运行。

API 网关通过提升后端服务的性能与可用性，从而增强企业整体效率，并为用户提供更可靠、响应更迅速的体验。

响应压缩功能可将大体积响应转换为更小的数据文件，从而降低带宽消耗并缩短加载时间。缓存机制则可将高频访问的数据存储在本地，在提升性能的同时降低成本并减轻服务器负载。

最后，尽管企业实施速率限制主要出于安全考虑，但这一机制同样有助于提升系统稳定性。它能够防止服务器因请求过载而崩溃，并确保 API 访问在用户之间得到公平分配。

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

微服务架构是一种将应用程序拆分为多个小型、独立运行模块的软件开发方法。每个微服务负责单一功能，并可独立部署与扩展。同时，各服务通过 API 进行通信，作为构建大型系统的模块化组件。根据 Gartner 2023 年的报告，近四分之三的组织已采用微服务架构，另有 23% 的组织计划在未来实施该模式。

在微服务环境中，API 网关通常负责处理南北向流量，将来自外部客户端的 API 调用路由到相应的后端服务。它们通常与服务网格协同工作，服务网格主要处理东西向流量，即微服务环境内服务之间的通信。

但也有一些例外，API 网关可以配置为路由内部流量，尤其是在现代环境中。但网关往往位于单独的架构层中，而服务网格则与每个服务一起部署或整合，以促进和管理内部连接。

在微服务架构中，API 网关发挥着关键作用，使组织能够通过单个 API 调用统一获取所需资源。例如，一家电商企业可能将商品信息、定价与库存分别拆分为独立服务。借助 API 网关，应用程序可以通过单一请求，从各个服务获取信息或调用功能。随着微服务环境日趋复杂、企业持续引入新的服务与 API，这种简化后的工作流显得尤为重要。

Kubernetes 是一种开源的容器编排系统，可帮助企业在容器化环境中部署、扩展与管理服务。在这种环境中，应用程序被打包为轻量级容器，并与其依赖项一同封装。Kubernetes 在微服务架构中应用广泛，同时也支持单体架构、无服务器架构及其他开发模式。该编排平台在现代云基础设施中具有关键作用，使开发人员能够一次构建应用程序，并在任意环境中部署运行。

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

• 当部署在多个 Kubernetes 集群之前时，API 网关可与负载均衡器协同工作，将流量分发至相应的集群，从而避免单一实例过载。
   

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

• 当部署在 Kubernetes 集群内部时，API 网关可与服务网格协同工作；服务网格负责管理内部容器化服务之间的通信。这种集成可提升负载均衡、服务发现、流量路由以及端到端加密能力。

在无服务器架构中，开发人员无需直接与支撑其应用运行的服务器进行交互。相反，云服务提供商负责服务器的配置与管理，使开发人员能够专注于代码的编写与部署。

在无服务器环境中，API 网关的作用类似于微服务架构中的网关，但不同之处在于：它不再从持续运行的服务中获取数据，而是根据客户端请求触发事件（即启动特定操作的指令）。这种方式可确保应用程序仅在需要时运行，从而提升安全性与运行效率。

无服务器部署模型可用于实现微服务架构，从而形成一种混合型基础设施，其中每个服务以无服务器方式运行，而非采用容器化或虚拟机部署。这种架构可降低成本并提升可扩展性，尤其适用于负载波动较大的场景。

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

入口控制器是 Kubernetes 原生组件，充当反向代理，根据预设的入口规则，将外部 HTTP/HTTPS 流量路由至集群内的各项服务。入口控制器通常具备负载均衡能力，可智能分发流量至不同服务，以保障网络稳定性。同时，它们还能根据新的部署与配置更新，动态调整路由策略。

尽管 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 网关还可与 Web 应用防火墙 (WAF) 等工具协同工作，对恶意 HTTP 流量进行监测、过滤与拦截。

API 网关能够整合采用不同数据格式、不同 API 架构或通信协议的服务——例如 REST（representational state transfer, REST API）、SOAP、gRPC 以及 WebSocket。

若缺少 API 网关，不同协议与数据格式之间的差异可能导致客户端与后端服务之间出现通信障碍。通过数据与协议转换能力，网关可自动将请求与响应转化为双方兼容的格式，从而有效化解这一问题。

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

旧版应用程序在与现代环境或 API 实现不兼容时，往往会成为系统演进的障碍。然而，旧版应用程序通常仍具备重要价值，因为其中承载着关键数据与核心功能，难以被轻易替代。

API 网关能够帮助组织在现代云环境中对遗留应用程序进行集成、复用与再利用，而非直接废弃或从头重建。其转换能力使企业即便在整体系统已迁移至更现代的架构之后，仍能够保留旧版应用程序的原始代码结构与格式特征。

“解耦”（即将服务拆分为更小的独立模块）使 API 网关能够对旧版应用程序实施速率限制、削峰等策略，从而推动其功能现代化并延长生命周期。该策略还支持系统在后台持续升级的同时，依然保持对外服务的稳定运行。

作为应用入站流量的控制中心，API 网关能够提供 API 使用情况与性能的全局视图。通过自定义图表与仪表盘，组织可以直观呈现流量模式、吞吐量、响应时间等关键指标。同时，告警机制可在潜在错误或安全风险影响系统性能或安全性之前，及时提醒相关团队。

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

尽管 API 网关在一定程度上能够提升系统的可扩展性，但也可能带来需要解决的扩展性挑战。

通常情况下，API 网关有助于简化 API 通信、资源分配与请求路由。

然而，配置不当或容量不足可能适得其反，不仅增加瓶颈风险（毕竟 API 网关本身是单一入口点），还会加重系统负载。因此，在架构设计中需充分考虑横向扩展能力（如部署多个网关）、负载均衡策略、自动扩缩容机制以及监控能力，以有效规避可扩展性问题。 

与可扩展性类似，API 网关对 IT 复杂性的影响是多层次且具有权衡性的。它通过统一管理与策略执行机制，以及自动化的数据与协议转换，在一定程度上降低了系统复杂性。

然而，API 网关在企业 API 生态系统中引入了一层额外架构，这也意味着需要投入更多的维护资源、计算能力及专业技术支持。开发人员可能会发现新部署的测试更加困难，因为 API 网关在虚拟环境中难以被精确复现。这一限制使团队难以在上线前预判部署对系统可能产生的影响。

一种称为“基础设施即代码” (IaC) 的 DevOps 实践，通过使用配置文件实现基础设施管理与标准化的自动化，从而有助于应对上述挑战。该方法可简化维护与资源配置流程，帮助 IT 团队在降低架构复杂性的同时，最大化提升 API 网关的运行效率。

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

为降低此类风险，企业可在不同环境及可用区中部署多个网关实例，以确保当某一实例下线时，其他实例能够及时接管。同样，组织还可采用不同类型的网关（包括边缘网关），将路由与管理职责分散至多个入口节点。

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