GraphQL 联邦（federation）如何为微服务工作？

Question

IT Interview Practice · Accepted Answer

**联邦（Federation）** 让许多独立部署的服务各自拥有同一张图的一部分，由一个**网关（gateway）**把它们组合成一个客户端查询的单一 schema。它是 **schema stitching** 的现代替代品——在 stitching 中，网关手动合并远程 schema，而联邦把合并规则下放到子图（subgraph）自身。

## 架构

```text
                 ┌────────────────────────┐
   Client ─────▶ │  Gateway / Router      │  （组合后的 supergraph）
                 └───────┬────────┬───────┘
                         │        │  规划并扇出子查询
              ┌──────────▼──┐  ┌──▼──────────┐  ┌──────────────┐
              │ Users svc    │  │ Reviews svc │  │ Products svc │
              │  type User   │  │  extends    │  │  type Product│
              │  @key(id)    │  │  User/Prod  │  │  @key(id)    │
              └──────────────┘  └─────────────┘  └──────────────┘
```

每个服务是一个**子图（subgraph）**。一个类型由某个服务拥有，并被其他服务**扩展（extend）**。`@key` 指令指明跨服务标识一个实体的字段。

```graphql
# Users 子图拥有 User
type User @key(fields: "id") {
  id: ID!
  name: String!
}

# Reviews 子图用它自己拥有的字段扩展 User
type User @key(fields: "id") {
  id: ID! @external          # 在别处声明；此处通过 key 引用
  reviews: [Review!]!        # 这个子图贡献这个字段
}
```

当一个查询跨越多个服务时，网关会**规划（plan）**它：先从 Users 取回 `User`，再用 `{ id }` 调用 Reviews 子图的**实体 resolver**（`__resolveReference`）来填充 `reviews`。

```js
// Reviews 子图解析网关交给它的 User 引用
const resolvers = {
  User: {
    __resolveReference: (ref, ctx) => ctx.reviewLoader.load(ref.id),
  },
};
```

## 联邦 vs stitching

stitching 把合并逻辑集中在网关（脆弱，网关必须了解所有人）。联邦把所有权**去中心化**：团队可以独立演进各自的子图，组合在 CI 中被校验。代价是更复杂的网关/router 以及跨服务的查询规划。

## 为什么这很重要

在规模化时，单个团队无法拥有一个庞大的单体 schema。面试官想看到你理解**通过 `@key` 的实体所有权、引用 resolver 以及查询规划**——以及为什么联邦在组织层面的扩展上胜过 stitching，而不只是技术上的优雅。

架构

联邦 vs stitching

为什么这很重要

相关问题