分布式网关参与者： 不断发展的 API 管理
F5 首席技术官办公室意见
F5 首席技术官办公室团队已在 API 相关技术领域探索一年多了。 这份最新的白皮书是我们努力了解不断发展的 API 生态系统的延续。
我们详述的管理 API 蔓延的挑战将导致 API网关蔓延的挑战，而解决这些挑战的传统方法是不够的。 虽然 GraphQL 等图形技术在解决 API 复杂性方面前景看好，但它只是解决方案的一部分，因为挑战不仅仅局限于连接性、安全性和路由。 正确的方法基于近三十年的扩展系统和applications专业知识，它基于分布式（而非联合式）架构，采用 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-GWs）（充当 API 调用入口点的专用软件层）已不足以管理新兴 API 生态系统的规模和复杂性。
图 1 说明了我们如何从管理 API 蔓延转向管理 API 网关蔓延。
上述设计模式指的是集中式控制平面，API 网关形成分布式数据平面，如图 2 所示。
API 网关是现代软件架构的重要组成部分，为 API 提供中央控制点和安全。 然而，随着 API 网关提供的功能数量的增长，它们变得越来越复杂和难以管理。 在许多情况下，这些网关已经发展成为单一系统，将各种功能捆绑在一个包中。
虽然管理多个网关可能看起来是一种分布式设计，但事实上它并没有达到真正的分布。 这是因为网关仍然紧密耦合，共享难以分离的资源和配置。 结果，许多企业最终管理分布式整体架构以及由此产生的所有挑战。
旧版 API 网关架构
图3给出了现有API网关的架构。 来自客户端的 API 请求首先通过共享或专用网络传输，穿过防火墙后才到达 API 网关。 充当反向代理的 API 网关随后将流量转发到 API 工作负载。
当 API 网关部署在整个企业中时，或者当 API 工作负载在跨区域、跨地区、跨云或跨边缘移动并同时应对 API 蔓延时，传统的 API-GW 将成为 API 管理的瓶颈。 多个 API-GW 由不同的团队启动，没有单一的企业管理和控制点。 如果单个或一组 API 服务转移到不同的基础设施（云或其他），运营团队必须有一种方法来迁移 API 管理的所有方面——注册、发现、身份验证、网络、安全和治理风险与合规 (GRC) 政策。
因此，图 3 中所示的架构不可扩展或不实用，因为随着时间的推移，它会导致管理分布式整体（图 2）。
创建 API 网关瓶颈存在两个问题： （1）API 网关供应商扩张，（2）当企业在更多地方运行更多applications时进行扩展。
- API 网关供应商扩张： 处理 API 网关供应商扩张是一项人力挑战，因为说服所有团队采用单一 API 网关供应商可能很困难，而迁移到新供应商可能是一项繁琐的任务。 结果，组织最终花费时间和资源来管理多个网关供应商。 尽管这个问题可以解决，但在现实中可能并不完全可行。
- 应用程序扩展： 当应用需要在单个位置支持更多用户或需要在多个位置部署时，扩展应用s就是一个问题。 这要求应用水平或垂直扩展。 但是，随着应用的扩展，API网关也需要扩展，在某些情况下，它们需要部署在多个位置以支持基于当前架构模式的扩展。 这会使管理 API 网关的操作变得复杂。
解决方案： 分布式网关参与者模式
图 4 描绘了一个分布式网关参与者模式，用于解决 API 网关蔓延问题。 虽然分布式模式本身并不新鲜，但本文在 API 网关的背景下对其进行了形式化。 客户端发起 API 请求。 分布式网关参与者是短暂的，并根据需要尽可能靠近客户端实例化。 API 传输层的职责是将 API 请求从网关参与者发送到简化的 API 网关，然后将请求路由到适当的 API 工作负载。 虽然在分布式参与者中使用 GraphQL 支持更多的是一种细节，而不是这种模式发挥作用的要求，但它确实支持服务编排等功能。 因此，GraphQL 可以提供该支持，而不必创建新的服务编排层。
需要澄清的是，交通模式是从右到左。 即客户端在右边，由客户端发起API请求，如图5所示。
有一种新兴的部署模式，使用网关参与者来取代或减少对 API 网关的过度依赖，以管理企业内部和跨企业的 API。 虽然 GraphQL 对于架构来说不是必需的，但它的引入是及时的，因为网关参与者是支持 GraphQL 的正确工具。
为了更深入地了解网关参与者作为潜在的解决方案，有必要仔细检查 API 基础设施（特别是 API 网关）的当前状态。 这是因为我们已经发现网关蔓延是造成 API 基础设施运营和扩展挑战的重要因素。
为了更好地理解 API 网关，首先需要检查现代 API 管理基础设施的各个组件。
图 6 以全面的视觉方式展现了 API 管理中不可或缺的各种功能和组件。 除了路由和管理后端服务流量所需的 API 网关之外，还有其他几个重要的基础设施组件。 这些可能包括身份验证、速率限制、缓存和服务网格等解决方案。 通过结合这些功能，组织可以控制其 API、增强安全性并优化性能。
让我们来看看 API 网关普遍认可和熟悉的功能：
- 路由： 根据请求的路径或内容将请求路由到适当的后端服务。
- 身份验证和授权： 作为单一入口点对请求进行身份验证和授权，确保只有授权的客户端才能访问后端服务。
- 速率限制： 限制客户端向底层 API 发出请求的速率，防止过度使用并保护后端服务免于过载。
- 缓存： 缓存来自底层 API 的响应，减少需要向后端服务发出的请求数量并提高性能。
- 协议翻译： 在不同的协议（例如 HTTP 和 WebSockets）之间进行转换，允许客户端使用不同的协议访问底层 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 并确保客户端访问正确的版本变得越来越困难。
- 监控和故障排除： API网关可以收集和生成大量数据。 在大型企业中，网关可能分布在许多位置，这使得很难关联影响应用整体运行状况的事件并解决问题。
API 网关蔓延
API 网关蔓延是指组织内多个独立 API 网关的激增。 不同的团队或业务部门通常会创建自己的 API，这会导致创建多个独立的 API 网关来处理这些不同的 API。 不同的团队也可能使用来自不同供应商或解决方案的 API 网关来处理不同类型的 API。
这导致部署多个 API 网关，所有网关都具有不同的功能集。
API 网关扩张带来了几个额外的挑战：
- 扩展 API 网关管理： 拥有多个独立的 API 网关会使网关的管理和维护变得困难，尤其是在底层 API 和客户端的数量不断增长的情况下。
- 东西向交通效率低下： 多个网关可能导致请求需要通过所述多个网关，从而增加延迟并降低性能。
- 安全政策的统一性： 管理多个网关可能很困难，并且可能导致安全策略不一致，从而更难确保敏感数据的保护和访问的控制。
- 规范治理： 由于存在多个网关，因此很难确保所有 API 都得到正确管理并符合标准和最佳实践。
- 成本增加： 拥有多个网关可能会导致基础设施、开发资源和维护的成本更高。
- 扩大整合挑战： 拥有多个网关会使与其他系统和技术（例如其他数据库、数据仓库和数据分析工具）的集成变得更加困难。
企业应努力集中其 API 管理和治理，并使用单一类型的 API 网关。 虽然这将减轻 API 网关蔓延的上述挑战，但 API 网关的同质化策略绝非易事。
企业中标准化 API 网关的挑战
随着企业有机增长或通过收购发展，与特定业务部门 (BU) 保持一致的内部团队在选择 API 网关技术或供应商时会产生分歧。 造成这种情况的原因如下：
- 技术： 不同的团队或业务部门拥有不同的技术栈或偏好不同的 API 网关解决方案，因此很难在单一类型的网关上进行标准化。
- 遗留系统： 一些团队现有的系统是使用不同类型的 API 网关构建的，用新的网关替换这些系统会很困难，尤其是在这些系统仍在使用的情况下。
- 定制： 一些团队会定制其现有的 API 网关以满足特定要求，并且会发现很难在新网关上复制这些定制。
- 重置成本： 用新的标准化网关替换现有的 API 网关在开发和维护方面成本都很高。
- 培训开发人员： 各个团队的专业水平各不相同，可能需要熟悉不同供应商的新网关技术或接受相关培训——这个过程既耗时又费钱。
- 有限的资源： 组织在开发人员、预算和时间方面的资源有限，因此很难实施新的网关。
- application依赖项： 不同的团队或业务部门对其现有网关有不同的依赖性，例如与特定系统集成或其他自定义集成，因此很难切换到新的网关。
- 第三方解决方案： 使用与网关集成的第三方解决方案的团队会发现很难迁移到不支持这些第三方解决方案的新解决方案。
因此，如果现有应用拥有完善且有主见的团队，则该团队将不愿意转向不同的部署模式，以免导致服务中断。
因此，我们可以得出结论，需要一种新的方法，该方法要考虑现有 API 基础设施的多重限制，同时强调 API 网关蔓延是更重要的考虑因素之一。
设计考虑因素
以下并非详尽的列表，但总结了我们认为在构建解决方案时应纳入的一些高级设计考虑因素：
- 与当前部署共存： 随着企业努力跟上不断变化的技术格局，企业部署多种多样的 API 网关是很常见的。 对现有的 API 基础设施进行分叉升级是不可行的，因为这可能会扰乱关键的业务运营。 因此，任何新的部署都必须以能够与当前部署的架构共存的方式进行设计。
- 标准化API网关功能： 企业 API 策略的主要目标应该是标准化其 API 网关功能，但由于 API 种类繁多且不同业务部门的需求各异，这可能是一项具有挑战性的任务。 尽管如此，这种标准化对于创建能够支持组织数字化转型的稳定、安全的基础设施至关重要。
- 利用边缘部署： 边缘基础设施不仅有可能成倍地增加 API 的数量，而且还为企业提供了将其网关参与者移近边缘的机会。 这是可能的，因为用于创建 API 的相同基础设施也可以用于创建分布式网关参与者。 因此，解决方案必须充分利用边缘基础设施与发起 API 请求的客户端的接近度。
- 运输无关： 分布式网关参与者架构的实现的一个重要考虑是它不应依赖于任何特定的传输机制。 无论企业想要利用传统 IP 网络、覆盖网络、VPN 还是低延迟消息传递基础设施，解决方案都必须与传输机制无关。 这提供了更大的灵活性，使企业能够选择最适合其特定需求和要求的传输机制。
- GraphQL 支持： GraphQL 由于其比传统 REST API 具有许多优势，正成为 API 开发越来越受欢迎的选择。 一个关键优势是它能够提供细粒度的数据访问，允许客户端在单个请求中准确指定他们需要的数据。 此外，GraphQL 可以简化从多个服务聚合数据的过程，使其成为进行服务可组合性和编排的正确架构。 这可以减少网络开销并提高性能，特别是在使用多个 API 服务来满足单个请求的分布式系统中。 最后，凭借其强类型模式和查询语言，GraphQL 可以提高 API 的可发现性并使客户端开发变得更加容易。
- 安全是首要考虑因素： 最重要的设计目标是它应该增强企业的 API 安全态势。 该解决方案可以包含一些功能，例如验证和授权 API 请求、实施访问控制以及防范跨站点脚本 (XSS) 和 SQL 注入攻击等常见安全威胁的能力。 在任何情况下，新的解决方案都不应损害现有的威胁模型，或对其进行重大改变以致攻击面发生变化。 通过将安全性作为设计目标，架构必须为 API 通信提供更安全的环境，降低数据泄露和其他安全事件的风险。
根据这些设计考虑可以得出具体要求，我们已将其纳入我们的分布式网关参与者（DGA）解决方案中。
分布式网关参与者
现在已经充分探索了 API 网关，我们可以解释分布式网关参与者解决方案。
分布式网关参与者设计
分布式网关参与者 (DGA) 设计模式从边缘计算和靠近客户端的计算中汲取灵感。 这个想法的关键在于将每个网关参与者尽可能地分布在靠近客户端的地方，并且让网关参与者仅在交易持续期间存在，直到最后被清除。
假设
以下是该解决方案的一些基本假设。
边缘计算已变得更加普遍，我们现在可以找到地理位置上更靠近客户端的某种类型的计算。 网关参与者可以在这些边缘计算节点上实例化。 目的是实现一个非常轻量且短暂的 DGA，以便它可以在任何边缘计算上实例化。
API 传输是基础设施的一个重要组成部分，因为它涉及在网关参与者和 API 网关之间建立网络。 所需的基础设施类型取决于供应商或企业，并且可能有所不同。 例如，大型公共云可能使用自己的主干网来运行 API 传输。 另一种实现方式可能是在企业数据中心内现有的高带宽和低延迟网络之上构建低延迟消息总线。
API 网关函数
重申一下，API 网关本质上是一个反向代理，其主要功能是将 HTTP 流量路由到适当的 API 工作负载。 这种方法在所有 API 都共置的情况下很有意义，例如在本地内部部署网络中或在可用区域内的虚拟私有云 (VPC) 中。 但是，随着 API 数量的扩大、跨混合基础设施的移动或移动化，这种 API 网关设计方法变得效率低下、操作复杂且成本高昂。
虽然对于如何对图 6 中描述的所有功能进行分类可能会有不同的看法，但我们可以同意API 管理基础设施已经成为需要精心协调的许多组件的复杂部署。
图 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 分析、使用情况报告、错误率监控、警报和事件以及监控和日志集成可以由边缘网关处理，边缘网关可以收集和聚合来自多个微服务的数据。
网关参与者 – 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 本身可以根据他们的特定需求提供更好的控制和定制。
这种新方法还具有更高的可扩展性，因为开发人员可以根据需要轻松启动网关参与者实例来处理增加的流量，而不必担心管理大型集中式网关的开销。
除了技术优势之外，网关参与者还比传统 API 网关节省成本，因为企业只需为其使用的临时网关参与者实例付费。 这种部署模型可以为额外的收入模式创造机会。
网关演员安置
通过利用 API 传输层，DGA 本质上将 API 入口位置与 API 网关分离。 DGA 可以移动到边缘，即更靠近发出 API 调用的客户端。 API 可以在 DGA 中终止，然后通过任何方式进行传输。 这与图 3 不同： 传统 API 网关架构中，客户端流量在拓扑上与 API 网关相邻进入。
结论
因此，我们的目的是提出一种与供应商和部署无关的方法，因为不同的供应商可能拥有自己的知识产权来构建这些组件，以实现如上所述的类似目标。
在本文中，我们总结了从多个方面研究API 蔓延、 Edge 2.0架构、 API 经济和 GraphQL 调查的经验教训。 尽管对于遗留 API 基础设施尚无定论，但我们认为需要一种新的方法。
仅仅是承诺在全球范围内释放每个单独的设备或实体内的价值就为探索新方法提供了足够强大的理由。 我们今天需要摆脱传统的 API 基础设施，因为虽然它看起来是分布式的，但在本质上却是整体的。
我们提出了基于分布式 GraphQL 的网关参与者方法，作为一种与供应商无关的方式来释放新兴 API 经济的全部潜力。