08-Serverless与Edge Computing基础

要点

• 传统部署、容器化部署、Serverless 三种模型的核心区别在于「谁管理运行时」
• Serverless 的核心价值是按需执行和按用量计费，代价是冷启动和资源上限
• Edge Computing 把执行推到离用户最近的节点，换取更低延迟，但运行时能力受限
• Cloudflare Workers 的 V8 isolate 模型消除了冷启动，按 CPU 时间而非执行时长计费，这对 AI 后端有特殊意义
• Serverless/Edge 的 CPU 时间上限直接影响长耗时 AI 任务的可行性
• 流式响应在 Serverless/Edge 环境中需要关注连接超时和 backpressure 处理
• Hono 的跨运行时能力让你在同一套代码下自由切换部署目标

1. 从运行时对比到部署模型

上一篇对比了 Node.js、Bun、Deno、Edge Runtime 四种运行时的差异。你已经知道它们各自的能力边界和 API 兼容性。但运行时只是执行环境的基础——真正把代码跑起来、让用户访问到，还需要一层部署模型。

部署模型决定的是「谁来管理这台服务器」。

按照运维责任从多到少，当前主流的选择有三类：

传统部署        容器化部署          Serverless
┌──────────┐   ┌──────────────┐   ┌────────────────────┐
│ 你的代码  │   │ 你的代码      │   │ 你的代码            │
│ + 进程管理│   │ + Dockerfile │   │ + 入口函数          │
│ + 负载均衡│   │ + K8s 配置   │   │ （其余全交给平台）   │
│ + 扩缩容  │   │ + CI/CD 流水线│   │                    │
│ + 操作系统│   │              │   │                    │
└──────────┘   └──────────────┘   └────────────────────┘
   你管一切       你管容器，         你只管代码
                 平台管机器

三种模型不是递进替代关系，而是适用场景不同。AI 后端可能同时用到多种模型——边缘节点处理轻量 API 路由，Serverless 函数处理突发流量的推理请求，传统服务器承载需要长连接或 GPU 的模型推理。

2. 三种部署模型对比

2.1 传统部署

你拿到一台（虚拟）服务器，安装操作系统、运行时、Web 服务器（Nginx/Caddy），配置负载均衡、进程管理（PM2/systemd），处理扩缩容和安全更新。

优势：完全控制，没有运行时限制，适合需要 GPU、长连接、自定义内核参数的场景。

劣势：运维成本高，资源按固定规格付费（不管用没用），扩容需要手动或提前搭建自动伸缩策略。

在 AI 后端场景中，传统部署通常用于：自托管模型推理（需要 GPU）、需要 WebSocket 长连接的服务、对延迟有极高要求的场景。

2.2 容器化部署

用 Docker 打包应用和依赖，用 Kubernetes（或更轻量的编排工具）管理容器生命周期。你不需要管理操作系统和运行时版本，但需要管理容器编排、镜像构建、集群配置。

优势：环境一致性好，可移植性强，扩缩容由编排器管理，资源利用率比传统部署高。

劣势：Kubernetes 本身有学习成本，冷启动（拉镜像、启容器）比 Serverless 慢，需要维护集群。

容器化在 AI 后端中常用于：微服务架构下的模型服务、需要自定义运行环境的推理服务、多租户隔离。

2.3 Serverless

你只写代码（一个函数或一个模块），平台处理运行时的启动、扩缩容、负载均衡、故障恢复。没有请求时不运行、不计费。

优势：零运维，按用量付费，天然支持从零到数千并发的自动扩缩容。

劣势：有冷启动问题（部分平台已解决），CPU 时间和内存有上限，不适合长时间运行的任务。

三种模型的关键差异：

3. Serverless 的核心概念

Serverless 这个术语有误导性——它不是「没有服务器」，而是「你不需要关心服务器」。服务器仍然在运行，只是由平台管理。

3.1 函数即服务（FaaS）

FaaS 是 Serverless 的核心执行模型。你把业务逻辑写成一个函数，平台负责在触发条件满足时执行它。触发条件可以是 HTTP 请求、定时任务、消息队列事件等。

// Cloudflare Workers 的执行模型
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url)
 
    if (url.pathname === '/api/chat') {
      return await handleChat(request, env)
    }
 
    return new Response('Not Found', { status: 404 })
  },
}

