什么是 GraphQL 联合？

联合会将模式（后端和前端操作之间的契约）划分为更易于管理的组件和微服务，允许团队独立构建、部署和管理模式的各个部分，同时维护统一的数据图以供客户端交互。

在联合 GraphQL 环境中，GraphQL 网关将多个模式（也称为子图或服务）集成到单个图（或路由器）中。每个子图定义整体模式的一部分，并处理其自身类型和字段的业务逻辑和数据检索。然后，网关将多个独立子图拼接成一个母图，让客户端能够跨服务查询数据源，就像与单个 GraphQL 模式交互一样。

在联合之前，组合多个 GraphQL 模式的主要方法之一是模式拼接，其中不同的模式和解析器需要手动组合。它要求开发人员定义如何合并模式以及如何将数据拼接在一起。虽然模式拼接确实为 GraphQL 模式提供了统一的解决方案，但它也很复杂且容易出错，因此难以管理。

为了解决这些问题并简化模式拼接流程，Apollo（用于产品和应用程序工程的 GraphQL 实现）背后的工程师开发了 Apollo 联合。Apollo 联合引入了“key”、“external”、“requires”和“extends”这些关键字来定义不同服务中类型之间的连接。新的交叉引用功能使得开发人员能够使用 Apollo 网关构建一个连贯的数据图，而不必依赖过于复杂的拼接逻辑。

但是，Apollo GraphQL 联合不仅仅是一组新的工具和库。它也是一个系统规范，对架构进行了描述，并且描述了各种服务如何通信以形成分布式图。这让其他实现和工具能够采用联合原则，并且有助于制定联合 GraphQL API 构建标准。

自推出以来，GraphQL 联合已经历了多次改进。例如，托管联合可以促进指标收集，并在子图发生变化时启用自动网关更新，所有这些都无需人工干预或系统停机。

进步还包括 Federation 2¹ 的开发，这项创新简化了跨服务架构合并和查询执行，提高了模块化程度以加强对模式组合的控制，并改善了错误可见性以方便跟踪和调试。

Apollo 联合代表了构建精简 API 生态系统的重大进步，并且对于希望部署联合 IT 架构的企业来说，它仍然是一个选择。

然而，基于 Apollo 的联合方法将开发人员锁定在单一供应商实施中，因为 Apollo 联合环境只能接受来自 Apollo 或符合 Apollo 的后端技术的 Apollo 定义的指令和类型。换句话说，即使新技术不断涌现，Apollo 联合通常也会限制系统的灵活性。

如果开发人员希望在保持 Apollo 联合的统一层功能的同时优化灵活性，他们可能会选择开放式联合。开放式联合方法使系统能够组合来自任何 API 供应商或类型的数据，包括非 GraphQL API。使用 IBM API Connect 等工具，企业可以在不受兼容性限制的情况下定制和扩展其 IT 资产，并继续采用来自一系列技术社区的创新。

GraphQL 可帮助客户端准确请求他们所需的数据，而不会出现资源预配置不足或过度的情况，这使其成为希望优化运营效率的企业的绝佳选择。

鉴于其灵活性，GraphQL 成为越来越受欢迎的查询语言和 API 运行时也就不足为奇了。²然而，随着 Web 和移动应用程序变得越来越复杂，部署单个整体 GraphQL 服务器（及其所有依赖项）可能会变得难以为继。联合通过帮助不同的子图作为一个统一的 GraphQL 服务协同工作，简化了 GraphQL 生态系统。

实施联合 GraphQL 架构涉及以下关键流程。

定义子图模式涉及到确定领域边界，并决定这些边界应该如何交互。

在联合架构中，每个子图模式代表整个数据图的特定部分；它包含适用于服务或领域的类型、配置、查询、变更和订阅。例如，产品服务可能具有子图模式，其中包括产品和评论等类型，而用户服务可能具有用户和个人资料这些类型。

子图模式的定义方式与标准 GraphQL 模式大致相同，但增加了联合特定的指令。联合指令提供了系统如何跨模式扩展实体以及网关如何跨服务解析特定字段的说明。它们还定义了用于引用实体的键。

举个例子，@key 指令可指定跨多个联合图标识类型的字段；部署时，此指令会提示网关从拥有指定类型的服务中检索实体。@extends 指令可指示一个子图模式中定义的类型扩展源自另一个子图模式的类型，从而便于在另一个服务中（使用附加字段）进行类型扩展。

子图服务是实现相应子图 API 业务逻辑的后端服务。每个子图服务都定义了自己的数据图部分，并处理与其领域相关的查询和变更。它们各自的解析程序从相应的数据源、数据库或 REST API 中获取任何关联的数据。

子图服务还会向联合网关显示其 GraphQL 端点，联合网关使用它们来组成整体联合模式。请记住，这些服务可以用任何编程语言编写，前提是该语言支持 GraphQL。

联合网关可协调模式组合和查询规划。在联合服务器的帮助下，网关可以伪装单个子图服务，向客户端提供统一的 API。

要配置联合网关，团队通常要指定每个子图服务的位置，并建立模式获取、查询规划、执行和错误处理所需的基础设施。就位后，网关将不断从子图服务中获取模式，以确保拥有最新版本的联合模式。

当子图服务和联合网关配置完成后，管理员就会部署整个系统。这包括预配置硬件和云资源、设置部署管道、监控系统性能以及确保资源的高可用性。

毫无疑问，一致的实时监控对于优化联合 GraphQL 环境至关重要。警惕的监控使团队能够在性能瓶颈、系统错误和计划外停机造成更大问题之前发现并解决它们。监控还能跟踪子图服务和联合网关的运行状况。

GraphQL 联合代表了针对大规模分布式系统的 GraphQL API 开发的重大进步。它使团队能够独立处理 GraphQL 模式的不同部分，同时将他们的工作无缝集成到统一的 API 中，而不会破坏最终用户的体验。

GraphQL 联合还具有广泛的用例 - 从微服务架构部署和缓存到产品开发和运营洞察 - 并且已经被 Netflix、Airbnb、GitHub 和 Expedia 等公司采用。

GraphQL 联合还可以促进：