1.2 选型对比：轻量与云开发的账

场景：两个方案摆在桌面上

需求拆完，团队为部署方案吵了一下午。一派说直接上微信云开发，小程序天然集成，免运维；另一派说要自己买轻量应用服务器跑 Go，数据库用云数据库 MySQL，可控又便宜。两边都有道理，最后我们把三年的账算了一遍，才拍下来。

林姐给的硬约束有三个：每个月总成本控制在五百块以内、三家店的预约数据必须能导出（她要自己对着 Excel 盘库存和客流）、我们小团队随时能登上服务器排查问题。这三条直接影响了最终选择。

还有一个隐藏约束是她没说的：她被上一家服务商坑过。上一套收银系统把数据全攥在自家服务器上，解约时只给了一份 PDF 报表，三年的会员数据一笔勾销。所以这次她嘴上没提，但每次讨论都会绕回这个问题——数据到底放哪，能不能拽走。

吵架那天下午白板上最后留下了这句话：方案对不对，三年之后见。吵的时候都觉得自己有理，算完账就安静了。

方案：把三年账算清楚

云开发的好处是真省心：不用买服务器、不用装数据库、云函数直接跑，但按量付费的计费项多到眼花。轻量应用服务器是包年包月一口价，CPU、内存、流量全给你标得明明白白。我们把两种方案在同一个量级下的成本摆在一起：

算下来稳定运营期两者的钱差不了太多，真正拉开差距的是数据归属感。预约系统跑的是一家店的核心资产，能裸 SQL 导出、能跑复杂连接查询做漏斗统计，对林姐来说比省一百块重要得多。云开发那套文档型数据库做门店 join 统计时要写一堆聚合代码，写完自己都怕，最后还是迁回 MySQL 草草收场——这是我们另一个做小程序商城的朋友踩过的坑，详见 小程序商城实战 的选型复盘。

最终架构定了：Go 写后端，部署在轻量应用服务器上；数据放云数据库 MySQL；短信走腾讯云 SMS；门店素材和二维码图放对象存储 COS；所有请求日志进日志服务 CLS。这套组合每样都是独立产品，互不绑架，哪个环节出问题都能单独换掉。

再把三年的总账算一下，这是说服林姐的关键一张表：

云开发那个是往少了算的价，一旦云函数调用频次上去，按量计费的部分不可控；轻量这一口价反而是做预算的店老板最安心的数字。

云数据库 MySQL 的档位也有讲究，我们对比了三个：

我们选的是中间档，预约库宕机三分钟对林姐就是一次信任崩塌，多花六十块买个主从秒级切换。便宜的档位不是不能省，但省钱最好省在客人看不见的地方。

配置/代码：先跑通最小闭环

选型定了第一件事不是买东西，而是先在本地把最小闭环跑通：一个创建预约的接口加一张 MySQL 表。能在本地跑通，上了轻量只是换套环境变量的事：

r := gin.Default()
r.POST("/api/booking/create", mwAuth(), createBooking)
r.GET("/api/slot/list", slotList)
r.GET("/healthz", func(c *gin.Context) { c.JSON(200, gin.H{"ok": 1}) })

轻量服务器买好之后，装好 Go 编译产物，配上 MySQL 的连接串和 SMS 的密钥，整个服务的配置就一份 env 文件，迁移和回滚都极其简单。不用玩容器编排，预约系统这个量级上 Kubernetes 属于高射炮打蚊子，systemd 拉起服务足够稳。服务跑起来之后用 top 看一眼，Go 进程占 30MB 出头，心里就有底了。

线上用的配置文件长这样，密钥不分写在代码里，全从环境变量读：

# /etc/booking/env
DB_HOST=hub-xxx.sql.tencentcdb.com
DB_USER=booking
DB_PASS=换成自己的强密码
SMS_SDK_APPID=1400xxxxxx
SMS_SIGN=林姐美甲
INSTANCE_ID=lh-xxxxx

这份配置文件本身不上代码仓库，服务器上手工放一份，交接的时候直接把文件拷给下一个人。小团队没有密钥管理服务，能用文件加权限解决的问题就不要引入额外组件。

后端语言我们也对比过一轮。团队三个人各自最熟的栈不同，最后用一张表压住了争论：

选 Go 的决定性理由是机器配置只有 2 核 2G，一个编译好的 Go 单文件占用 30MB 出头，同样的内存跑 PHP 要开 php-fpm 的进程池，Node 要带一整套运行时。这台机器还要同时跑静态文件服务和定时任务，谁占内存少谁赢。事后证明了这一点：大促那天 Go 进程在高并发下内存只涨了 20MB，换以前我们写的 PHP 服务早就要扩内存了。

踩坑：三条选型弯路

第一条弯路是差点为了省钱全塞进轻量服务器。轻量自带一个本机 MySQL，最初想把数据也放本机，后来想明白本机数据库等于数据和服务绑在同一台机器上，机器挂了备份要从文件系统里抠，而且轻量重装系统时数据盘说没就没。花四十块买云数据库 MySQL，换来的是自动备份、弹性扩容和一条内网链路，这笔钱不能省。轻量和云数据库同地域走内网，延迟只有一毫秒级，不占公网带宽，这个细节在配置安全组时记得放行 3306 端口的内网来源即可。

第二条弯路是高估了云开发的免运维。云开发的免是免在平时，出问题时排查链路完全不透明，你不知道云函数在哪里卡了多久。我们的预约接口对延迟敏感，接口慢一秒客人就刷新重提交，重复下单的处理见 并发占位与锁。必须能自己打日志自己看，轻量加 CLS 的组合反而比云开发更踏实，日志怎么做在 监控告警 里细说。

第三条弯路是纠结了两天要不要买 CVM 而不是轻量。CVM 更灵活但同等配置贵 40% 左右，轻量本质上是腾讯云把常用配置打包好的性价比产品，对这个项目绰绰有余。先够用，等真不够了再迁移也不迟，无非是重新装一遍服务、导一次数据，半天的事。轻量还自带一套防火墙和监控面板，做小项目不用折腾 VPC 和安全组细节，省下来的时间拿去调业务逻辑更划算。

小结

选型没有银弹，只有适合当前阶段的方案。我们的判断依据很朴素：数据是不是自己的、出事能不能自己查、三年总账算不算得清。轻量加 MySQL 这套组合每个月一百块出头，换来的是完全的控制权和一条随时能排障的链路，对一家连锁美甲店来说刚刚好。如果哪天林姐开到二十家店，这套架构也只需要升配加从库，不至于推倒重来。选型会上最怕两种人：一种只会说贵有贵的道理，一种只会说便宜就够了。把账算成表格摆出来，争吵自然就停了。下一节讲轻量机器到底选哪个配置最划算。

延伸阅读

• 机器配置怎么挑，继续看 机器准备
• 想看另一套轻量部署实践，翻 轻量服务器建站指南
• 技术栈与短信产品地图在 后端框架与短信地图
• 同为小程序后端的还有 小程序动态社区，思路可互相借鉴