这个函数就是全部——没有 HTTP 服务器要启，没有端口要监听。平台接收请求，把请求传给你的函数，拿回响应返回给客户端。

3.2 按需执行与按用量计费

传统部署下，服务器 24 小时运行，不管有没有请求。Serverless 下，没有请求时不分配计算资源。

计费维度因平台而异：

对 AI 后端来说，计费模型直接影响成本结构。如果你的 AI 服务流量波动大（白天高峰、夜间几乎无人用），Serverless 的按用量计费可以显著降低成本。

3.3 自动扩缩容

Serverless 平台自动处理扩缩容。从 1 个并发请求到 10000 个并发请求，平台会自动分配对应的执行实例。你不需要配置最小/最大实例数（部分平台允许设置上限）。

这对 AI 后端意味着：流量高峰期不需要担心容量不足，流量低谷期不需要为闲置资源付费。

但有一个隐藏问题：扩缩容速度取决于平台的实例复用策略。如果一个实例处理完一个请求后被回收，下一个请求需要重新初始化（冷启动）。

3.4 冷启动问题

冷启动是 Serverless 最受关注的问题。当平台需要启动一个新的执行实例时，会产生额外的初始化延迟：

请求到达 → 平台分配实例 → 加载运行时 → 执行初始化代码 → 处理请求
                              ↑
                         这部分是冷启动开销

冷启动延迟取决于：

• 运行时类型：V8 isolate（Cloudflare Workers）< Bun < Node.js
• 初始化代码量：导入的模块越多、执行的初始化逻辑越重，冷启动越慢
• 平台策略：部分平台会预热实例或保持实例存活一段时间

对于 AI 后端，冷启动的绝对延迟通常在 5ms-200ms 之间。相比 AI 模型推理本身几百毫秒到几秒的延迟，冷启动在多数场景下占比不大。但如果你的 AI 服务需要极低首 token 延迟，冷启动就是一个需要优化的点。

4. Edge Computing 的核心概念

Edge Computing 不是一个独立于 Serverless 的品类，而是 Serverless 的一种特殊形态——执行环境不部署在少数几个数据中心，而是分布在全球数百个边缘节点上。

4.1 计算离用户更近

传统 Serverless（如 AWS Lambda）的执行位置在少数几个区域（us-east-1、ap-northeast-1 等）。如果你的用户在深圳，函数部署在弗吉尼亚，光是网络往返就需要 200ms+。

Edge Computing 把执行推到离用户最近的节点。深圳用户的请求在深圳或香港的边缘节点执行，网络往返可能只有 5ms-20ms。

传统 Serverless：
  用户(深圳) ──200ms──→ 数据中心(弗吉尼亚) ──200ms──→ 用户(深圳)
                        执行 AI 请求转发
 
Edge Computing：
  用户(深圳) ──5ms──→ 边缘节点(深圳/香港) ──5ms──→ 用户(深圳)
                      执行 AI 请求转发

4.2 轻量执行环境

边缘节点不是完整的服务器。为了在数百个节点上高效运行，边缘运行时必须是轻量级的：

• 不使用完整的 Node.js 运行时，而是使用 V8 isolate 或类似机制
• 不支持所有 Node.js API（如 fs、child_process），只暴露 Web Standards API
• 内存和 CPU 时间有严格上限
• 启动速度极快（微秒级）

这种取舍的原因是：边缘节点需要同时服务大量用户，每个用户的代码必须隔离且轻量。V8 isolate 可以在同一个进程中运行数千个独立执行环境，共享底层引擎但不共享内存。

4.3 代表平台

这些平台的共同特点：启动快、分布广、运行时受限。

5. Serverless vs Edge：关键区别

Serverless 和 Edge 在概念上有重叠——都是平台管理的按需执行环境。关键区别在于执行位置和运行时的完整度。

一个常见的误解是把 Edge 和 Serverless 对立起来。实际上，Vercel 同时提供 Serverless Functions（Node.js 运行时，区域部署）和 Edge Functions（V8 isolate，全球部署）。选择哪个取决于你的具体需求。

6. 对 AI 后端的影响

部署模型的选择直接影响 AI 后端的延迟、成本和可靠性。以下是几个核心维度。

