一、API 中介技术概述

背景，API 中介技术变得多样化，应用与集成架构师需要借助决策框架，从企业级 API 网关、轻量级网关、入口网关以及服务网格中挑选出适合多粒度服务和 API 的中介技术。

随着无服务器架构与容器管理系统的兴起，API 管理、API 网关与服务网格在转型、流量管理、安全以及可观测性方面出现了功能特性重叠与互补的情况。例如，企业级 API 网关通常位于网络边缘，用于保障进出 API 流量的安全，适合那些具有商业化潜力、面向外部的、产品化且已发布的 API，同时也可用于管理支持跨域集成和共享服务的内部 API；轻量级 API 网关因体积小、配置声明式且具备 DevOps 准备性，在云原生环境中成为内部 API 管理的热门选择；入口网关则应运而生，它结合 API 中介与入口控制器或网关 API 模式，在容器编排平台上保障、路由和监控外部流量。

然而，面对众多的 API 中介技术选择，一方面增加了找到最优解决方案的难度，另一方面也存在过度购买或购买不足导致的各种问题，比如过度购买会使产品利用率低、部署延迟以及运营复杂性和开销增加，而购买不足或利用不足则会使组织难以维持对安全性不足的影子 API 的可视性和控制。

二、决策要点问题

文章提出决策要点问题是 “我应该选择哪些中介技术来保护和管理我的 API 和服务通信？”，并阐述了基于 API 网关的 API 中介仍然是保护、管理和监控 REST 端点以供外部、私有和内部使用的最常见解决方案。但随着网状应用和服务架构（MASA）以及多粒度服务（包括宏服务、微型服务和微服务）的广泛应用，容器编排平台（如 Kubernetes）和服务网格（如 Istio）领域出现了快速创新，这也促使 APIM 市场不断演变，传统 APIM 厂商开始支持事件驱动架构（EDA）、服务网格和 GraphQL，初创公司则推出了与服务网格和容器编排平台集成的 API 网关功能，以保障和管理南北向流量到东西向流量的交接。

三、决策概览

在选择 API 中介技术时，需要平衡各种功能性与非功能性标准。该研究的评估标准未纳入技能、成本、采购时间以及部署工作量等约束因素，因为首次实施新 API 中介技术的成本远高于后续实施，若纳入这些因素会导致选择标准失真。

决策工具旨在帮助从企业级 API 网关、轻量级 API 网关、入口网关和服务网格中挑选出合适的 API 中介技术。以下是对这几种技术的简要介绍：

企业级 API 网关 ：通常位于网络边缘，保障进出 API 流量的安全，适合外部面向、产品化且已发布并具有商业化潜力的 API，也可用于管理支持跨域集成和共享服务的内部 API，一般由集成 / 中间件团队或安全部门集中管理，且可能是包含 API 生命周期管理以及 API 开发人员门户的更广泛的 APIM 解决方案的一部分。
轻量级 API 网关 ：又被称为 “微网关”，设计为分布式且部署在靠近单个服务的地方，与企业级 API 网关不同，轻量级网关可由开发团队单独部署、配置和管理，以满足应用需求，例如 Axway Amplify Platform、Google 的 Apigee 和 Apigee Hybrid、IBM API Connect、Microsoft Azure API Management、Salesforce MuleSoft API Gateway 等。
入口网关 ：是组织容器环境的一部分，作为容器编排集群或服务网格的网络通信守门员，所有进入集群内部服务的入站流量都必须先经过入口网关，因此成为保护已部署到集群或服务网格的服务所实现 API 的理想策略执行点（PEP），例如 Contour、Ambassador Labs Emissary-Ingress、Envoy Gateway、Istio Ingress Gateway、Solo.io Gloo Gateway、Traeﬁk Hub、HashiCorp/IBM Consult API 网关、Kubernetes Ingress、NGINX Ingress Controller、Amazon Web Services（AWS）App Mesh 等。
服务网格 ：在应用域内调解服务间（东西向）通信，将与安全和流量管理相关的横向问题抽象化，同时为开发者实现可观测性，以一致性和高可靠性实现这些功能，如 Google Cloud Service Mesh、Istio、Buoyant Linkerd、HashiCorp Consul 等。

四、决策工具

