Serverless 与边缘部署

GraphQL 服务天生是「长驻进程」的假设：启动时构建 Schema、建立数据库连接池、预热 DataLoader 缓存、常驻内存做查询解析。而 Serverless 与边缘运行时把这三个假设全部推翻——实例随时创建、随时回收，请求之间不保证共享任何内存状态。把 GraphQL 直接搬到函数计算上，最常见的后果是「P99 延迟莫名其妙地高」和「数据库连接数在高峰期爆炸」。

但 Serverless 并非不能跑 GraphQL，只是需要针对运行时特性重新设计。本文围绕冷启动、连接复用、跨实例状态、边缘约束、持久化、可观测性六个维度，给出在 AWS Lambda、Cloudflare Workers、边缘函数三类运行时上部署 GraphQL 的工程要点。理解这些约束，也顺带解释了为什么有些团队最终选择「Serverless 处理边缘查询 + 容器常驻处理重查询」的混合架构。

一、为什么 GraphQL 与 Serverless 天然有摩擦

1.1 四个冲突点

1.2 冷启动的真实构成

一次 Lambda 冷启动的耗时大致由四段组成：

拉取镜像/代码  →  初始化运行时  →  加载依赖（require/import）  →  执行 handler 外代码
   ~100ms          ~50ms              ~200~800ms                 ~100~500ms

GraphQL 服务通常把 Schema 构建、resolver 注册放在 handler 外（模块顶层），这样能命中「初始化阶段」，比放在 handler 内快得多。但在 Lambda 上，初始化阶段也有时间限制（约 10 秒）与费用（初始化计费），所以既不能把所有东西都塞进去，也不能什么都不做。

二、冷启动治理

2.1 把重活放在初始化阶段

// handler 外的顶层代码 = 初始化阶段，每个实例只执行一次
import { ApolloServer } from '@apollo/server';
import { startServerAndCreateLambdaHandler } from '@as-integrations/aws-lambda';
import { buildSchema } from './schema';

const server = new ApolloServer({
  schema: buildSchema(),          // Schema 构建放在顶层
  introspection: process.env.NODE_ENV !== 'production',
  plugins: [costLimitPlugin, loggingPlugin],
});

export const handler = startServerAndCreateLambdaHandler(server, {
  context: async ({ event }) => createContext(event), // 每请求执行
});

原则：与请求无关的东西放顶层，与请求相关的放 context。Schema、resolver 表、指令定义、编译好的查询缓存都属于前者；用户身份、DataLoader 实例、数据库事务属于后者。

2.2 打包体积与依赖裁剪

冷启动时间与包体积强相关。GraphQL 服务的体积膨胀通常来自三处：

用 esbuild / swc 做一次 bundle 并开启 minify，通常能把体积压到原来的 1/3。Cloudflare Workers 对包体积有 1MB（免费）/ 10MB（付费）的硬限制，这一步不是优化而是必须。

2.3 预置并发与预热

AWS Lambda 提供预置并发（Provisioned Concurrency），让指定数量的实例常驻，消除冷启动；代价是这部分容量按小时计费。策略：

• 对延迟敏感的核心端点（如 me、homeFeed）配置少量预置并发（如峰值 QPS 的 20%）；
• 其余流量靠按需扩容 + 冷启动兜底；
• 用 Application Auto Scaling 按时间表（工作日白天多、夜间少）动态调整预置并发数。

Cloudflare Workers 没有冷启动概念（V8 isolate 启动在毫秒级），但isolate 可能在任意时刻被回收，同样不能假设内存状态持久。

2.4 冷启动的可观测性

不要凭感觉判断冷启动。在 handler 里记录 process.env.AWS_LAMBDA_LOG_STREAM_NAME 或判断实例是否首次执行，把「冷启动标志」写入日志与 trace：

let isColdStart = true;
export const handler = async (event) => {
  const cold = isColdStart;
  isColdStart = false;
  // 把 cold 作为 span 属性上报，统计冷启动比例与耗时分布
  return runWithTrace({ coldStart: cold }, () => server.handle(event));
};

有了冷启动比例与 P99 分布，才能决定预置并发该配多少。

三、连接与状态管理

3.1 数据库连接：从「池」到「代理」

Serverless 最大的坑是连接池。假设数据库允许 100 个连接，Lambda 并发 500，每个实例建一个池（哪怕池大小设为 1），也会瞬间打满数据库。两种解法：

连接代理的典型实现是 RDS Proxy 或 PgBouncer：函数侧把连接池设小（甚至 max: 1），代理侧做多路复用。注意代理引入了一层额外延迟（约 1~3ms），对极低延迟场景要权衡。

