分布式网关参与者：不断演进的API管理

作者：Rajesh Narayanan

审核及贡献者：Ian Smith、Sam Bisbee、Andrew Stiefel、Lori MacVittie、Mike Wiley等。

F5首席技术官办公室观点

一年多来，F5首席技术官办公室团队一直在探索API相关技术领域。这份最新白皮书延续了我们为深入了解不断演变的API生态系统所做的努力。

我们详细阐述的API蔓延管理难题还会引发API网关蔓延问题，而解决这些问题的传统方法将不足以应对。GraphQL等图技术在降低API相关复杂性方面潜力巨大，但这只是解决方案的一部分，因为相关挑战并不局限于连接、安全和路由。基于近30年来在系统和应用扩展方面积累的专业经验，适当的方法应采用分布式而非联邦式架构；该架构使用GraphQL，但并非完全依赖GraphQL。

本文探讨如何采用分布式架构来应对API网关蔓延带来的挑战。

摘要

数字经济将由API驱动，从而形成API驱动型经济。继《API蔓延白皮书》之后，我们着力研究如何消除或减轻API蔓延的影响。GraphQL看似有望减轻API蔓延带来的后果，但往往需要开发人员重写API代码库中的大量代码。不过，围绕GraphQL出现了一种新观点，即可将其用作有效的网关执行体。网关执行体是在客户端附近创建、用于发起API请求的函数或进程。该网关执行体充当初始API网关，负责终止API请求。它也可以是临时的，即在处理完请求后销毁。

除了开发人员和运维团队更重视API管理而非API网关之外，我们还发现，API蔓延会导致API网关蔓延问题。从开发人员的角度来看，主要关注的是确保API及时、正常运行。另一方面，运维团队更关注发现、安全性、可用性和访问控制等方面。如今，API网关是API基础设施的关键组成部分，因此很明显，API数量激增会增加API网关的部署，进而导致API网关蔓延。

未来的API架构需要不断演进，在适应API蔓延的同时简化部署和运维。所提出的架构代表了API网关设计模式的下一阶段演进方向。虽然GraphQL并非该架构的核心或必需组件，但它可以增强网关参与者模式。

总结

API管理生态系统必须摆脱对单体式API网关的管理，转向更现代的系统设计方法。这将打造更敏捷、更高效的API管理生态系统。

API网关泛滥：管理分布式单体架构

API蔓延本已是API经济中的一项挑战，还会导致API网关蔓延。在这种情况下，由于API网关供应商技术多样，加之各团队按照各自的理念管理API网关，API管理已变得难以控制。API架构正处于转折点：传统API网关（API-GW）是充当API调用入口的专用软件层，但已不足以应对新兴API生态系统的规模和复杂性。

图1说明了管理重点如何从API蔓延转向API网关蔓延。

图1：从API泛滥到API网关泛滥

上述设计模式采用集中式控制平面，API网关则构成分布式数据平面，如图2所示。

API网关是现代软件架构的重要组成部分，可为API提供集中控制和安全防护。然而，随着API网关提供的功能不断增加，其复杂性和管理难度也日益上升。在许多情况下，这些网关已演变为单体系统，将各种功能捆绑在一个软件包中。

图2：管理分布式单体架构

管理多个网关看似采用了分布式设计，但实际上并未实现真正的分布式架构。这是因为各网关仍然紧密耦合，共享难以分离的资源和配置。因此，许多企业最终不得不管理分布式单体架构，并应对由此带来的各种挑战。

传统API网关架构

图3展示了现有API网关的架构。来自客户端的API请求首先通过共享或专用网络传输，经由防火墙后到达API网关。API网关充当反向代理，随后将流量转发至API工作负载。

图3：传统API网关架构