6.1 延迟

AI 请求的总延迟 = 网络传输延迟 + 后端处理延迟 + 模型推理延迟。

部署模型能优化的是前两项：

• 边缘部署减少网络传输延迟：用户到边缘节点的 RTT 可以从 200ms 降到 10ms。对于首 token 延迟敏感的场景（流式聊天），这个差异用户可感知。
• 后端处理延迟：Serverless 冷启动增加 100ms-500ms。边缘部署几乎为零。

但模型推理延迟通常占大头（500ms-30s），部署模型的选择对这部分影响不大——推理在模型提供商的服务器上完成，你的部署位置只影响你到模型 API 的网络延迟。

总延迟构成（示意）：
  用户 → 你的后端：5-200ms（取决于部署位置）
  你的后端 → 模型 API：10-100ms（取决于你的后端与模型 API 的距离）
  模型推理：500ms-30s（你无法控制）

6.2 成本

三种计费模型对 AI 后端的影响：

按执行时长计费的陷阱：一个 AI 请求转发耗时 10 秒，其中 9.5 秒在等待模型 API 的流式响应（I/O 等待），实际 CPU 计算只有 0.5 秒。在 AWS Lambda 上你为 10 秒付费，在 Cloudflare Workers 上你只为 0.5 秒 CPU 时间付费。

对 AI 后端来说，大量时间花在等待模型 API 响应上。按 CPU 时间计费比按执行时长计费更合理。

6.3 可靠性

Serverless 和 Edge 的自动扩缩容天然适合应对流量峰值。AI 服务的流量往往呈突发特征——产品推广、社交媒体传播时流量可能在几分钟内涨 10 倍。

传统部署需要提前准备容量。Serverless 自动扩展，不需要预判流量。

但要注意平台的并发限制和速率限制。AI 请求通常耗时长，高并发下可能快速触及平台的并发上限或 CPU 时间配额。

6.4 CPU 时间上限

这是 AI 后端在 Serverless/Edge 环境中最容易碰到的硬限制。

如果一个 AI 请求的流式响应持续 20 秒，但实际 CPU 计算只有 2 秒，在 Cloudflare Workers 上只消耗 2 秒 CPU 时间。但在 Vercel Serverless Functions 上，它会占用 20 秒执行时长，可能触及 10 秒限制。

6.5 流式响应的注意事项

流式响应在 Serverless/Edge 环境中有几个需要注意的点：

连接超时：平台对单个请求的最大执行时长有限制。流式 AI 响应可能持续几十秒，需要确认平台允许的最大时长。

Backpressure：流式响应需要处理客户端消费速度慢于服务端生成速度的情况。在 Edge 环境中，内存和 CPU 资源有限，不处理 backpressure 可能导致内存溢出。

错误处理：流已经开始后出错，无法修改 HTTP 状态码。需要在流内发送错误事件并关闭连接。这个模式在 03 的状态码章节已经讨论过。

// Hono 中处理流式响应的基础模式
import { streamSSE } from 'hono/streaming'
 
app.post('/api/chat', async (c) => {
  return streamSSE(c, async (stream) => {
    try {
      const response = await fetch('https://api.openai.com/v1/chat/completions', {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          'Authorization': `Bearer ${c.env.OPENAI_API_KEY}`,
        },
        body: JSON.stringify({ ...await c.req.json(), stream: true }),
      })
 
      const reader = response.body.getReader()
      while (true) {
        const { done, value } = await reader.read()
        if (done) break
        await stream.write(new TextDecoder().decode(value))
      }
    } catch (error) {
      // 流中出错：发送错误事件
      await stream.writeSSE({
        data: JSON.stringify({ error: { message: 'Stream interrupted', type: 'server_error' } }),
        event: 'error',
      })
    }
  })
})

7. Cloudflare Workers 深入

Hono 知识库特别关注 Cloudflare Workers，原因有两个：Hono 最初就是为 Workers 环境设计的，Workers 的执行模型对 AI 后端有独特的优势。

7.1 V8 isolate 执行模型

Cloudflare Workers 不使用容器或进程隔离。它在同一个 V8 进程中运行多个 isolate——每个 isolate 是一个独立的 V8 执行环境，有自己的内存空间，但不能访问其他 isolate 的数据。