无服务器数据库（如 Neon 的 HTTP 驱动、Cloudflare D1）走的是另一条路：把「连接」换成「HTTP 请求」，天然适配无状态运行时。代价是事务能力受限、延迟受网络往返支配。

3.2 DataLoader 的跨实例失效

DataLoader 的批处理与缓存都基于「同一事件循环内」的假设。在 Serverless 中：

• 批处理仍然有效：同一次请求内的多个 load(id) 依然会被合并成一次查询，因为它们在同一个实例、同一次调用内。
• 缓存基本失效：下一次请求可能落在另一个实例，缓存不共享。

因此 Serverless 场景下必须把 DataLoader 的缓存职责外移到 Redis 等外部存储：

const userLoader = new DataLoader(async (ids) => {
  const cached = await redis.mget(ids.map((id) => `user:${id}`));
  const missIds = ids.filter((_, i) => !cached[i]);
  const fetched = await db.users.findMany({ where: { id: { in: missIds } } });
  await redis.mset(/* 回填缓存 */);
  return ids.map((id) => cacheMap.get(id));
}, { cache: false }); // 关闭内存缓存，避免实例内陈旧数据

注意 cache: false：在无状态运行时里，内存缓存的收益低（实例随时回收），而陈旧数据的风险高（实例可能存活数分钟）。把缓存交给 Redis，配合明确的 TTL 与失效事件，语义更清晰。

3.3 APQ 与查询白名单的持久化

自动持久化查询（APQ）依赖服务端记住「哈希 → 查询文本」的映射。在 Serverless 中，这份映射必须放外部存储：

// APQ 存储接口，用 KV / Redis 实现
const apqStore = {
  async get(hash: string) {
    return kv.get(`apq:${hash}`, 'text');
  },
  async set(hash: string, query: string) {
    await kv.put(`apq:${hash}`, query); // 可设长 TTL，或永不过期
  },
};

Cloudflare Workers 的 KV 读取延迟低但最终一致，适合「写入少、读取多」的 APQ 映射；Redis 强一致但需要额外服务，适合对一致性敏感的白名单场景。持久化查询的原理与安全价值参见 持久化查询与生产安全 。

3.4 限流计数器的位置

基于内存的限流在 Serverless 中完全失效——每个实例各算各的。必须用外部计数器：

如果已有 API 网关（Kong/Envoy/Cloudflare），把限流放在网关层比放在函数内更省事——函数实例数不定，网关是唯一稳定的计数点。成本模型的细节见 限流与成本控制 。

四、边缘运行时的约束

4.1 边缘运行时不是 Node.js

Cloudflare Workers、Deno Deploy、Vercel Edge 运行在 V8 isolate 上，只实现 Web 标准 API（fetch、Request/Response、crypto、streams），没有 fs、net、child_process、原生 TCP 连接。这对 GraphQL 服务意味着：

4.2 SDL 与 Schema 的构建方式

边缘运行时无法在运行时读文件，SDL 必须在构建期变成代码：

// 构建期生成：schema.graphql -> schema.ts
export const typeDefs = /* GraphQL */ `
  type Query { me: User! }
  type User { id: ID! nickname: String! }
`;

或者用代码优先（code-first）方案（如 Pothos）直接以 TypeScript 定义 Schema，构建期编译成 JS，运行时零文件依赖。代码优先在边缘场景反而更顺手。

4.3 边缘的订阅与实时

GraphQL 订阅需要长连接，而边缘函数的执行模型是「请求-响应」。可行路径：

• SSE：边缘函数返回 text/event-stream，用 ReadableStream 持续推送。多数边缘平台支持，但有最长执行时间限制（如 Workers 的 CPU 时间与墙钟时间限制）。
• Durable Objects：把「订阅会话」放在 Durable Object 里，一个对象负责一组连接，天然支持 WebSocket 与状态持久。
• 降级到轮询：对实时性要求不高的场景，用短轮询 + 缓存反而更省心。

订阅在 Serverless/边缘的完整方案对比参见 实时订阅与 SSE 推送 。

4.4 边缘执行与源站回源

边缘部署的核心收益是就近执行：把 GraphQL 网关放在离用户最近的节点，只有需要查数据库时才回源。这要求把「可边缘化的部分」和「必须回源的部分」拆开：

这种拆分与 边缘缓存与 CDN 的思路一脉相承：边缘负责「便宜且高频」的工作，源站负责「昂贵且个性化」的工作。

五、部署形态对比

5.1 三种形态

5.2 选型建议