当API网关部署在整个企业中，或者API工作负载在应对API蔓延的同时，跨区域、可用区和多个云进行运维迁移或迁移至边缘时，传统API-GW会成为API管理的瓶颈。不同团队会启动多个API-GW，但缺少统一的企业级管理和控制点。如果单个或一组API服务迁移到其他基础设施（云或其他基础设施），运维团队必须能够迁移API管理的各个方面，包括注册、发现、身份验证、网络、安全以及治理、风险与合规（GRC）策略。

因此，图3所示的架构不具备可扩展性，长期来看也不切实际，因为随着时间推移，它会导致需要管理分布式单体架构（图2）。

造成API网关瓶颈的原因有两个：（1）API网关供应商数量激增；（2）随着企业在更多位置运行更多应用，需要持续扩展。

1. API网关供应商泛滥：应对API网关供应商泛滥是一项人员协作方面的挑战，因为很难说服所有团队统一采用同一家API网关供应商，而迁移到新的供应商也可能十分繁琐。因此，组织最终不得不投入时间和资源来管理多家网关供应商。虽然这个问题可以解决，但在实际中可能难以完全实现。
2. 应用扩展：当应用需要在单个位置支持更多用户，或需要部署到多个位置时，应用扩展就会成为一项挑战。这要求应用进行横向或纵向扩展。然而，随着应用扩展，API网关也需要相应扩展。在某些情况下，根据当前的架构模式，还需要将API网关部署到多个位置以支持扩展。这可能会增加API网关运维管理的复杂性。

解决方案：分布式网关Actor模式

图4展示了一种分布式网关参与者模式，用于解决API网关蔓延问题。分布式模式本身并非新概念，但本文在API网关的语境下对其进行了规范化定义。客户端发起API请求。分布式网关参与者是临时的，可按需实例化，并尽可能靠近客户端。API传输层负责将API请求从网关参与者发送到简化的API网关，再由该网关将请求路由到相应的API工作负载。分布式参与者对GraphQL的支持更多是实现细节，而非该模式正常运行的必要条件，但它确实能够支持服务编排等功能。因此，无需创建新的服务编排层，GraphQL即可提供此类支持。

图4：基于GraphQL的分布式网关执行单元

需要说明的是，流量模式为从右向左。也就是说，如图5所示，客户端位于右侧，API请求由客户端发起。

图5：流量从客户端（右侧）流向API工作负载（左侧）

一种新兴的部署模式是使用网关参与者来取代API网关，或减少在企业内部及跨企业管理API时对API网关的过度依赖。虽然该架构并非必须使用GraphQL，但此时引入GraphQL正当其时，因为网关参与者是支持GraphQL的合适载体。

API网关在API管理中的作用

要更深入地了解API网关，首先需要了解现代API管理基础设施的各个组成部分。

API管理基础设施及功能

图6全面展示了API管理所需的各种功能和组件。除了用于将流量路由至后端服务并对其进行管理的API网关外，还有其他几项重要的基础设施组件，其中可能包括身份验证、速率限制、缓存和服务网格等解决方案。通过整合这些功能，组织可以更好地管控API、增强安全性并优化性能。

图6：API管理和基础设施功能

API网关常见功能

下面来了解一下API网关广为人知的常见功能：

1. 路由：根据请求的路径或内容，将请求路由到相应的后端服务。
2. 身份验证和授权：作为单一入口点对请求进行身份验证和授权，确保只有获得授权的客户端才能访问后端服务。
3. 速率限制：限制客户端向底层API发送请求的速率，防止过度使用，并保护后端服务免于过载。
4. 缓存：缓存底层API的响应，减少向后端服务发出的请求数量并提升性能。
5. 协议转换：在HTTP和WebSockets等不同协议之间进行转换，使客户端能够使用不同协议访问底层API。
6. 负载均衡：将请求分发到多个后端服务，从而提高可扩展性和可靠性。
7. 安全性：处理加密和解密等安全任务，确保数据安全传输。
8. 分析和监控：跟踪并报告使用情况指标和错误信息，帮助了解系统的使用方式，并识别性能瓶颈和错误。
9. 版本控制：管理底层API的版本，使客户端能够根据需要访问不同版本的API。
   
