概览

我们来深入了解一下超图的架构

在本课中，我们将

• 确定超图的主要部分、了解每个部分的作用以及它们各自的托管位置
• 描述从客户端到超图的往返请求和响应是如何工作的

从 GraphQL API 开始

首先，让我们看看GraphQLAPI 目前如何运作。

当客户端需要一些数据时，它会向 GraphQL 操作 发送到 GraphQL 服务器。服务器使用其模式、解析器 和 数据源 来检索和解析该数据，然后将其发回客户端。这是一次非常棒的体验！

此设置非常适合小型项目或团队，但随着我们的 API 不断发展，会发生什么情况？随着更多团队开始向我们的模式中添加类型、字段 和特性，我们的 API 变得越来越难以管理、扩展和部署。这是单体后端服务中常见的一大瓶颈问题。

为了解决这个问题，我们可以将 API 的功能分布到多个 GraphQL 驱动的微服务中，每个服务负责我们 API 模式的不同部分。当我们采用这种联合架构时，我们的每个微服务称为 子图，它们共同形成我们 超图的基础。

在我们的例子中，Poetic Plates API 可以成为我们 超图 中的第一个 子图。它负责模式中所有类型的和 字段 与我们的食谱有关。

随着我们 超图 的发展，它可以包含一个、两个，甚至两百个 子图！这完全取决于我们如何划分我们的特征和功能以帮助我们的团队构建和协作。因此，我们对 Poetic Plates 的宏伟蓝图未来将涉及更多的子图！

接下来就有一个很重要的问题：假如我们把 API 的功能划分为多个微服务，客户端该如何查询所有微服务？为此，我们需要超图的另一部分：路由器。

该路由器了解我们所有的子图，也知道哪个子图负责 API 架构中的每个字段。客户端向路由器发送查询，然后路由器会智能地将查询分配到适当的子图中。

该路由器充当 API 的唯一访问点，有点像 API 网关。这意味着客户端不需要担心与我们的各个子图进行通信！

GraphOS 的用武之地

这就是超图！GraphOS是帮助我们构建和管理超图的开发者平台。

GraphOS会自动设置、托管和维护路由器，这很好用。如果您想自己托管路由器，也可以！您能够查看 Apollo 文档，了解如何执行此操作。

另一方面，我们负责托管子图。我们可以使用任何符合我们需求的托管平台。

我们将提供 GraphOS 带有我们现有 GraphQL API 的 URL 和架构，该架构随后成为我们 超级图 中的第一个 子图。一旦它进入 GraphOS，我们就可以使用架构注册表、可观察性指标、安全 架构交付 等出色功能以及更多功能。

练习

关键要领

• 超图架构由一个或多个子图和一个路由器组成。
• 客户端会向GraphQL发送操作，然后通过路由器。路由器接收此请求，找出哪些子图负责解析它，并将操作发送给合适的子图。子图解析数据并将它返回给路由器，之后路由器再将其打包返回客户端。

下一步

准备好你的编码围裙，是时候烹制超图了。