Cloudflare Workers 进程模型：
  ┌─────────────────────────────────────┐
  │  V8 Engine (一个进程)                │
  │  ┌─────────┐ ┌─────────┐ ┌────────┐│
  │  │Isolate A│ │Isolate B│ │IsolateC││
  │  │ 你的代码 │ │ 你的代码 │ │你的代码 ││
  │  │ 请求 1  │ │ 请求 2  │ │ 请求 3 ││
  │  └─────────┘ └─────────┘ └────────┘│
  └─────────────────────────────────────┘

这种模型的好处：

• 无冷启动：V8 引擎常驻运行，新 isolate 的创建在微秒级完成
• 内存效率高：数千个 isolate 共享一个引擎的内存，比每个请求启动一个容器高效得多
• 启动快：不需要加载运行时，不需要初始化进程

7.2 计费方式：按 CPU 时间

Workers 的计费不按执行时长，而按实际 CPU 时间。

执行时长 = CPU 计算时间 + I/O 等待时间
计费时间 = CPU 计算时间（不含 I/O 等待）

对 AI 后端来说，一个典型的流式请求：

• 执行时长：15 秒（等待模型 API 返回流式数据）
• CPU 时间：0.8 秒（解析请求、转发、逐 chunk 写入）
• 计费：0.8 秒 CPU 时间

对比 AWS Lambda（按执行时长 × 内存计费），同样的请求：

• 计费：15 秒 × 128MB

这个差异在高频 AI 服务中会产生显著的成本差距。

7.3 配套服务

Workers 不只是计算环境。Cloudflare 围绕 Workers 提供了一套完整的服务：

这意味着你可以用 Workers 构建一个完整的 AI 后端——从 API 路由、认证、对话存储、向量检索到模型调用，全部在 Cloudflare 生态内完成，不需要额外的服务器。

7.4 对 AI 后端的价值

Cloudflare Workers 对 AI 后端的核心价值：

1. 无冷启动：首 token 延迟不会因为实例启动而增加
2. 按 CPU 时间计费：流式响应的大部分时间（等待模型 API）不计费
3. 全球分布：用户就近接入，减少网络往返延迟
4. 配套服务齐全：不需要额外管理数据库、缓存、对象存储的基础设施
5. Hono 原生支持：Hono 对 Workers 的支持最成熟，hono/cloudflare-workers 适配器提供完整的绑定和环境变量支持

限制也需要注意：CPU 时间上限（付费 30 秒）对于特别长的 AI 任务可能不够；不支持 Node.js 专有 API，需要使用 Web Standards 兼容的库。

8. Vercel Edge Functions

Vercel 提供两种 Serverless 执行环境：Serverless Functions（Node.js）和 Edge Functions（Edge Runtime）。

8.1 Edge Runtime

Edge Functions 基于 Vercel 自研的 Edge Runtime，底层是 V8 isolate。它兼容大部分 Web Standards API（Fetch API、Web Crypto、ReadableStream 等），但不支持 Node.js 专有 API。

// Vercel Edge Function 示例
export const config = {
  runtime: 'edge',
}
 
export default async function handler(req: Request) {
  // 可以使用 Fetch API、Web Crypto 等
  // 不能使用 fs、path、child_process 等 Node.js API
  const url = new URL(req.url)
  return new Response(JSON.stringify({ path: url.pathname }), {
    headers: { 'Content-Type': 'application/json' },
  })
}

8.2 与 Next.js 的深度集成

如果你的 AI 后端和前端都用 Next.js，Edge Functions 可以无缝集成：

// app/api/chat/route.ts (Next.js App Router)
export const runtime = 'edge'
 
export async function POST(req: Request) {
  const body = await req.json()
  // 处理 AI 请求...
  return new Response(stream, {
    headers: {
      'Content-Type': 'text/event-stream',
    },
  })
}

Edge Functions 还可以用作 Next.js 中间件，在请求到达页面之前执行认证、重定向、A/B 测试等逻辑。

8.3 限制

Edge Functions 的主要限制：