10. 服务发现：发现可用的后端服务，并将请求动态路由到这些服务，从而实现更具动态性和灵活性的服务发现。

背景：聚焦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网关复杂性的一些因素包括：

1. 配置管理：API网关通常包含大量需要管理和维护的配置选项和设置，例如路由规则、速率限制和安全设置。管理这些设置可能既复杂又耗时，尤其是在底层API和客户端数量不断增加的情况下。
2. 与其他系统集成：网关需要与多种其他系统集成，例如身份验证和授权系统、负载均衡器及数据库。这一过程可能较为复杂，尤其是在底层系统集成不完善，或API网关需要处理多种协议或数据格式时。如果企业部署了来自多个供应商的多个API网关，问题会更加突出。
3. 可扩展性和可用性：API网关需要能够处理大量请求并确保高可用性，这可能会增加管理的复杂性，尤其是在需要应对大量后端服务和客户端时。
4. 安全性：作为API安全的关键组件，安全API网关必须得到妥善配置和管理，以确保敏感数据受到保护并实施访问控制。这项工作可能较为复杂，需要持续监控和管理。
5. 版本管理：随着底层API和客户端数量的增加，管理不同API版本并确保客户端访问正确版本可能会变得越来越困难。
6. 监控和故障排除：API网关可以收集和生成大量数据。在大型企业中，网关可能分布在多个位置，因此难以关联影响应用整体运行状况的事件，也难以排查问题。

API网关泛滥

API网关蔓延是指组织内部出现大量彼此独立的API网关。不同团队或业务部门通常会创建自己的API，这可能导致组织部署多个彼此独立的API网关来处理这些不同的API。不同团队还可能使用不同供应商提供的API网关或不同的API网关解决方案，以处理不同类型的API。

这会导致部署多个API网关，而每个网关具备的功能各不相同。

API网关泛滥还会带来其他几项挑战：

1. 扩展API网关管理规模：多个相互独立的API网关会增加管理和维护难度，尤其是在底层API和客户端数量不断增长时。
2. 东西向流量效率低下：多个网关可能导致请求需要经过多个网关，从而增加延迟并降低性能。
3. 安全策略的一致性：管理多个网关可能较为困难，并可能导致安全策略不一致，从而更难确保敏感数据受到保护并实施访问控制。
4. 标准化治理：使用多个网关时，可能难以确保所有API均得到妥善治理，并符合相关标准和最佳实践。
5. 成本增加：使用多个网关可能会增加基础设施、开发资源和维护成本。
6. 集成挑战加剧：多个网关会增加与其他系统和技术集成的难度，例如其他数据库、数据仓库和数据分析工具。

企业应尽力集中管理和治理API，并采用单一类型的API网关。虽然这有助于缓解上述API网关泛滥带来的挑战，但要实现统一的API网关策略绝非易事。

企业统一API网关标准面临的挑战

随着企业通过自然增长或收购不断发展，隶属于特定业务部门（BU）的内部团队在选择API网关技术或供应商时可能会产生分歧。部分原因如下：

• 技术：不同团队或业务部门采用不同的技术栈，或偏好不同的API网关解决方案，因此难以统一采用同一种网关。
• 遗留系统：一些团队的现有系统采用其他类型的API网关构建，因此很难用新网关替换这些系统，尤其是在系统仍在使用的情况下。
• 定制：一些团队会对现有API网关进行定制，以满足特定要求，但很难在新网关上复现这些定制内容。
• 替换成本：使用新的标准化网关替换现有API网关，可能会产生高昂的开发和维护成本。
• 开发人员培训：团队的专业水平各不相同，可能需要熟悉其他供应商的新网关技术或接受相关培训，这一过程可能既耗时又成本高昂。
• 资源有限：组织在进行这项变更时，可投入的开发人员、预算和时间有限，因此难以实施新的网关。
• 应用依赖关系：不同团队或业务部门对现有网关有不同的依赖，例如与特定系统集成或采用其他自定义集成，因此难以切换到新网关。
• 第三方解决方案：如果团队使用与网关集成的第三方解决方案，就很难迁移到不支持这些第三方解决方案的新解决方案。