决策流程图旨在帮助选择合适的 API 中介技术，涵盖了 Gartner 客户中普遍存在的约束条件、变量和模式。该流程从假设拥有一个服务且需要控制其 API 访问权限开始，若服务所公开的 “内部” API 不能被所有客户端直接使用，则必须定义并发布针对特定用例的消费者中心版本的 API（外部 API），当涉及多个外部 API 时，需重新审视流程中的每个新外部 API 定义。

决策流程包含以下问题：

第一步：您的服务是否在容器管理平台上运行？ ：若服务容器化且在容器管理平台（如 Kubernetes）上运行，回答 “是”，则需继续考虑入口网关和服务 / 消息网格，否则选择企业级 API 网关或轻量级 API 网关进入第二步。
第二步：您的服务所公开 API 的范围是什么？ ：API 的预期用途对于向新消费者发布 API 至关重要，它决定了所需的开发者支持（自动化或自助服务）、监控、安全 / 身份等能力，分为以下几种情况：
- 企业范围 ：API 设计用于在企业内外供广泛受众共享和重用，需按照企业信息安全和网络安全策略进行保护，并应发布到开发者门户或目录以支持 API 用户的设计时发现、共享文档、API 规范和运营信息。
- 应用范围 / 子应用范围 ：API 专为特定用例设计，公开特定于应用的功能，通常不适用于其设计的应用 / 项目之外的重用，其和消费组件通常由同一项目或产品团队设计和开发，并负责管理其生命周期，尽管通常不发布到开发者门户供跨域消费，但仍应注册到 API 目录中进行管理和保护，现代开发者门户允许使用细粒度的访问控制将应用范围的 API 发布给有限受众（如开发团队），或者可使用内部开发者门户来对 API、服务和其他软件资产进行目录管理。

若 API 是企业范围的，则进入第三步评估企业级 API 网关的适用性；若是应用范围甚至子应用 / 组件范围的，则进入第四步评估轻量级 API 网关。

第三步：API 是否符合企业级 API 网关标准？ ：若前几步的回答表明企业级 API 网关可能是调解 API 的合适候选，则需要进一步审查一些额外标准来验证这一选择，关键标准包括 API 实现的是企业范围的、旨在作为企业资产共享和重用的 API，通过 “失败向上” 路径在考虑轻量级网关标准后到达此处，API 在企业边缘 / 边界处受到保护，API 被发布到企业外部的消费者等。若对一个或多个标准回答 “是”，则应选择企业级 API 网关作为服务外部 API 的中介技术，否则考虑轻量级 API 网关。
第四步：API 是否符合轻量级 API 网关标准？ ：若到此为止的回答表明轻量级 API 网关可能是最佳选择，仍需审查额外标准，关键标准包括 API 在企业内广泛共享和使用、作为产品进行管理、以业务价值为导向、在应用域内发布 API、将 API 流量限制在内部网络 / 域边界内等。若对一个或多个标准回答 “是”，则应选择轻量级 API 网关作为服务 API 的中介技术，否则重新考虑企业级 API 网关。

五、原则、需求与约束

决策流程简要展示了如何为特定用例到达有效的中介技术，这一部分则揭示了决策流程背后的逻辑所依据的要求和约束。

（一）要求

使用 JSON 网络令牌（JWT）进行请求身份验证和授权 ：在授予对服务的访问权限之前，需要使用 JWT 对调用者进行身份验证 / 授权。
可观测性和依赖分析 ：对应用和基础设施与运营（I&O）团队而言，服务行为、拓扑和服务依赖关系的可观测性至关重要。
服务流量管理 ：对于微服务架构而言，细粒度的流量管理能力至关重要。

（二）约束

API 网格东西向流量不多。
运行服务网格的开销超过了应用本身所需的资源。
应用的网络拓扑相对静态，无需调整以适应动态路由策略或支持频繁的组件更新。

六、集成现有基础架构

多数组织在本地和云环境中拥有多种现有基础架构，如应用交付控制器（ADC）、网络应用和 API 保护（WAAP）、API 网关、容器管理平台、企业服务总线以及集成平台即服务（iPaaS）等，可利用与要求相符的现有企业级 API 网关和应用及集成基础架构进行 API 中介。

