将 GraphQL 单体迁移至 Apollo Federation
我们一直在寻求改善 Rapid 开发人员体验的方法。在我们不断寻求提高开发环境的可扩展性、灵活性和性能的过程中，我们最近完成了一项具有广泛益处的重大任务：从 GraphQL Monolith 切换到 Apollo Federation。
任何经历过这种转变的人都知道，这不是一个胆小的人能做到的。但结果值得付出努力。
在这篇文章中，我们将分享一些有关 GraphQL 和 Apollo Federation 的背景信息，以及我们的体验如何，以及我们为何对这一举措感到高兴。
GraphQL 与 Apollo Federation 详解
您可能通过开发人员的小道消息听说过 GraphQL 和 Apollo Federation，但可能并不真正了解它的组成和功能。简而言之，它是一种通过将多个 GraphQL 服务组合成单个 API 模式来构建 GraphQL API 的模式。它是一种强大的开放式架构，用于创建组合多个 GraphQL API 的超级图。
Apollo Federation 提供了一种将大型、复杂的 API 架构分解为更小、更易于管理的服务的方法，这些服务可以独立开发和维护。这意味着后端开发人员可以获得灵活性和服务隔离，而最终用户体验则保持不变：他们继续以相同的方式使用子图。
GraphQL 本身是一种 API 查询语言，由 Facebook 于 2012 年开发，并于 2015 年开源，允许用户以精细的特定级别请求数据。作为使用 GraphQL 的开发人员，您可以轻松：
- 描述您的数据
- 提出你想要的
- 减少呼叫次数
- 接收可预测的数据
因此，如果您使用 GraphQL 查询语言来处理 API，则迁移到 Apollo Federation 可以简化处理复杂 API 的工作流程。
为什么我们决定使用 Apollo Federation？
Rapid 之前的 GraphQL 实例存在问题，原因如下。我们有一个代码库，供多个团队共享，共同开发功能 — 而且我们在部署到我们环境中的同一个工件中使用同一个代码库。
由于大约 30 名开发人员同时处理同一段代码，我们最终在部署中遇到很多冲突。
例如，如果我们的某位开发人员发布了一个包含错误的损坏代码，那么所有团队都将无法取得进一步进展。此外，如果我们尝试部署多个功能，而这些功能都包含一个损坏的代码，那么我们必须将它们全部回滚到上一个稳定的迭代版本。
而当涉及到域名所有权和标准时，我们有：
- 所有权不明确
- 多个团队采用不同的编码标准
- 对代码审查责任人的困惑
总的来说，我们的 GraphQL 实例是我们开发的瓶颈。
相比之下，Apollo 联邦鼓励一种称为“关注点分离”的设计原则，这使得不同的团队可以在一个图中处理不同的产品和功能，而不会互相干扰。我们知道 Apollo 联邦将使我们的开发人员能够处理独立的 GraphQL 服务，每个服务都有自己的架构和数据源。通过分离代码库，我们的开发人员将能够更好地进行更快的迭代并体验更无缝的工作流程。
移至阿波罗联邦
转向阿波罗联邦是一个复杂的过程，所以我们知道需要分阶段解决。
以下是我们采取的步骤：
- 创建联邦服务和基础设施：我们将新服务纳入 GraphQL API 配置，这使我们能够开始使用联邦。每个服务都有自己的 GraphQL 架构和数据源。
- 重构 API 网关：我们将旧的 API 网关转换为独立运行，或者在必要时作为单个子图运行，包含多个微服务并由图路由器组成。这使我们能够：
- 将网关整体拆分为多个服务
- 使团队能够继续无缝协作
- 建立阿波罗联邦基础设施
- 无需停机即可部署
- 将网关作为子图连接到联邦：通过将 API 网关作为子图使用，我们能够将一些与逻辑相关的图移动到单独的服务。我们还通过使用联邦基础设施来逐步实现这一点，以服务于 API 网关图和迁移到另一项服务的图部分。
- 通过测试和部署逐步发布：第一步是仅在内部使用联合网关，以便我们能够测试流程并查找和修复任何错误。然后，我们进行了逐步发布：起初，只有 1% 的用户使用联合网关，然后是 5%，然后是 10%、20% 等等，直到所有用户都使用联合网关。我们密切关注每一步，确保监控进度并解决任何问题。同时，我们开始将 API 网关服务分解为子图。
作为一个风险很大的大项目，这是一个巨大的团队努力。我们确保以最谨慎的态度处理开发环境的这一核心工作，我们感谢整个团队愿意参与其中。
目前进展如何
自从转向 Apollo Federation 以来，我们的开发流程得到了极大改善。由于我们将庞大而复杂的 API 分解为更小、更易于管理的服务，我们的开发人员能够更有效地工作。一个部门的开发人员可以编写代码，而不会受到其他部门代码情况的阻碍。这对我们的全球员工尤其有帮助——与我们美国团队处于不同时区的开发人员不再需要等待美国团队有空。
这意味着我们获得了更高的可扩展性、灵活性和性能——这反过来又有助于 Rapid 更快、更高质量地向最终用户提供功能。