• 突发、低频、对延迟不敏感：Lambda。按需付费，无空闲成本。
• 全球低延迟、以读为主：Workers。边缘执行 + 缓存，写操作回源。
• 重查询、长连接、强状态：容器。DataLoader 缓存、连接池、订阅都能正常工作。

混合架构往往是最终解：边缘做鉴权、缓存与轻查询，源站容器做重聚合与写操作。这也解释了为什么很多团队「先上了 Serverless，后来又补了一套容器」——不是 Serverless 不好，而是不同工作负载适合不同形态。

5.3 流式响应与增量交付

@defer/@stream 需要流式响应体，而 Lambda 默认缓冲整个响应。要支持增量交付，需启用响应流式传输（Lambda Response Streaming）或选择原生支持流式的运行时。在边缘运行时上，用 ReadableStream 直接构造 Response 即可实现逐块下发：

export default {
  async fetch(request: Request, env: Env) {
    const stream = new ReadableStream({
      async start(controller) {
        const encoder = new TextEncoder();
        for await (const chunk of executeIncremental(request, env)) {
          controller.enqueue(encoder.encode(JSON.stringify(chunk) + '\n'));
        }
        controller.close();
      },
    });
    return new Response(stream, {
      headers: { 'content-type': 'application/jsonl' },
    });
  },
};

增量交付的协议细节与客户端集成参见 请求批处理与增量交付 。

六、部署配置与 CI/CD

6.1 配置即代码

Serverless 的部署配置应当与代码一起入库，避免「控制台点出来的环境」成为无法复现的黑盒。两种主流形态：

Cloudflare Workers 用 wrangler.toml：

name = "graphql-edge-gateway"
main = "src/index.ts"
compatibility_date = "2026-09-01"
compatibility_flags = ["nodejs_compat"]

[vars]
ENVIRONMENT = "production"

[[kv_namespaces]]
binding = "APQ_KV"
id = "xxxxxxxxxxxxxxxx"

[[d1_databases]]
binding = "DB"
database_name = "gateway"
database_id = "yyyyyyyy"

[observability]
enabled = true
head_sampling_rate = 0.1

AWS Lambda 用 Serverless Framework 或 SAM：

service: graphql-api
provider:
  name: aws
  runtime: nodejs20.x
  memorySize: 1024
  timeout: 10
  environment:
    NODE_OPTIONS: '--enable-source-maps'
functions:
  graphql:
    handler: dist/handler.handler
    url: true
    provisionedConcurrency: 5
    events:
      - httpApi:
          path: /graphql
          method: post

memorySize 与 CPU 绑定：Lambda 的 CPU 配额随内存线性增长，1024MB 通常比 512MB 更快且（因执行时间缩短）不一定更贵。上线前用压测对比几个档位，而不是拍脑袋选最小的。

6.2 灰度与回滚

Serverless 的发布是全量替换，没有滚动更新。要灰度必须靠流量切分：

• Lambda 用别名（alias）+ 加权别名，把 10% 流量指向新版本；
• Workers 用版本（version）与部署（deployment）机制，按百分比分流；
• 无论哪种，回滚都是「把流量切回上一个版本」，秒级完成，这是 Serverless 相对容器的优势。

6.3 Schema 变更的发布顺序

GraphQL 的 Schema 变更是契约变更，发布顺序必须保证任一时刻新旧代码都能处理流量：

1. 先发布向后兼容的 Schema 变更（新增字段、新增可选参数）；
2. 观察一段时间，确认无破坏性影响；
3. 再发布依赖新字段的客户端；
4. 最后（跨版本后）才移除旧字段。

在 Serverless 全量替换的模型下，这个顺序尤其重要——一次发布就换掉所有实例，没有「新旧实例并存」的缓冲期。Schema 兼容性检查应当放进 CI，作为部署门禁，具体流程见 Schema 治理与 Registry 。

6.4 环境隔离

至少三套环境：本地（内存 Schema + mock 数据）、预发（真实下游 + 影子流量）、生产。预发环境要能接收生产的影子流量（复制请求但不写库），用于验证 Schema 变更与性能回归。Serverless 的按需特性让预发环境的空闲成本接近于零，这是相对容器架构的隐性收益。

七、可观测性与成本

7.1 无状态下的追踪

Serverless 的可观测性难点在于「一次用户请求可能横跨多个实例与多个下游」。对策是全程透传 traceId：从边缘入口生成 traceId，写入 context，委派到下游时放入请求头，下游日志与 trace 都带上它。这样即便实例是短暂的，也能把散落的日志串成一条链。

7.2 冷启动与耗时的分离指标

必须把「冷启动耗时」与「热执行耗时」分开统计，否则 P99 会被冷启动污染，导致误判：