因此，如果现有应用由一支成熟且对技术方案有明确主张的团队负责，该团队通常不愿转向其他部署模式，以免造成服务中断。

因此可以得出结论：需要采用一种新方法，既要考虑现有API基础设施的多项局限，也要将API网关蔓延作为较为重要的考量因素之一。

设计注意事项

以下内容并非详尽无遗，而是概述了我们认为在构建解决方案时应纳入的一些总体设计考虑因素：

1. 与当前部署共存：随着组织努力跟上不断变化的技术发展，企业通常会部署多种不同的API网关。整体替换现有API基础设施并不可行，因为这可能会中断关键业务运营。因此，任何新部署在设计时都必须能够与当前已部署的架构共存。
2. 标准化API网关功能：企业API战略的首要目标应是实现API网关功能标准化。由于API种类繁多，且不同业务部门的需求各异，这项任务可能颇具挑战性。尽管如此，标准化对于构建稳定、安全且能够支持组织数字化转型的基础设施至关重要。
3. 充分利用边缘部署：边缘基础设施不仅可能使API数量呈指数级增长，还为企业将网关执行组件迁移到更靠近边缘的位置提供了机会。这是因为，用于创建API的同一基础设施也可用于创建分布式网关执行组件。因此，该解决方案必须充分利用边缘基础设施靠近API请求发起客户端的优势。
4. 传输机制无关：实施分布式网关执行单元架构时，一个重要的考虑因素是该架构不应依赖任何特定的传输机制。无论企业希望使用传统IP网络、覆盖网络、VPN还是低延迟消息传递基础设施，解决方案都必须与传输机制无关。这样可以提高灵活性，使企业能够选择最符合其具体需求和要求的传输机制。
5. GraphQL支持：与传统REST API相比，GraphQL具有诸多优势，因此日益成为API开发的热门选择。其中一项主要优势是能够提供细粒度的数据访问，让客户端可在单个请求中准确指定所需数据。此外，GraphQL还可简化从多个服务聚合数据的过程，是实现服务组合与编排的合适架构。这有助于减少网络开销并提升性能，尤其是在使用多个API服务来完成单个请求的分布式系统中。最后，GraphQL采用强类型架构和查询语言，可提高API的可发现性，并简化客户端开发。
6. 安全是基本要求：首要设计目标是增强企业的API安全态势。该解决方案可以整合部分功能，例如对API请求进行身份验证和授权、实施访问控制，以及防范跨站脚本（XSS）和SQL注入攻击等常见安全威胁。新解决方案在任何情况下都不得削弱现有威胁模型，也不得对其进行大幅更改而导致攻击面发生变化。将安全作为优先设计目标，意味着该架构必须为API通信提供更安全的环境，从而降低数据泄露及其他安全事件的风险。

可以根据这些设计考量推导出具体要求，我们已将这些要求纳入分布式网关执行单元（DGA）解决方案。

分布式网关执行单元

全面了解API网关后，我们现在可以介绍分布式网关参与者解决方案。

分布式网关参与者设计

分布式网关执行单元（DGA）设计模式的灵感源自边缘计算，以及利用靠近客户端的计算资源。其核心理念是将每个网关执行单元高度分散部署在尽可能靠近客户端的位置，并使其仅在事务期间存在，待事务结束后即予以清除。

假设

以下是此解决方案所基于的一些假设。

边缘计算已日益普及，现在可以在地理位置上更靠近客户端的地方找到某种形式的计算资源。网关执行单元可以在这些边缘计算节点上实例化。其目标是实现一种非常轻量且短暂存在的DGA，使其可以在任何边缘计算资源上实例化。

