在本系列的上一篇文章中，我们讨论了在企业数据环境中构建和使用 API 的复杂性。这些环境涉及由不同团队管理的多个数据域和众多应用程序，由于资源受限和目标冲突，导致挑战。
译自 Supergraph: A Solution for API Orchestration and Composition，作者 Sandip Devarkonda。
Supergraph 架构框架 (SAF)，源于我们在联邦数据访问和 GraphQL 联邦方面的经验，通过提出构建域 API（子图）和数据访问 API 平台（ SUPERGRAPH ）的策略来解决这些挑战。
该框架提供了一个团队协作的操作模型，充当具有 API 生产者和消费者的 API 市场。它简化了 API 生产者的加入，为消费者提供高质量的 SUPERGRAPH API，并强调具有过滤、排序和分页等功能的高质量域 API。
SAF 为联邦域所有权的操作模型和系统设计奠定了基础。在企业数据和 API 环境中，这有助于解决联邦数据访问的挑战，并使 API 编排和 API 组合等用例更容易解决。
API 编排
API 编排涉及管理多个 API 调用，并对请求和结果进行排序以执行复杂的任务或工作流。在我们的参考上下文中，API 编排的示例可能涉及以下顺序：
- 餐厅 API: 检查菜单和可用性。
- 支付 API: 处理付款。
- 配送 API: 安排配送。
编排层按顺序处理这些步骤，确保每个步骤在移至下一步之前成功完成，并将它们的响应组合成一个单一的、连贯的用户结果。
API 编排的挑战
编排主要由 API 消费者根据最终用户需求驱动。它具有挑战性，因为它通常跨越多个域。使用传统方法进行编排需要与聚合相同的“粘合”代码/端点——只是在这种情况下，这种粘合更复杂，正如我们从示例中看到的那样。编排通常还涉及多个变异，这进一步加剧了挑战。
我们再次遇到了所有权的挑战：消费者团队是否应该拥有编排代码？该团队是否具备构建高性能编排端点所需的技能？这些都是需要解决的操作挑战，以便在域 API/数据之上构建强大的编排层。
解决 API 编排挑战
一个好的 API 平台必须提供语义来定义可能与业务逻辑函数交织在一起的复杂工作流。类似于 SUPERGRAPH 架构允许域 CRUD API 和业务逻辑之间建立关系的方式，API 调用的响应可以链接到可以独立运行的函数（甚至可以从 SUPERGRAPH 调用其他 CRUD API）或反之亦然。
这种能力的基础是，来自任何来源（数据库、API 等）的每条数据和业务逻辑代码中的类型都在 SUPERGRAPH 的语义层上标准化。这使 SUPERGRAPH 能够为开发人员（包括 API 消费者）提供语义，以便他们仅使用声明性配置来表达工作流。
与 Camunda、Orkus、Temporal 等第三方编排软件的集成使开发人员的体验更加无缝。阅读有关API 编排的更多信息。
问题 | 解决方案 |
|---|---|
新的工作流需要新的编排端点。 | SUPERGRAPH 要求 API 消费者能够使用声明性配置自助服务对新工作流的需求。 |
编写工作流需要后端系统工程知识。 | SUPERGRAPH 配置是声明性的，这使构建可扩展工作流的能力民主化。 |
API 组合
API 组合可以被认为是 API 集成和编排的特殊情况（或演变），它指的是将多个 API 响应组合成单个统一响应的技术，该响应包含来自不同调用的分层信息。换句话说，组合以一种连贯的方式从不同的来源获取相关数据——因此，对于读取操作来说，它是聚合和编排。API 组合的一个例子是以下关于我们食品配送应用程序用户的示例数据：
- 用户的过去订单。
- 对于每个订单，获取有关放置订单的餐厅的一些信息。
- 对于每个订单，获取支付信息。
获取这些信息涉及按顺序向三个不同的域发出请求，在每一步使用上一步的响应，最后将整个结果集组合成一个单一的层次化响应，该响应表示三个实体（订单、餐厅和支付）之间的关系。
API 组合面临的挑战以及如何解决
Supergraph(QL) 架构主张了解底层来源或域，并在异构来源集中进行标准化。这使得 supergraph 可以提供 API 组合自助服务模型，而无需任何自定义开发，方法是提供以下两种功能：
- 连接: 从 A 获取数据，并从 B 获取相关数据。
- 嵌套过滤器: 从 A 获取数据，并根据其相关数据 B 的属性值进行过滤。
问题 | 解决方案 |
|---|---|
每个数据组合排列都需要一个组合端点。 | supergraph 通过跨来源数据的声明式关系定义来自动执行组合。如果可以从程序上推断出来自同一来源的关系，则 supergraph 可以自动执行此操作。 |
创作工作流需要了解后端系统工程。 | supergraph 配置是声明式的，这使得工程师能够轻松地构建可扩展的工作流。 |
阅读更多关于 API 组合 的内容。
结论：实践者的 API 平台设计清单
基于之前关于 Supergraph 架构框架的帖子，我们可以为任何寻求解决 API 集成、聚合、组合和编排挑战的 API 平台（称为 supergraph）设计编制以下综合清单。
指南 | 描述 |
|---|---|
1. 集成 | 使 API 消费者能够轻松地将 API 集成到其服务中 |
1.1 多种 API 格式 | supergraph 平台是否可以自动提供除 GraphQL 之外的输出格式，例如 REST/OpenAPI？这是为了满足多个消费者的集成需求。 |
1.2 文档 | supergraph 平台是否可以帮助域或平台所有者维护 API 文档？如果底层域（数据库、代码或 API）已经过文档化，那么这些文档是否会自动被 supergraph 平台获取？ |
1.3 标准化 | supergraph 平台是否提供或强制执行标准化的域 API 设计（分页、过滤、排序等）？ |
2. 聚合 | 使 API 消费者能够轻松地将多个 API 调用聚合/批处理到一个调用中 |
2.1 关系 | supergraph 是否提供了一种在任何两个实体或端点之间创建关系的方法，而无需域所有者进行更改？ |
2.2 可组合性 | 鉴于 supergraph 中两个实体之间的关系，supergraph 提供了多少个“连接”功能？ |
3. 编排 | 使 supergraph 利益相关者能够轻松地创作自定义 API 编排 |
3.1 联合变异/解耦编排业务逻辑 | supergraph 是否提供了一种在底层域内或跨底层域创作编排流程的方法？ |
衡量平台设计满足这些标准的有效性以及构建这些功能所需的时间和精力投入，将为任何架构师提供一个明确的指标，表明其平台计划的成功可能性。
