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.js | node dist/index.js | 传统服务器、Docker |
| Bun | bun run src/index.ts | 传统服务器、Docker |
| Deno | deno run src/index.ts | 传统服务器、Deno Deploy |
| Cloudflare Workers | wrangler deploy | 边缘网络 |
| Vercel | 自动检测 | Serverless |
| AWS Lambda | lambda adapter | Lambda 函数 |
这不是「理论上支持」——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 前端 | Vercel | Next.js 官方平台、自动优化 |
| 数据库 | Cloudflare D1 | 边缘 SQLite、和 Workers 无缝集成 |
| 文件存储 | Cloudflare R2 | 兼容 S3、无出口流量费 |
选择 Workers 而不是 Lambda 的核心原因:
- AI 项目对延迟敏感:Workers 的冷启动 < 5ms,Lambda 可能几百毫秒
- 全球用户:Workers 自动全球分发,Lambda 需要配置多 Region
- 成本:Workers 免费额度每天 10 万次请求,个人项目够用
- D1 集成:Workers 和 D1 在同一个平台,网络延迟最低
选择 Vercel 而不是自建前端的原因:
- Next.js 官方支持:Vercel 是 Next.js 的开发公司,部署体验最好
- 自动优化:图片优化、代码分割、ISR 都是开箱即用
- 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(前端)的组合,兼顾了低延迟和开发体验。