F5 首席技术官办公室意见
一年多来，F5 的首席技术官办公室团队一直在探索与 API 相关的技术领域。这份新发布的白皮书是我们研究不断发展的 API 生态系统的续篇。
我们详细介绍过管理 API 蔓延带来的难题，这些难题将为 API 网关蔓延带来挑战，而传统方法不足以应对这些挑战。虽然 GraphQL 等图形技术有潜力应对与 API 相关的复杂性，但随着这些挑战超越连接性、安全性和路由，GraphQL 只能部分解决问题。基于近三十年来在扩展系统和应用方面的专业知识，正确的方法是以采用 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-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) 当企业有更多的应用在更多的地方运行时，随用随扩展。
- API 网关供应商蔓延：由于很难说服所有团队采用单一 API 网关供应商，而且迁移到新供应商是一项繁琐的任务，因此很难处理 API 网关供应商蔓延的问题。结果导致企业需要花费时间和资源来管理多个网关供应商。虽然这个问题是可以解决的，但在实际操作中却很困难。
- 应用扩展：当应用需要支持单个位置内的更多用户或需要在多个位置部署时，扩展应用就成为了问题。这要求应用横向或纵向扩展。然而，随着应用的扩展，API 网关也需要扩展，在某些情况下，需要在多个位置部署 API 网关，以支持基于当前架构模式的扩展。这可能会使管理 API 网关在操作上变得复杂。
解决方案：分布式网关参与者模式
图 4 描述了解决 API 网关蔓延的分布式网关参与者模式。分布式模式并不是新事物，但本文是在 API 网关的上下文中对其进行形式上的描述。客户端启动 API 请求。分布式网关参与者是临时性的，并尽可能根据客户端情况按需实例化。API 传输层负责将 API 请求从网关参与者发送到简化的 API 网关，后者将请求路由到适当的 API 工作负载。虽然分布式参与者模式并不要求使用 GraphQL 支持，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 网关的同质化策略绝非易事。
企业 API 网关标准化面临的挑战
随着企业自然发展或通过收购实现发展，被设置为特定业务部门 (BU) 的内部团队在选择 API 网关技术或供应商时会出现分歧。造成这种情况的原因包括：
- 技术：不同团队或业务部门有不同的技术堆栈或偏好不同的 API 网关解决方案，因此难以标准化单一类型的网关。
- 旧版系统：有些团队使用不同类型的 API 网关构建了现有系统，很难用新的网关替换这些系统，尤其是如果他们仍在使用这些系统。
- 自定义：一些团队会自定义现有的 API 网关以满足特定要求，他们会发现很难在新网关上复制这些自定义条件。
- 替换成本：无论在开发还是维护方面，用新的标准化网关替换现有 API 网关可能成本高昂。
- 培训开发人员：团队的专业知识水平不一，可能需要熟悉另一供应商提供的新网关技术或接受相应培训，这一过程既耗时又昂贵。
- 资源有限：企业的开发人员、预算和可用于更改网关的时间有限，难以实施新网关。
- 应用依赖性：不同的团队或业务部门对现有网关（例如与特定系统集成或其他自定义集成的网关）依赖程度不同，因此很难改用新网关。
- 第三方解决方案：一些团队将第三方解决方案集成到网关，他们难以将网关迁移到不支持这些第三方解决方案新的解决方案。
因此，如果现有应用的管理团队运作成熟且有主见，他们为了避免服务中断，不会改用其他部署模式。
结论是我们需要一种新的方法，它既考虑现有 API 基础设施中的多种限制，又将 API 网关蔓延看作更重要的注意事项之一。
设计注意事项
以下清单并不详尽，但总结了我们认为在构建解决方案时应该纳入的一些高级别设计注意事项：
- 与当前部署共存：随着企业努力跟上不断变化的技术格局，企业通常会使用多种 API 网关部署。拆除现有的 API 基础设施会扰乱关键业务运营，这种做法不可行。因此，任何新的部署都必须设计为能够与当前部署的架构共存。
- 标准化 API 网关功能：企业 API 策略的主要目标应该是标准化 API 网关功能，由于 API 类型多样且不同业务部门的需求不同，标准化 API 网关功能并非易事。尽管如此，这种标准化对于创建稳定安全的基础设施至关重要，这样的基础设施才能支持企业的数字化转型。
- 利用边缘部署：边缘基础设施不仅可以让 API 数量呈指数级增长，还让企业可以将网关参与者移动到更接近边缘。由于用于创建 API 的基础设施也可以用于创建分布式网关参与者，这一切成为可能。因此，解决方案必须充分利用启动 API 请求的客户端与边缘基础设施的接近度。
- 与传输无关：实施分布式网关参与者架构的一个重要注意事项是它不应依赖于任何特定的传输机制。无论企业希望利用传统的 IP 网络、覆盖网络、VPN 还是低延迟消息传递基础设施，解决方案都必须与传输机制无关。这样才更具灵活性，让企业能够选择最适合其特定需求和要求的传输机制。
- GraphQL 支持：相比传统的 REST API，GraphQL 有许多优势，因此是 API 开发越来越热门的选择。它的一个关键优势是能够提供对数据的精细访问，因而能让客户在单个请求中准确指定他们需要的数据。此外，GraphQL 可以简化从多个服务聚合数据的过程，使其成为执行服务可组合性和编排的正确架构。这样可以减少网络开销并提升性能，尤其是在使用多个 API 服务来满足单个请求的分布式系统中。最后，借助其强类型结构和查询语言，GraphQL 可以提高 API 可发现性并实现更轻松的客户端开发。
- 安全是赌注：最重要的设计目标是能将解决方案添加到企业的 API 安全策略。该解决方案应该包含一些功能，例如验证并授权 API 请求、实施访问控制以及防御常见安全威胁（如跨站点脚本 (XSS) 和 SQL 注入攻击）的能力。在任何情况下，新的解决方案都不应损害现有的威胁模型或对其进行重大更改，以至于攻击面发生变化。通过优先考虑安全性作为设计目标，解决方案架构必须为 API 通信提供更安全的环境，降低数据泄露和其他安全事件的风险。
根据这些设计注意事项可得出具体要求，我们已将其纳入我们的分布式网关参与者 (DGA) 解决方案中。
分布式网关参与者模式
全面了解 API 网关后，现在我们可以解释分布式网关参与者模式解决方案。
分布式网关参与者模式设计
分布式网关参与者 (DGA) 设计模式从靠近客户端的计算和边缘计算中汲取灵感。这个想法的关键在于尽可能靠近客户端超分发每个网关参与者，并且网关参与者只在事务持续时间内存在，事务结束后则被清除。
设想
以下是这个解决方案的一些基本设想。
边缘计算已经变得越来越普遍，我们现在可以找到一些地理位置更接近客户端的计算类型。网关参与者可以在这些边缘计算节点上进行实例化。其目的是实现非常轻量化和临时性的 DGA，让它可以在任何边缘计算上进行实例化。
API 传输涉及在网关参与者和 API 网关之间建立网络，因此它是基础设施的重要组成部分。API 传输所需的基础设施类型根据供应商或企业的情况会有所不同。例如，大型公共云可能会使用主干网来运行 API 传输。另一实施方式是在企业数据中心内现有的高带宽和低延迟网络之上分层的低延迟消息传递总线。
API 网关功能
重申一下，API 网关本质上是一个反向代理，其主要功能是将 HTTP 流量路由到适当的 API 工作负载。在所有 API 都并置的情况下，这种方法很有意义，例如在本地网络中，或者在可用性区域内的虚拟私有云 (VPC) 中。但是，随着 API 数量跨混合基础设施扩展、迁移或只是移动化，这种 API 网关设计方法变得低效、操作复杂且昂贵。
虽然对于如何分类图 6 中描述的所有功能可能存在不同的看法，但我们都同意：API 管理基础设施是一种复杂部署，需要对许多组件进行仔细编排。
图 7 将 API 管理的各种特征和功能从图 6 映射到分布式网关参与者架构。此映射直观地说明了每个特征和功能如何对应 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 的中间件。
由于 GraphQL 可看到所有 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 调用的客户端。DGA 中可以终止 API，并以任何方式传输 API。这与图 3：传统 API 网关架构不同，图 3 中客户端流量在拓扑上与 API 网关相邻。
结论
因此，我们的目的是提出一种与供应商和部署无关的方法，因为不同的供应商可能有自己的知识产权，用于构建这些组件来实现上述类似目标。
多个季度以来，我们一直在研究 API 蔓延、Edge 2.0 架构、API 经济和 GraphQL，本文总结了我们从中学到的知识。虽然对于传统 API 基础设施尚无定论，但我们认为需要一种新的方法。
新的方法能在全球范围内释放每个设备或实体的价值，单是这一点就很值得我们探索。传统 API 基础设施即便看起来是分布式的，但它根本上还是单体的，因此我们现在需要摆脱传统 API 基础设施。
我们提出了基于分布式 GraphQL 的网关参与者方法，这是一种与供应商无关的方式，可以释放新兴 API 经济的全部潜力。