概述
欢迎来到航行系列的第二个课程！
在第一门课程中，我们了解到Apollo 联合，它是如何工作以及它如何帮助我们模块化我们的 图并更快地扩展。我们从第一天就使用联合构建了一个名为 FlyBy 的应用程序！
在本课程中，我们将探讨联合如何帮助解决现有、非联合 图中的问题。我们将学习如何将现有的 单体结构图转换为联合图（也称为 超级图）。
为了提供管理和构建联合 图所需的观察性和治理，我们将使用 Apollo GraphOS 来提升我们的 API。Apollo GraphOS 是用于构建、管理和扩展 图 的一个完整的云平台：它提供了一组工具和服务，以便产品开发人员能专注于构建更好的应用程序和更快的速度。我们将使用 GraphOS 来管理我们的图、在本地对其进行处理，并使用 @override 指令。
查看计划：本课程的一部分涵盖了自托管 GraphOS 路由器，该路由器需要 GraphOS Enterprise 计划。如果贵组织使用其他计划，仍然可以继续，但无法完成特定的动手任务。还可以通过 注册免费的 Enterprise 试用版 来测试这一功能。
在开始之前，应该熟悉本系列 第一课中涵盖的以下概念：
- 什么是 Apollo Federation？
- 超级图的组件： 子图和 路由器
- 使用 Rover CLI
注意：本系列适用于那些习惯使用现有 GraphQL 服务器的后端开发人员。
如果您是一名不从事后端工作的前端开发人员，那么好消息是无论您是处理联邦还是非联邦图，您的工作流都是一样的。您仍然会将您所有的GraphQL 操作发送到一个单一的端点，而后台团队会处理剩下的事情！
好吧，让我们深入了解一下我们正在处理的内容！
🪐 介绍 Airlock，我们的太空旅行应用程序
想预订在浩瀚宇宙中激动人心、有时是虚构的新地方的旅行吗？那就来 Airlock 吧！
使用 Airlock，您可以找到符合您所选日期和所需床位数的房源。了解每个地方的情况以及提供的设施，如果您感兴趣，您可以一键预订您的住宿（当然前提是您钱包里有足够的太空积分）！
如果您希望出租您自己的太空套房，也可以通过 Airlock 来实现！将您的房源连同所有必要的详细信息添加到平台并开始管理您的预订。每次住宿后，客人和房东都会互相留下真实的评分和评价。
Airlock 的演变故事
在幕后，Airlock 的架构看起来像这样
Airlock 最初是一个基础应用程序，有一个小的图，定义的类型和字段非常少。随着其流行度和使用率的提高，引入了新功能，以及模式的更改和添加。
不久之后，原本不起眼的小应用程序就变成了一块笨重的巨石。随着摩擦的出现，开发人员体验正在恶化——模式更改和改进遇到了合并冲突、不一致和重复的信息。在庞大的模式文件中进行导航变得困难！新功能和错误修复正在花更长的时间进行部署。
图QL 服务器在图表中可能看起来很小，但实际上，它更像是一个巨大的巨石怪物，其中许多不同的业务领域以类型、查询和突变的形式表示，所有这些内容都包含在单个庞大的.graphql文件中！
此外，我们有多个团队和开发人员负责这些业务领域。让我们见见其中的一些人以及他们正在努力的事情。
👩🏽🚀 财务团队说：
“我们负责所有与用户、帐户和用户资料相关的事情！我们认为自己的工作范围比较小，所以不得不费力筛查架构中所有与我们预定更改无关的其他业务域，这让我们感到痛苦。”
👩🏽🏫 清单团队说：
“我们处理气闸中所有酷炫的太空租赁：其信息、便利设施，并将其链接回资料（这是财务团队的职责）。我们绝对拥有架构中当前内容的很大一部分，而且我们在新增功能和改进中进行了大量更改！通常情况下，我们与其他团队合并冲突。”
还有更多团队参与气闸开发：预订团队、评论团队和支付团队。显然，所有这些团队都在为开发、增长和扩展图形而苦苦挣扎。
为了帮助我们的气闸开发人员获得更流畅的体验，我们要将这个整体图形转换成超级图形！我们应该已经熟悉第一门课程中概述的联合架构的优势，这些相同的优势也适用于此处！
超级图形的替代旅程
如果您不熟悉操作在超级图形中的旅程，可以在 Voyage I 中查看。
我们本课程的超级图形旅程将类似于上一门课程中的旅程，有一个很大的例外：我们将开始处理一个整体图形，我们将逐步将其拆分为多个子图形。
让我们重新审视一下旅程！
首先，单体图将被转换为子图。这意味着架构的所有类型、字段和行为仍然会保留，并像往常一样工作。
接下来，我们将把子图发布到GraphOS注册表。这将触发合成。
如果合成失败，我们将收到需要修复的错误消息！如果合成成功，Uplink 将通过我们的新超图架构进行更新。
然后，路由器将获取此架构，并准备好使用此新架构来处理传入查询！
这只是我们超图之旅的开始！在此过程之后，我们将返回起点，再从单体子图中拆分出另一个子图。在对子图进行更改后，我们将需要再次发布我们的子图架构并遵循流程。
📋 迁移计划
让我们回顾一下将我们的大型单体转换为超图的具体实施细节！
首先，我们希望确保在此过程中，Web 应用客户端不会遇到任何问题，并且查询可以正常工作！
以下是我们的迁移计划中的高级步骤
我们将把整体内容GraphQL 服务器转换为子图服务器，我们在不同的端口上运行该服务器。（对超级图来说拥有仅一个子图是有效的！）该子图将发布到模式注册表。
我们将在整体内容的原始端口上创建一个运行GraphOS 路由器。该路由器将连接到模式注册表并处理之前发送到整体内容服务器的所有相同查询。
我们将开始将小型块从我们的单一整体内容子图拆分为新的特定于域的子图。这将涉及几个步骤，稍后我们会详细说明。
此过程是否听起来很熟悉？这些步骤会应用绞杀榕树方法——一种涉及逐步使用新组件替换旧系统，直到旧系统被“绞杀”并可以被完全移除的迁移技术。
练习
关键要点
一个简单的模式可能会演变成一个庞大、令人望而生畏的模式，不同团队难以浏览和处理。Federation 解决这些问题，但与从一个绿色字段应用程序相比，从现有应用程序开始时此过程将有所不同。
我们希望遵循迁移计划，用路由器替换原始整体内容服务器，以避免出现任何客户端问题。
最初，我们的 超级图模式只由一个 子图组成：初始整体架构模式。
下一步
在采取迁移计划之前，让我们启动并运行 Airlock！
分享你对本课的疑问和评论
你的反馈有助于我们改进！如果你陷入困境或感到困惑，请告诉我们，我们会帮助你的。所有评论都是公开的，必须遵守 Apollo 行为准则。请注意，已解决或已处理的评论可能会被删除。
你需要一个 GitHub 账户来在下面发帖。还没有吗？ 转而在我们的 Odyssey 论坛中发帖。