7.3 成本模型

Serverless 的成本 = 请求数 × 单请求价 + GB-秒 × 时长。GraphQL 的成本陷阱在于：

• 解析与校验耗时：一次复杂查询的解析可能占用几十毫秒 CPU，按 GB-秒计费时会放大；
• 长尾查询：一个深度嵌套查询拖长执行时间，账单随之上升；
• 冷启动的初始化计费：包越大，初始化越贵。

因此 Serverless 上的 GraphQL 更需要成本限制（查询复杂度上限、深度上限、超时上限），把「一个恶意深查询打爆账单」的风险堵死。成本治理的完整策略参见 限流与成本控制 。

八、部署清单

8.1 上线前检查项

• Schema 与 resolver 构建在初始化阶段，而非每请求执行
• 包体积已 bundle + minify，devDependencies 已剔除
• 数据库连接走代理或 HTTP 驱动，连接池大小已按实例数核算
• DataLoader 关闭内存缓存，缓存职责外移到 Redis/KV
• APQ 映射、限流计数、幂等键全部持久化到外部存储
• 冷启动标志已埋点，冷启动比例与耗时可见
• 查询深度、复杂度、超时三重上限已配置
• traceId 从入口透传到所有下游
• 边缘运行时未使用任何 Node.js 专有 API
• 订阅/SSE 有明确的时长上限与降级方案

8.2 一个常见的错误决策

把「所有 GraphQL 流量」一次性迁到 Serverless，往往在第一次大促或流量峰值时暴露连接数与冷启动问题。更稳妥的路径是：先迁只读、可缓存的查询，验证边缘收益；把写操作与重聚合留在容器；待基础设施（代理、外部缓存、持久化）成熟后，再评估是否扩大 Serverless 比例。

FAQ

Q1：Serverless 上的 GraphQL 一定比容器慢吗？

不一定。热执行路径上，Serverless 的 resolver 性能与容器相当（同一份 JS 代码）。差距在冷启动与连接建立：容器连接池已预热，Serverless 每次冷启动都要重连。用预置并发 + 连接代理可以把差距压到可接受范围，但成本会上升。判断标准是「冷启动比例 × 冷启动额外耗时」是否在延迟预算内。

Q2：DataLoader 在 Serverless 里还有意义吗？

有，但角色变了。它的批处理能力（同请求内合并取数）依然完整有效，这是防 N+1 的核心；它的内存缓存能力基本失效，需要外移到 Redis/KV。所以正确姿势是「保留 DataLoader 的批处理，关闭其内存缓存，缓存交给外部存储」。

Q3：边缘函数能做 GraphQL 订阅吗？

能，但受限。SSE 在多数边缘平台可用，但有执行时长上限；WebSocket 需要 Durable Objects 之类的有状态原语。对实时性要求不高的场景，短轮询 + 边缘缓存是更省心的选择。若订阅是产品核心，容器 + 消息队列仍是更稳的方案。

Q4：如何避免「一个深查询打爆账单」？

三重限制缺一不可：查询深度上限（如 10 层）、查询复杂度/成本上限（如 1000 点）、单请求超时上限（如 3 秒）。三者在请求解析阶段就拒绝超限查询，而不是等到执行阶段。再配合按用户/IP 的速率限制，把成本风险收敛到可控范围。

Q5：Serverless 部署后，本地怎么调试？

把「平台绑定」（KV、D1、环境变量）抽象成接口，本地用内存实现替换。业务逻辑与运行时解耦后，90% 的调试可以在本地完成，剩下的联调在预发环境做。这也是「Schema 构建放顶层、平台绑定放 context」这一设计原则的额外收益。

小结

在 Serverless 与边缘运行时上跑 GraphQL，本质是把「进程内状态」全部外移：Schema 构建移到初始化阶段或构建期，连接池换成代理或 HTTP 驱动，DataLoader 缓存换成 Redis，APQ 与限流计数换成 KV/Durable Objects。冷启动是可用带宽与包体积的权衡，边缘运行时是 Web 标准 API 与 Node.js 能力的取舍，成本模型则要求把查询复杂度限制当作硬约束而非可选优化。理解了这些约束，就能判断哪些工作负载适合 Serverless（突发、只读、可缓存），哪些必须留在容器（重聚合、长连接、强状态），从而做出混合架构的合理切分。

相关阅读

• 边缘缓存与 CDN
• 持久化查询与生产安全
• 限流与成本控制
• GraphQL 服务端实现深度解析
• Serverless 与边缘计算架构
• Cloudflare Workers 实战指南
• TypeScript 边缘运行时适配