Node 后端实战 · 为什么用 Cloudflare Workers + D1 扛起了整个多租户 SaaS 后端？架构决策全景复盘

Node 后端实战 · 为什么用 Cloudflare Workers D1 扛起了整个多租户 SaaS 后端架构决策全景复盘各位看官这篇聊聊我最近做的一个多租户 SaaS 后端。技术栈没有走买服务器、装 Postgres、再配 Nginx的传统路线而是选了Cloudflare Workers D1边缘 SQLite KV R2 Hono Drizzle的全 serverless 边缘栈。选型阶段我其实也犹豫过——SQLite 跑 SaaS还是边缘的不少人第一反应是质疑。但项目上线跑了一段时间回过头看当时那几个架构决策基本站得住。今天把拍板的逻辑和踩过的坑一并讲清楚供同样想轻运维上云的同学参考。一、为什么是 serverless 边缘栈而不是传统服务器最朴素的原因是我不想长期养一台服务器。租 ECS 要一直付钱哪怕半夜没流量扩容得自己盯监控数据库主从、备份、打补丁样样都要管。而这个 SaaS 的体量也就几十个租户、日活几千犯不着为这点规模专门投入运维精力。Cloudflare Workers 的思路正好相反按量计费、闲置不花钱没有请求就不产生计算费用对小项目很友好。全球边缘、就近执行Worker 跑在 Cloudflare 几百个边缘节点上请求落到离用户最近的节点延迟天然低。冷启动几乎为零毫秒级启动体验上和常驻服务没有明显差别。数据库跟着 Worker 走D1 是 Cloudflare 托管的 SQLite和 Worker 同区域部署读写延迟极低不需要自己维护连接池。对中小体量、流量平稳的项目来说轻量、省钱、免运维这三个诉求一套 Workers D1 基本都能满足。二、多租户怎么隔离单库 tenant_id 行级隔离多租户 SaaS 第一个绕不开的问题是租户数据怎么隔开。我一开始也权衡过是否每个租户独立一个库最后定了单库 每表tenant_id行级隔离。核心做法每个业务表都加一个tenant_id列所有查询在中间件层被强制注入tenant_id过滤条件应用层无法绕开。二三十个租户这个量级独立库没有必要单库反而让备份、迁移、跨租户统计都简单得多。隔离方案做法优点缺点适用场景独立数据库每租户一个 D1 / 实例物理隔离最彻底备份/迁移/统计爆炸运维重大客户、强合规Schema 隔离同库不同 schema中等隔离SQLite 不支持 schema劝退Postgres 多租户单库 tenant_id 行级每表加 tenant_id查询强制过滤轻量、易备份、易统计靠应用层纪律保证隔离中小体量 SaaS三、D1 没有真事务零物理外键 db.batch 原子写这是用 SQLite 系数据库最反直觉的一点。D1 不支持交互式BEGIN / COMMIT没法开一个事务再中途查询、最后决定回滚。每条语句自带自动事务批量写要靠别的方式。所以我定了两条原则表之间零物理外键。Drizzle 的extra回调里不能塞原始sql\FOREIGN KEY会把 schema 解析拖垮完整性靠应用层保证。需要批量原子写时用db.batch([...])。它把多条写打包成一个事务边界一起提交相当于伪事务。比如一条线索转化时同时写leads状态变更和customers新建就放进同一个 batch。把传统关系型数据库外键 长事务的习惯换成应用层约束 批次提交的 edge-native 写法是用 D1 必须过的关。四、架构决策全景表把当时拍板的几个关键决策列出来方便各位对照复盘决策做法为什么多租户隔离单 D1 每表tenant_id行级几十租户级不需要独立库备份统计都省事原子写db.batch([...])替代事务D1 不支持交互式BEGIN/COMMIT预聚合看板lead_stats_daily宽表 Cron 每日写避免实时多表 GROUP BY 突破 30s 超时禁拨合规手动 / Cron 对账刷新is_blocked 联动取消日程合规优先标记即移出活跃池废弃双源leads.nextFollowupAt仅来自 schedules避免两表数据不一致审计归档D1 热存 365 天 → R2 NDJSON 冷归档单 D1 10GB 上限控制Token 吊销JWT tv版本号KV 存改密 / 全设备登出无需扫描删 RefreshToken密码存储PBKDF2(SHA-256, 10万迭代) 每用户随机盐符合行业密码存储规范鉴权签名JWTjose, HS256双密钥密钥轮转不中断服务接口校验Zod运行时类型安全挡住脏数据五、最反直觉的一个决策统计看板必须预聚合这条值得单独说。Cloudflare Workers 单次请求有30 秒超时实际可用 CPU 时间更短。如果做一个实时统计接口跨 leads / call_records / schedules 几张表 JOIN 再 GROUP BY数据量稍大就直接超时。我的解法是空间换时间建一张预聚合宽表lead_stats_daily用 Cron 每天凌晨把前一天的统计数据算好写进去看板接口直接SELECT这张表。代价是数据有一天延迟但看板本来就不是实时交易场景T1 完全够用。这一招把看板响应从可能超时变成毫秒返回。六、Token 吊销不扫库tv 版本号 KV传统做法里用户改密码要去数据库删掉所有 RefreshToken才能实现全设备登出。在 serverless 环境里这等于一次扫库又慢又费钱。我改成JWT 里带一个tvtoken version字段版本号存在 KV 里。用户改密或管理员踢人时只把 KV 里的tv加一所有旧 token 因为携带的tv对不上验证时直接拒绝——全设备登出就是一次 KV 写入秒级生效零扫描。配合 JWT 双密钥JWT_SECRET/JWT_SECRET_PREV密钥轮转也能做到不中断服务。七、踩坑与权衡这趟没那么顺这套栈有几个坑是实打实绊过我的先在这里点一下后面会单开文章细讲D1 单查询 100 绑定参数硬上限批量写入得按变量数分块宽表一张 INSERT 可能只能塞 3 行。本地 D1 复位要rm -rf .wrangler不能用 better-sqlite3 直接开 D1 文件否则内部状态污染dev 各种诡异。workerd 端口幽灵占用wrangler dev退出了真正跑 worker 的子进程还占着端口下次启动改动不生效得pkill -9 workerd。PBKDF2 在 Workers 上限 10 万迭代超了直接NotSupportedError而且 seed 脚本和运行时迭代次数必须对得上否则登录永远失败。KV 写入配额反模式限流如果每请求kv.put一次超过 16 QPS 就爆配额得改成本地内存固定窗口。这几个坑每一个都能单独成篇今天先列在这里。八、什么时候这套栈不适合你这套栈有清楚的能力边界选错场景一样会出问题。我见过有人把它硬塞进高并发事务系统最后不得不迁回 Postgres。划条线场景这套栈的短板该用什么超大量级 / 强一致事务D1 单库、无交互式事务跨表强一致难保证老老实实上 Postgres / MySQL长耗时计算Worker 30s 超时摆在那丢给队列 独立算力如 Cloudflare Queues 外部 worker复杂实时分析预聚合只解决固定看板专门 OLAP / 数仓一句话中小体量、请求短平快、能接受最终一致性的 CRUD 型 SaaS这套栈合适超出这个框传统数据库该上还是得上。技术选型服务于项目的体量和团队的人力不要为了 serverless 而 serverless。小结回头复盘serverless 边缘栈做中小体量的 SaaS 完全够用关键是把传统数据库那套事务 / 实时聚合 / 扫库吊销的习惯换掉改成批次 / 预聚合 / 版本号的 edge-native 思路。各位看官记住一点选 Workers D1 不是因为它比 Postgres 强而是因为它让小团队 zero-ops 也能把多租户 SaaS 跑起来。技术选型永远服务于体量和人力别被最佳实践绑架——能用最简单的栈 deliver就是合适的架构。如果这篇文章对你有帮助发财的小手点个小赞。也欢迎翻翻我前面几篇实战记录相关阅读NodeJS Koa 后端用户会话管理JWT, Session长短Token本文一次性讲明白node 后端和浏览器前端有关 RSA 非对称加密的完整实践前后端匹配的代码演示Nodejs 实现 Mysql 数据库的全量备份的代码演示安装和配置 Nginx 和 Mysql —— 一步一步配置 Ubuntu Server 的 NodeJS 服务器详细实录6PVE 虚拟机安装 Ubuntu Server V24 系统 —— 一步一步配置 Ubuntu Server 的 NodeJS 服务器详细实录1本文由 FungLeo 主导Deepseek 优化校阅转发请注明首发地址谢谢大家