1.1 传统 vs Serverless：开发周期的减法

在正式动手之前，我和合伙人为要不要买服务器争论了整整两个周末。我写了三年传统 Web 服务，惯性思维是先开机再写代码；他是个从没运维过服务器的前端，张口就是云开发。这一节把我们当时算过的账原样搬过来：同一个图文分享需求，两种架构在开发周期上到底差在哪，以及最后为什么是 Serverless 赢了。

场景：一个不大不小的图文应用

需求列出来其实很朴素：

• 用户能发图文，正文支持 Markdown 排版
• 列表页能分页刷，详情页能看全
• 点赞和评论要有，但允许晚一版再上线
• 图片走对象存储，CDN 分发
• 内容审核合规第一位，违规图文不能漏

负载预估也很保守：DAU 几百到几千，每天几百张图片，峰值不超过一百 QPS。这个量级放传统架构里属于最小那一档，但该干的活一样不少，服务器不会因为项目小就少装一个组件。

合伙人当时撂下一句话：你这个应用前三个月可能连一百个活跃用户都没有，但服务器不会因为没人访问就少收你一分钱。这句话成了压垮传统方案的最后一根稻草。

除了开发周期，还有个约束是团队结构：就我们两个人，一个写前端一个写接口，谁也没有精力兜底服务器运维。任何一个半夜的磁盘告警、一次数据库慢查询把 CPU 拉满，都意味着第二天顶着黑眼圈去上班。这种事在传统项目里一年总能碰上两三回。

传统架构的账单

按老路子走，采购清单和排期大概是这样：

算下来光把架子支起来就要一周，而接下来一年我还得惦记着续费、证书续期、安全补丁。对一个白天还要上班的独立开发者来说，这些隐性成本才是最贵的。

钱也得算一笔。最低配的轻量服务器一年也要好几百块，再加上域名、可能的对象存储和 CDN，第一年的固定开销奔着一千五去了，而应用前三个月可能根本没有流量，这笔钱花得多少有点冤。

传统路线上线之后的日常同样不省心，随便列几条每天都会打交道的东西：

# 传统服务器的真实日常
systemctl status nginx       # 看服务是否活着
systemctl restart mysql      # 慢查询搞挂了重启
pm2 restart api              # 应用进程重启
df -h                        # 看磁盘还剩多少
crontab -l                   # 检查备份任务还在跑

这些命令每一条都不难，但它们永远在后台占着你一部分注意力。对独立开发者来说，注意力才是最稀缺的资源。

更难受的是排期不可控。买机器要等审核，备案要等审批，证书签发也要等。每一件单独看都是小事，串起来就是一周原地踏步，产品上线日期一推再推。

Serverless 的减法

云开发这类 Serverless 方案把上面整张清单砍掉了大半，我们逐项对比：

把费用也折到同一张表里更直观，下面是我们按第一年用量做的粗算：

我后来把这本书的项目从零跑通也确实没超过十分钟，详见本书目录里的环境搭建一节。最关键的一点其实是心智负担：不需要再记着哪台机器上跑着什么进程、哪个证书下个月过期，写完函数部署上去就完事，再也不用半夜爬起来重启服务。

弹性那一行也值得多说两句。传统架构碰到一次活动带来十倍流量，你得手动升配，升早了浪费钱、升晚了网站挂。云函数自动伸缩特性之后，我们做了一次小范围分享，流量短时翻了几十倍，函数自动扛住了，活动结束自动回落，全程无人值守。这种体验传统架构给不了小团队。

先用命令感受一下

口说无凭，装好 CLI 实际跑几行最有体感：

# 安装云开发命令行工具
npm install -g @cloudbase/cli
# 登录腾讯云账号
tcb login
# 查看已有的环境列表
tcb env list
# 一键创建新环境（按提示交互填写）
tcb env create my-app-env

几条命令下来，数据库、存储、云函数、静态托管全都有了。再写个最简单的云函数验证链路：

# 在项目目录初始化函数
tcb fn init hello
# 部署到云端
tcb fn deploy hello
# 本地直接调用测试
tcb fn invoke hello

前端本地开发也完全不受影响，另开一个终端：

# 前端本地起开发服务器
npm run dev
# 改完某个函数一键重新部署
tcb fn deploy list --force

如果换成传统架构，同样的能力你得分别去装 MySQL、挂载磁盘、配 Nginx、再找个对象存储 SDK 接进去，一天能搞完都算手速快。而这里从安装到调用成功，一个晚上一边看剧一边敲就弄完了。

踩坑：Serverless 也不是完全没有代价

减法做多了，自然会有新的问题冒出来，提前知道比上线后被坑强：

第一是冷启动。云函数长时间没人调用会缩到零，下一次请求要先冷启动，图文列表接口首次响应可能多出几百毫秒，用户体感上就是进列表卡一下。我们的做法是给列表接口加低频定时预热，比如每十分钟打着定时器空跑一次，让函数保持热状态，具体怎么配在后面云函数触发器一节会详细展开。另外把函数超时时间设到合理值也很重要，默认值对图片处理类的函数往往不够用。

第二是本地和线上的差异。CLI 提供了本地调试能力，但触发器、定时任务这些行为在本地模拟不完整，有些 bug 只有部署上去才现形。最好尽早建一个测试环境走真实链路验证。这一路上我们踩的坑，在腾讯云实践里也能找到同款复盘。

第三是调试链路变长。函数看不到进程，出问题只能靠日志。后来我们养成习惯，每个函数入口先打印一份结构化的入参，出问题时一眼能定位是参数传错还是逻辑走偏。日志检索的细节在监控与成本那一节单聊。

第四是厂商 API 绑定。写了云函数、用了云数据库，迁移成本就真实存在了。对独立项目来说这不算致命，但你要清楚：选 Serverless 本质上是用灵活性换效率，换不换划算取决于你的应用生命周期。

小结

如果你的应用是图文这种典型的读多写少、流量平稳的形态，Serverless 的减法是实打实的：运维清单清零、上线周期从周缩到天、成本从固定包年变成随用随付。代价是接受冷启动、按厂商 API 写代码、换一套调试思路。对我们这个项目来说，这笔买卖划算。

反过来说，如果你的应用是长时间高并发、且有大量长连接，或者团队已经有成熟运维体系和闲置机器，那传统架构可能仍然更合适。选型没有银弹，这一节只是把图文类小应用这笔账算给你看。建议动手前把本书目录的后续实操章节扫一遍，确认Serverless的协作方式你愿意接受，再正式投入。

下一节聊聊另一个一度很有诱惑的选项：既然只想快点上线，为什么不直接用一个建站 SaaS 呢？我们对比之后发现，省下的那点时间，会在某一天想加一个自定义功能时连本带利还回来。

延伸阅读

• Python 云开发实战目录：本书章节索引与环境搭建实操
• 灯塔站点实战：轻量服务器路线的完整交付案例
• 腾讯云实践：更多云上项目的选型复盘