使用 Cosmo 运行 Federation：无 Glue Code，无意外

Source: Dev.to

如果你已经阅读了第 1 部分，我们已经用美食广场的比喻走过了 Federation。这一次，我们来深入了解 Cosmo 实际上做了什么。

这并不是魔法。Cosmo 使用 schema 本身来验证、路由和协调你的 GraphQL 子图，从而让 bug 更少、意外更少，也不需要维护胶水代码。

🧠 Schema Composition：在上线前捕获问题

每个早晨（或 CI 运行时），每个团队都会把自己的子图 schema 提交给 Cosmo。Cosmo 将它们组合成一个 supergraph 并检查：

• 重复的类型或字段名
• 所有权冲突
• 另一个子图所需的缺失类型或字段

如果有任何问题，组合会失败并把 schema 返还给团队审查。你会看到到底是哪个服务导致了问题以及原因——在它破坏你的 API 之前。

📦 Query Planning：基于所有权的路由

一旦所有内容都组合完成，Cosmo 使用 supergraph 来规划查询的解析方式。每个字段都会映射到拥有它的子图。

示例客户端查询：

query OrderSummary {
  sides { name }
  drinks { type }
}

Cosmo 构建的查询计划如下：

1. Send `sides` query to Fry Truck subgraph
2. Send `drinks` query to Smoothie Truck subgraph
3. Stitch together response and return to client

所有这些都由 schema 元数据驱动——没有手写的路由规则，也没有猜测。

⚠️ 当出现故障时：Cosmo 处理回退

如果服务宕机或字段出错，Cosmo 不会让整个响应崩溃。相反它会：

• 按已定义的回退规则处理
• 如有配置则重试
• 在需要时返回部分数据并抑制内部错误

回退行为在路由层中定义，而不是在运行时随意猜测。

📡 实时订阅：子图 + Pub/Sub + Cosmo

订阅在 federation 中非常困难。Cosmo 通过 EDFS（事件驱动的联邦订阅）解决了这个问题。每个子图将事件发送到 NATS 或 Kafka 等 pub/sub 系统。Cosmo 监听这些流，使用组合好的 schema 和路由元数据将事件映射到正确的 GraphQL 订阅，并过滤掉客户端未请求的内容。

• 无轮询
• 无全局广播
• 无手动接线

Cosmo 通过你已经用于查询的同一套感知 schema 的路由层处理所有工作。

🧰 你专注于功能，Cosmo 负责 Federation

你不必从头构建编排逻辑。Cosmo 负责：

• Schema 组合
• 查询规划
• 运行时路由
• 错误屏蔽与回退
• 联邦订阅

它可以连接你的 GitHub 仓库，通过 CLI 部署，并让你在 Studio 中跟踪所有内容。Cosmo 不仅仅是搬运数据——它是让你的联邦平台在大规模下保持可靠的关键。

接下来： Schema 合约以及 Cosmo 如何在问题出现之前强制执行它们。