例如，在混合云或 multicloud 部署中，API 消费者与 API 提供者之间的接近程度可帮助确定 API 网关实例的放置位置以及整体 APIM 部署拓扑；服务运行时基础架构（如虚拟机、无服务器 FaaS 和容器管理平台）也可能影响或限制 API 网关形式因素的选择；若需要跨异构运行时基础架构（如虚拟机和容器化服务）支持服务间通信，那么具备这种能力的服务网格相对较新，应谨慎使用。

七、利用集成技术

中介技术旨在提供治理能力，如访问控制、流量管理和协议调解等，不包含业务逻辑。表 1 描述了 API 中介的理想、可能或不合适的负载情况。

在 API 中介网关中添加复杂的调解、转换或编排逻辑是一种反模式，会导致膨胀和紧密耦合，并模糊 API 策略执行与服务实现之间的界限。涉及业务逻辑的功能，如复杂的转换、聚合或服务编排，应在单独的服务中实现，而不是在调解层中。

八、结合同步与异步通信

并非所有服务间通信都采用同步请求 / 响应模式，事件驱动的通信模型可降低服务之间的耦合度和依赖性，从而提高适应性和灵活性。常见的设计模式（如事件溯源和命令查询职责分离）基于同步 API 前端与 EDA 构建，使用事件代理促进命令和查询模块之间的事件流动。技术专业人员应将基于请求或响应的调解与异步事件驱动模型相结合，以实现现代化的应用交付。

直接连接到消息（或事件）代理的服务使用特定于代理的协议或基于标准的消息协议。当前 API 中介技术（如 API 网关和服务网格）通常对 EDA 和异步消息传递的支持有限，因此可能不足以调解服务与消息（或事件）代理之间的通信。

九、优化 API 和服务的企业治理模型

API 和服务的企业治理模型从集中控制到联邦自治不等，组织通常采用介于集中治理模型和联邦治理模型之间的混合模型。

集中治理模型 ：强调在整个企业范围内对 API 生命周期的一致性和控制，通常围绕集中式的 APIM 团队实施，例如，API 卓越中心可能负责分享 API 最佳实践，并确保在 API 设计和策略执行方面的一致性，使用企业网关和开发者门户。
联邦治理模型 ：将 API 治理权下放给多个分散的业务线团队或地理位置，该模型更注重自主性、敏捷性和独立性，采用此模型的组织通常拥有多样化、自主的业务线团队，这些团队有权根据当地环境或产品需求优化其治理模型。
混合集中和联邦治理模型 ：使组织能够在集中一致性和控制与分布式团队的分散自主性和敏捷性之间取得平衡，组织需要根据组织结构和文化定制合适的治理方法，结合企业级 API 网关、轻量级网关和入口网关以及服务网格可提供全面的控制，组织可以执行 API 和服务的混合治理模型。

治理模型决定了组织如何实施和管理 API 网关、入口网关和服务网格等中介技术，还决定了负责操作、配置和利用每个中介层的角色。分配给开发和产品团队的控制和自主权的程度可以使其有效利用中介技术进行应用开发和交付。

十、与平台工程协作

平台工程团队负责工程、交付、维护和改进自助服务应用平台或 PaaS，包括 CI/CD 工具链，为多个敏捷应用团队构建定制软件。平台工程团队负责 API 网关、API 和服务目录、容器管理平台以及服务网格的持续运营，通常配置这些平台的控制平面，并为生产团队 / DevOps 团队设置全球策略、“合理” 默认值和护栏。

在不影响跨团队一致性和治理的前提下，某些应用、服务和 API 的特定策略和配置可委托给负责的 DevOps 团队，以优化开发团队的自主性和效率。平台工程团队通常拥有内部开发者门户的实施和交付，这对于提供有效的开发者体验至关重要。

十一、使用企业级 API 网关的标准

企业级 API 网关过去是最常见的 API 中介技术，传统上用于作为 APIM 的一部分治理 API 的内部或外部发布，以支持集成、开发和生态系统。以下是使用企业级 API 网关的标准检查清单：