• 不支持 Node.js API：fs、path、crypto（Node.js 版本）、Buffer 等不可用。需要使用 Web Standards 替代方案（crypto.getRandomValues()、TextEncoder 等）
• CPU 时间有限：单个请求的 CPU 时间上限较低
• 无持久文件系统：不能写文件到本地磁盘
• 冷启动比 Workers 慢：Edge Runtime 的冷启动在 10-50ms 级别，比 Workers 的 < 1ms 慢

8.4 适合场景

Edge Functions 适合：

• 轻量 AI API 代理转发
• 认证和权限校验中间件
• 请求路由和 A/B 测试
• 简单的 AI 接口（非流式或短流式）

不适合：

• 需要完整 Node.js 生态的复杂 AI 服务
• 长耗时的流式 AI 响应
• 需要文件 I/O 的场景

9. 选择部署平台的考量

AI 后端的部署选择没有万能答案。以下是具体的决策维度。

9.1 按场景选择

9.2 成本估算思路

估算 AI 后端的部署成本时，需要考虑：

1. 请求量：日均请求数 × 30 = 月请求数
2. 单次请求的平均 CPU 时间：非流式约 50-200ms，流式约 0.5-2s
3. 单次请求的平均执行时长：非流式约 0.5-2s，流式约 5-30s
4. 平台计费模型：按请求次数、按 CPU 时间还是按执行时长

粗略估算示例（日均 1 万次 AI 请求，流式，平均 CPU 1s / 执行时长 15s）：

这些数字是近似值。实际成本取决于具体使用模式。核心结论是：对于 I/O 密集型的 AI 流式响应，按 CPU 时间计费的平台（如 Cloudflare Workers）成本优势明显。

9.3 Hono 如何帮助你保持部署灵活性

Hono 的核心设计原则是「Write Once, Run Anywhere」。同一套 Hono 代码可以部署到：

• Cloudflare Workers
• Deno / Bun
• Node.js（Express、Fastify、node:http）
• Vercel（Serverless Functions 或 Edge Functions）
• AWS Lambda
• 以及更多

// 同一套代码，不同部署目标
import { Hono } from 'hono'
 
const app = new Hono()
 
app.post('/api/chat', async (c) => {
  // 业务逻辑只写一次
  const body = await c.req.json()
  // ...
  return c.json({ result: 'ok' })
})
 
// 部署到 Cloudflare Workers
// export default app
 
// 部署到 Node.js
// import { serve } from '@hono/node-server'
// serve({ fetch: app.fetch, port: 3000 })
 
// 部署到 Vercel Edge Functions
// export default app
// export const config = { runtime: 'edge' }

这种灵活性意味着你可以在开发阶段用 Node.js 本地调试，部署时根据场景选择 Cloudflare Workers 或 Vercel Edge，而不需要重写代码。

部署模型的选择会影响性能和成本，但 Hono 确保你的业务逻辑不受部署目标的约束。具体的部署配置和 CI/CD 流程会在后续的部署章节展开。

延伸阅读

• Cloudflare Workers 文档：Workers 平台完整文档，包括执行模型、计费、配套服务
• Vercel Edge Functions：Edge Functions 的能力边界和限制说明
• AWS Lambda 文档：传统 Serverless 平台的参考
• V8 Isolates 介绍：Cloudflare 关于 V8 isolate 模型的技术文章
• Hono 部署指南：Hono 在不同平台的部署方式
• Serverless 架构模式：Serverless 架构的常见模式

总结

Serverless 和 Edge Computing 是当前最重要的两种现代部署模型。Serverless 解决了「谁管服务器」的问题，让你只关注代码；Edge Computing 进一步解决了「代码在哪里执行」的问题，让计算离用户更近。

对 AI 后端来说，选择部署模型的核心考量是延迟、成本和 CPU 时间上限。Cloudflare Workers 的 V8 isolate 模型在三个维度上都有优势——无冷启动、按 CPU 时间计费（流式响应的大部分等待时间不计费）、全球分布。Vercel Edge Functions 在与 Next.js 集成时有独特的便利性，但运行时限制更多。

Hono 的跨运行时能力让你不需要在开发阶段锁定部署目标。同一套代码可以部署到 Workers、Vercel Edge、Node.js 等多个平台，部署决策可以推迟到实际需要时再做。

下一篇会深入 Cloudflare Workers 的开发环境搭建和本地调试流程，为后续的 Hono 实战章节做好环境准备。