22.01-部署方式总览

要点

  • Hono 的「一次编写,多运行时部署」不是营销口号——同一个 app 可以跑在 Node.js、Bun、Deno、Workers 上
  • 不同运行时的部署方式差异很大:传统服务器、Serverless 平台、边缘计算
  • 选型的核心不是「哪个最好」,而是「哪个最适合你的场景」
  • 这个系列覆盖主流部署方式,最后回到项目实际用的 Workers + Vercel 组合

内容

1. Hono 的跨运行时能力

Hono 框架的一个核心卖点是跨运行时。同一份代码可以在不同平台上运行:

// src/app.ts
import { Hono } from 'hono'
 
const app = new Hono()
 
app.get('/', (c) => c.text('Hello Hono!'))
 
export default app

这段代码可以直接跑在:

运行时入口方式部署方式
Node.jsnode dist/index.js传统服务器、Docker
Bunbun run src/index.ts传统服务器、Docker
Denodeno run src/index.ts传统服务器、Deno Deploy
Cloudflare Workerswrangler deploy边缘网络
Vercel自动检测Serverless
AWS Lambdalambda adapterLambda 函数

这不是「理论上支持」——Hono 的内部实现就是基于 Web Standards API(Request、Response、fetch),这些 API 在所有现代 JS 运行时里都有原生支持。

2. 部署方式的分类

可以把部署方式分成三大类:

2.1 传统服务器

代码跑在一台(或一组)固定的服务器上。

用户请求 → 负载均衡 → 服务器(Node.js/Bun/Deno) → 数据库

典型方案:

  • VPS + PM2:最经典的方式,买一台 VPS,用 PM2 管理 Node.js 进程
  • Docker + 云服务器:容器化部署,用 Docker Compose 或 K8s 编排
  • 自建服务器:物理机或虚拟机,完全自主控制

优点:完全控制、可以跑任意语言/框架、成本可预测 缺点:需要自己运维、扩缩容复杂、冷启动不存在但故障恢复慢

2.2 Serverless 平台

代码以函数形式跑在平台托管的基础设施上,按需执行,按量计费。

用户请求 → 平台网关 → Lambda/函数 → 数据库

典型方案:

  • AWS Lambda:最成熟的 Serverless 平台,功能最全
  • Vercel:前端友好,Next.js 官方平台
  • Netlify Functions:类似 Vercel,前端生态
  • Google Cloud Functions:GCP 的 Serverless 方案

优点:不需要管服务器、自动扩缩容、按请求计费 缺点:冷启动延迟、运行时长有限制、供应商锁定

2.3 边缘计算

代码部署到全球边缘网络,请求由最近的节点处理。

用户请求 → 最近的边缘节点(执行代码) → 数据库(可能在中心)

典型方案:

  • Cloudflare Workers:最大的边缘计算平台
  • Deno Deploy:基于 Deno 的边缘平台
  • Vercel Edge Functions:基于 Vercel 的边缘函数

优点:延迟极低、全球自动分发、启动快 缺点:运行时限制更严格(无 Node.js 原生 API)、存储选择有限

3. 主流部署方式对比

维度传统服务器Serverless边缘计算
典型延迟取决于服务器位置中等极低
冷启动几百 ms ~ 几秒< 5ms
扩缩容手动或自动,需要配置自动自动
运行时长无限制几分钟到 15 分钟几十秒 CPU 时间
编程语言任意多数主流语言JS/TS/Wasm
运维复杂度
成本模型固定月租按请求/执行时间按请求
适用场景长时间运行、重计算突发流量、事件驱动低延迟 API、全球服务

4. 这个项目的实际选择

这个项目用的是边缘 + Serverless 的组合

组件平台原因
API 后端Cloudflare Workers低延迟、全球分发、免费额度够用
Web 前端VercelNext.js 官方平台、自动优化
数据库Cloudflare D1边缘 SQLite、和 Workers 无缝集成
文件存储Cloudflare R2兼容 S3、无出口流量费

选择 Workers 而不是 Lambda 的核心原因:

  1. AI 项目对延迟敏感:Workers 的冷启动 < 5ms,Lambda 可能几百毫秒
  2. 全球用户:Workers 自动全球分发,Lambda 需要配置多 Region
  3. 成本:Workers 免费额度每天 10 万次请求,个人项目够用
  4. D1 集成:Workers 和 D1 在同一个平台,网络延迟最低

选择 Vercel 而不是自建前端的原因:

  1. Next.js 官方支持:Vercel 是 Next.js 的开发公司,部署体验最好
  2. 自动优化:图片优化、代码分割、ISR 都是开箱即用
  3. Preview Deployments:每个 PR 自动有预览版本

5. 这个系列的文章结构

接下来的文章会覆盖主流部署方式:

篇目内容
22.01 部署方式总览本文——部署方式分类和选型
22.02 Node.js 部署传统 Node.js 服务器部署(PM2、Docker)
22.03 Bun 部署Bun 运行时部署
22.04 Deno 部署Deno 运行时和 Deno Deploy
22.05 Cloudflare Workers 部署Workers 的架构、V8 isolates、配套服务
22.06 Vercel 部署Next.js 在 Vercel 上的部署
22.07 AWS Lambda 部署Lambda 的架构和部署流程
22.08 Docker 容器化Docker 基础、Dockerfile 编写
22.09 Docker Compose 本地环境本地多服务编排
22.10 CI/CD 流水线GitHub Actions 自动化部署
22.11 环境变量管理环境变量和密钥管理
22.12 灰度发布灰度/金丝雀发布策略
22.13 回滚策略版本回滚方案
22.14 多环境配置开发/测试/生产环境管理
22.15 生产部署检查表上线前的检查清单

05 会详细讲 Workers 的架构(V8 isolates、和 Lambda 对比),这里先建立全局视角。

6. 选型的决策框架

选部署方式时,可以按这个思路判断:

你的项目是什么类型?
  │
  ├── 全球用户、低延迟 API → 边缘计算(Workers、Deno Deploy)
  │
  ├── 前端为主、Next.js → Vercel、Netlify
  │
  ├── 长时间运行、重计算 → 传统服务器、Docker
  │
  ├── 突发流量、事件驱动 → Serverless(Lambda、Cloud Functions)
  │
  └── 不确定 → 先从 Vercel(前端)+ Workers(后端)开始

对于 AI 项目,推荐 Workers + Vercel 的组合:Workers 处理 API 和 AI 调用(低延迟),Vercel 托管前端(自动优化)。这个组合免费额度够个人项目用很久,成本可控。

7. 小结

部署方式分三大类:传统服务器、Serverless、边缘计算。Hono 的跨运行时能力让你可以用同一份代码跑在不同平台上。

选型的核心不是「哪个最好」,而是「哪个最适合你的场景」:全球低延迟选边缘,前端选 Vercel,长时间运行选传统服务器。

这个项目用的是 Workers(后端)+ Vercel(前端)的组合,兼顾了低延迟和开发体验。