API传输是基础设施的关键组成部分，因为它涉及在网关参与者与API网关之间建立网络。所需的基础设施类型因供应商或企业而异。例如，大型公有云可以使用自己的骨干网来运行API传输。另一种实现方式是在企业数据中心现有的高带宽、低延迟网络之上构建低延迟消息总线。

API网关功能

再次说明，API网关本质上是一种反向代理，其主要功能是将HTTP流量路由到相应的API工作负载。当所有API都部署在同一位置时，例如本地网络中，或可用区内的虚拟私有云（VPC）中，这种方法较为合理。但随着API数量增加、API跨混合基础设施迁移或变得可移动，这种API网关设计方法会变得效率低下、运维复杂且成本高昂。

尽管对于如何对图6中所述的所有功能进行分类可能存在不同看法，但可以确定的是，API管理基础设施已成为由众多组件构成的复杂部署，需要对这些组件进行精心编排。 

图7：基于GraphQ-的分布式网关参与者

图7将图6所示API管理的各项特性和功能映射到分布式网关参与者架构。该映射直观展示了各项特性和功能如何与DGA方法保持一致，并突显API管理组件在该架构中的无缝集成。

集中式功能

上述大多数功能都包含可在逻辑上集中管理的组件。我们的目标并非重新设计管理平面，而是在可行的情况下移除某些功能。

API网关核心功能

这些属于数据平面功能，因此适合在API中实现，并与应用工作负载部署在同一位置。API网关是现代微服务架构的关键组件，充当所有外部流量的入口。我们将其核心功能归纳为路由、负载均衡、动态路由、运行状况检查、重试和回退。

API网关将传入请求定向到相应的微服务，在多个实例之间分配流量，支持动态路由，监控微服务及其实例的运行状况，重试失败的请求，并在微服务不可用或发生故障时提供回退响应。身份验证、授权、速率限制、缓存和日志记录等其他功能可根据系统的具体要求，分布到边缘或由中心化功能处理。

这种模块化方法可打造更灵活、更优化的架构，也是我们建议简化、现代化改造和扩展企业API基础设施的核心所在。

混为一谈

供应商经常误将API网关和API管理混为一谈，认为API管理属于API网关功能，但二者实际上是不同的功能，应分别对待。API网关负责将客户端请求路由到后端服务，而API管理涵盖更广泛的功能，例如访问控制、速率限制、分析和开发者门户管理。

虽然有些供应商可能会在单一产品中同时提供API网关和API管理功能，但了解这些功能之间的差异，并根据各自的具体要求分别进行评估非常重要。将这些功能整合在一起可能会造成混淆，并可能限制组织API基础设施的灵活性和可扩展性。这对于理解我们在分布式部署API网关功能方面的立场也至关重要。

网关执行组件：内联功能

此处列出的功能是需要以内联方式部署在数据路径中的核心功能。在分布式网关模式下，API网关的部分内联功能也会采用分布式部署。这些功能包括访问控制、速率限制、请求验证、API分析、使用情况报告、错误率监控、告警和事件处理、身份验证集成、第三方集成、监控和日志集成、边缘缓存以及压缩。

将这些功能迁移到分布式网关模式具有以下优势：

• 降低API网关负载：有助于降低集中式API网关的负载，并提升系统性能和可扩展性。
• 缩短响应时间：通过将这些功能部署在更靠近客户端的位置，可以缩短响应时间并降低延迟。利用数据和功能缓存，托管在边缘的API网关可以快速响应传入的请求。

例如，访问控制、速率限制和请求验证可由部署在更靠近客户端位置的边缘网关执行单元处理。这有助于减少需要由集中式API网关处理的请求数量，从而提升其性能和可扩展性。同样，API分析、使用情况报告、错误率监控、告警和事件处理，以及监控与日志集成也可由边缘网关处理。边缘网关可以收集并聚合来自多个微服务的数据。

网关执行单元：GraphQL候选项

如今，API网关支持的一项重要功能是服务组合与编排。虽然这项功能可能相当复杂，但如果简化版API网关不支持它，就会引发担忧。我们认为，GraphQL可以作为现有API的一种中间件，为服务组合提供一种值得关注的方法。