在边缘 / 边界处受保护 ：API 保护和 API 访问控制作为企业整体 API 安全策略中的第一道防线和控制措施至关重要，边界保护是保障外部和合作伙伴 API 安全的必要措施，而组织采用分布式执行模型来保障企业范围内的 API 安全。
在企业外部公开 ：该 API 是外部、私有或合作伙伴 API 吗？企业外部公开的 API 包括公共 / 开放 API、支持移动和 Web 应用的 API，以及专用于合作伙伴和客户的私有 API，所有情况下消费者都在企业边界之外。
在企业内部广泛共享 ：是否有在企业内部被广泛共享和使用的 API？通过云连接（如 AWS Direct Connect、Google Cloud Dedicated Interconnect 或 Microsoft Azure ExpressRoute），企业网络的逻辑边界延伸至混合云和多云环境。
作为产品进行管理 ：该 API 是否将被产品化并在开发者门户或 API 市场中发布？API 被打包并交付给客户，作为产品或产品的一部分，并有产品经理和交付计划作为支撑。
以业务价值为导向 ：该 API 是否旨在为业务直接和间接创收？直接货币化 API 通过收取 API 产品消费费用来产生收入，而间接货币化 API 则在不直接追踪收入的情况下交付业务价值。

十二、使用轻量级 API 网关的标准

应用架构师有时会问：“如果企业网络边缘已经运行了企业级 API 网关，我是否还需要轻量级 API 网关？”答案是肯定的，因为如果不想让内部用户通过企业级 API 网关进行路由，那么也需要轻量级网关用于这些用例，以下是一些验证轻量级 API 网关益处的标准问题：

在应用域内发布的 API ：该 API 是由产品团队为应用或一组相关应用发布的内部 API 吗？是否是特定应用的私有后端 for 前端 API？内部 API 可能封装域功能，以支持应用上下文内的跨域交互，其消费者位于企业内部网络边界内。
将 API 流量限制在网络 / 域边界内 ：是否需要将内部 API 流量限制在受信任的网络内，以满足安全和合规要求？是否担心在 API 消费者和提供者位于同一受信任网络时，通过云端或非军事化区的集中式 API 网关路由 API 流量所引入的延迟？战略性地放置由开发团队管理或专用于开发团队的 API 网关，可以优化应用网络拓扑，减少网络延迟，并改善 API 流量在指定边界内的隔离和分段。
特定于应用的细粒度策略 ：该 API 是否具有特定于应用的细粒度策略？应用需要在其微边界内实施某些特定于域的细粒度 API 策略，这些策略可能包括基于应用内定义的角色或属性的授权策略、支持蓝绿或金丝雀部署的流量管理 / 路由规则、基于用户角色的数据脱敏规则等。
以开发者为中心的 DevOps 自动化 ：是否要求 / 希望将 API 中介策略作为 DevOps 流程的一部分进行部署？应用范围的 API 通常表现为迷你服务，公开域功能，它们是独立可部署的，并且与应用发布 / 更新周期一致的定期发布节奏相关联，因此应用开发团队更愿意将 API 生命周期作为应用 CI/CD 流程的组成部分进行管理，外部对企业 API 团队的依赖会阻碍开发团队的敏捷性、自主性和对其应用 CI/CD 流程的控制。

十三、使用入口网关的标准

入口网关是容器管理平台（如 Kubernetes）或服务网格（如 AWS App Mesh）的入口点，应用架构师常会问是否应使用入口网关保护和路由进入 Kubernetes 集群或服务网格的外部 API 流量。

小结：

该研究主要聚焦于 API 中介技术的选择框架，旨在帮助应用与集成架构师在多样化的企业级 API 网关、轻量级网关、入口网关以及服务网格中挑选出合适的解决方案，以应对多粒度服务和 API 的需求。文章阐述了 API 中介技术的多样化现状及发展趋势，强调了 API 管理、网关与服务网格在满足无服务器架构和容器系统需求过程中出现的功能重叠与互补，并指出了企业在购买 APIM 产品时存在的过度购买或购买不足的问题。同时，介绍了决策工具的使用方法，该工具通过一系列问题引导用户根据服务运行环境、API 范围等关键因素选择恰当的 API 中介技术。此外，文章还探讨了与平台工程协作、优化 API 和服务治理模型等方面的内容，并对 API 中介技术的未来发展趋势进行了展望，如 API 治理与服务治理的融合、服务网格控制平面的创新等，为技术专业人员提供了全面的指导，以应对在分布式企业应用环境中实现 API 和服务一致治理的挑战。