由于API网关能够查看所有API，因此很适合用于服务组合。开发人员可以组合网关后的API来增强业务逻辑，而无需编写更易于在服务组合层中进行组合的新服务。

GraphQL通过强类型架构实现服务组合，该架构定义了客户端可用数据的结构。无论数据由哪些服务或来源提供，客户端都可以使用此架构构建查询，明确指定所需的确切数据。解析器是将查询映射到数据源的函数，用于从相应的服务或来源检索数据。不过，尽管GraphQL有望提升安全性，其实际安全水平仍取决于编写代码的开发人员。

其他特性和功能

还有一些功能未在图6：API管理和基础设施功能中重点说明。这些其余特性和功能可考虑迁移到各个管理和运维功能或数据平面功能中。

我们特意选择使用“参与者”一词，以避免指向特定的实现方式或供应商技术。网关参与者可以基于方法、函数、工作单元、线程和进程来实现，并采用基于虚拟机、容器、无服务器架构的基础设施，或供应商特有的其他方式。

组件的功能和行为

分布式网关执行单元（DGA）架构采用的方法简化了API网关功能，并将其他内联功能移至边缘或控制平面。

控制平面

除API网关功能外，DGA架构还建议识别更适合由控制平面中的逻辑集中式组件提供，而非在单体式API网关中实现的功能。可以扩展现有API基础设施的管理和控制范围，以纳入这些附加功能。

简化的API网关

因此，简化API网关的关键在于提炼出一套标准的核心功能，使所有API网关供应商都能通过一组通用配置参数进行管理。

希望实现这一转型的企业可以逐个应用部署DGA架构，既不影响现有部署，也无需进行整体替换。

分布式网关参与者

DGA的一个重要特点是，每个“网关执行单元”都是临时的，仅在一次API会话期间实例化（即一个客户端发起一次API调用）。 

与传统API网关相比，分布式网关执行单元可以更加灵活、更具可扩展性，并且更具成本效益。开发人员无需依赖来自不同供应商的多个单体式API网关来汇聚和处理API流量，而是可以通过网关执行单元，为每个API指定并部署更靠近网络边缘的独立网关实例。API本身可以针对各自的特定需求提供更强的控制能力和更高的定制灵活性。

这种新方法还可提高可扩展性。开发人员可以根据需要轻松启动网关执行单元实例，以应对流量增长，而无需担心管理大型集中式网关所带来的开销。

除了技术优势外，网关Actor还可帮助企业节省相较于传统API网关的成本，因为企业只需为实际使用的临时网关Actor实例付费。这种部署模式可为拓展其他营收模式创造机会。

网关Actor部署位置

通过利用API传输层，DGA实际上将API流量入口位置与API网关解耦。DGA可以移至边缘，即更靠近发起API调用的客户端。API可以在DGA处终止，然后通过任意方式传输。这不同于图3：传统API网关架构。在该架构中，客户端流量从拓扑上与API网关相邻的位置进入。 

结论

因此，我们旨在提出一种不受特定供应商和部署方式限制的方法，因为不同供应商可能会利用各自的知识产权来构建这些组件，以实现上述类似目标。

本文总结了我们历经多个季度研究API蔓延、Edge 2.0架构和API经济（https://www.f5.com/company/blog/inverting-the-api-is-the-digital-transformation-that-enterprises-need-to-participate-and-compete-in-an-api-economy），以及探索GraphQL所获得的经验。尽管传统API基础设施的前景尚无定论，但我们认为需要采用一种新方法。

仅仅是释放全球每台设备或每个实体所蕴含价值的前景，就足以成为探索新方法的有力理由。我们现在需要摆脱传统API基础设施，因为它虽然看似分布式，底层却采用单体架构。

我们建议采用基于GraphQL的分布式网关参与者方法，以不受供应商限制的方式充分释放新兴API经济的潜力。