1.3 机器准备：轻量应用服务器怎么选

1.3 机器准备：轻量应用服务器怎么选

场景：同一台机器要干四件事

架构定了轻量应用服务器，但点开购买页还是懵：2 核 2G 还是 4 核 8G？峰值带宽 5M 还是 8M？系统盘多大？CPU 型号看得人眼花。我们的这台机器最后要同时干四件事：跑预约接口服务、托管后台管理工作台、跑每分钟的定时任务（释放超时占位）、放一小部分静态页面。把这些需求往配置上一对，选择就清楚多了。

林姐听到我们要自己买服务器时问了一句：这玩意儿会宕机吗？诚实回答是会，但轻量带快照和监控，宕机了恢复时间以分钟计。相比之下柜台上那台老 Windows 收银机才是真正的单点隐患。

顺带一提，轻量的控制台对非技术人员友好，后来林姐自己学会了看流量监控图和重启按钮，遇到异常先截个图发群里，省了我们好多沟通成本。

项目有两个特点必须先说清楚：一是并发不高，节假日估算峰值也就两三百同时在线，不是秒杀那种量级；二是预算敏感，能省的配置坚决不堆。所以我们的选型策略是先买够用的，留一个随时能升配的后路。

顺便说一句，轻量的升配是真的方便，控制台点一下重启就生效，没过几分钟就能从 2 核升到 4 核。这给了我们底气：起步不堆配置，峰值真的顶不住再升。怕的是那种一上来买顶配、月底看账单后悔的团队。

方案：按职责任务推配置

我们把四件事逐项拆开估算内存占用，做出了下面这张选型表。比起看参数页，按任务估算更直观：

任务	预估内存	CPU 占用	备注
Go 预约服务	约 50MB	平时 2%，高峰 40%	单进程跑
Nginx 静态托管	约 20MB	忽略	工作台页面
定时任务协程	约 10MB	每分钟脉冲	释放占位锁
日志采集 Agent	约 30MB	常驻	推送到 CLS
系统与监控代理	约 200MB	常驻	这一栏最容易被忘

加起来 350MB 上下，2G 内存起步绰绰有余；CPU 两核对一个 Go 单体足够，高峰期顶满也就几秒钟。带宽是真正的瓶颈变量，着我们做了个粗算：

带宽	每秒可传	高峰撑不撑得住
1M	约 128KB，约 40 次请求	明显超时
3M	约 384KB，约 120 次	勉强
5M	约 640KB，约 160 次	够用有余
8M	约 1MB，约 300 次	浪费

小程序里点一次选时间就要拉一屏时段数据，我们测过一次列表请求约 3KB，5M 带宽理论能撑住每秒 160 次请求的传输，拟合节假日峰值没问题。CSS 和小程序包都走 CDN 加速，服务器只出 JSON，带宽压力进一步摊薄。最后下单的是 2 核 2G、5M 峰值带宽、50GB SSD 系统盘的套餐，赶上特惠一次买了三年，折算下来月租五十块出头：腾讯云轻量应用服务器限时特惠。

配置买定离手前，我们用一台临时同配机器做了轮压测，模拟国庆峰值的 200 并发：

压测场景	并发数	P99 延迟	结论
拉时段列表	200	90ms	带宽没到顶
创建预约	100	160ms	锁竞争在 MySQL
短信下发回调	50	40ms	闲置
全链路混合	260	230ms	可接受

压测救了我们一命：200 并发创建预约时 MySQL 的行锁等待明显上升，这才有机会在上线前把热点时段的锁粒度优化掉，具体做法见并发占位与锁。压测还顺带验证了 Go 进程在并发下的稳定性，高峰期 top 里的 CPU 曲线像心电图一样规律，没有出现内存泄漏迹象。

付费周期也值得算一笔账：

付费方式	月均成本	风险
按月	60 元左右	随时被价格波动影响
包年	50 元上下	中途项目黄了心疼
三年	40 元上下	绑定最深但最便宜

考虑到系统已经跑通且没有迁移计划，我们直接上了三年，省下来的钱够交大半年的短信费。对小店老板来说，一次性付费的另一个好处是财务上好记账，不用每个月对着跳动的小额账单怀疑人生。

配置/代码：开机先做的四件事

机器到手，先做初始化配置再传代码。第一件是改 SSH 端口并禁掉密码登录，只放公钥；轻量的防火墙规则里顺手放行 80 和 443，MySQL 只对内网云数据库的地址放行。改端口这步看着多余，实际上每天有大量扫描脚本在敲 22 端口，日志里触目惊心：

# /etc/systemd/system/booking.service
[Unit]
Description=booking api
After=network.target
[Service]
ExecStart=/opt/booking/server --env=/etc/booking/env
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target

第二件是挂载数据盘、第三件是开启每日快照、第四件是装好日志采集把请求日志推到 CLS。这四件事做完，后面基本都是业务开发了。定时任务直接用 Go 里的 cron 协程跑，不再依赖系统 crontab，这样服务重启不会丢任务，机器迁移也只带一个二进制文件。

Nginx 的配置只保留最必要的部分，反代到 Go 服务的 8080 端口：

server {
  listen 443 ssl;
  server_name booking.example.com;
  ssl_certificate     /etc/ssl/booking.pem;
  ssl_certificate_key /etc/ssl/booking.key;
  location /api/ { proxy_pass http://127.0.0.1:8080; }
  location /admin/ { root /opt/booking/web; }
}

小程序后端必须 HTTPS，证书用免费的，一年一换。配置越简单越好，这台机器上不跑任何与预约无关的东西，保持干净。

开机四件事里最容易被略过的是每日快照。快照是机器级别的整盘备份，一旦被勒索或者误删配置，回滚到一个小时前的状态也就是几分钟的事。费用每天几毛，属于那种出事时感激涕零的投资。快照与云数据库 MySQL 的自动备份互补：前者保机器，后者保数据，两边都攥着才睡得着。

踩坑：三个首轮配置的教训

第一个教训是差点选了 1M 带宽的套餐。做预约系统的页面看似很轻，但客人反复刷时段列表时的流量是脉冲式的，1M 带宽在节假日刷一下就超时，客人以为系统坏了，直接退出小程序去打电话——那这套系统还不如不上。实测 5M 才够，差不了几块钱的事。

第二个教训是系统盘不能只看容量要看 IOPS。最初为了省钱选了普通云硬盘，初始化时段表三万行写入时明显卡顿，换 SSD 之后问题消失。预约系统的写入频率不算高，但写入卡顿会直接传导成接口超时，最后账要算在用户体验头上。

花了三天才把四件事做完，期间顺手记录了一个开机清单，后来交接给运维时直接照单执行，省了极多口舌。这个清单现在还贴在团队 wiki 第一页：改 SSH、挂数据盘、开快照、装日志采集，外加一条别忘了给云数据库设强密码。

第三个教训是地域选择。为了便宜选了离家最近的地域，结果发现美甲店的客人分布全国各地，小程序后端请求跨地域多绕十几毫秒。一次没忍住查了下轻量的多地域价格，发现差别不大，第二个项目开始果断选了用户集中区域的地域。

第四个教训是别忘系统监控代理占的内存。光算自己业务的内存不算数，轻量自带的监控、安全代理加起来常驻两百多MB，2G 机器上一开始心里慌得很，跑了一周发现峰值还不到 70%，这才放了心。如果当时图便宜买了 1G 内存，估计现在已经在为升级迁移发愁了。

小结

轻量应用服务器的选型核心就一句话：按任务估配置，别按参数页估。2 核 2G、5M 带宽、SSD 系统盘，对我们的预约系统是甜蜜点，逢特惠还能再便宜三成。压测一遍再下单，比买完提心吊胆强一百倍。开机四件件事事做到位，后面半年基本不用登服务器。顺嘴一句：特惠活动不是天天有，下单前去官网活动页转一圈，往往能省下两三成的预算，这算是我们这种小项目最实在的省钱方法。机器配置定了，下一节把后端框架和各云产品的接入路径一次对齐。

1.3 机器准备：轻量应用服务器怎么选

1.3 机器准备：轻量应用服务器怎么选

场景：同一台机器要干四件事

方案：按职责任务推配置

配置/代码：开机先做的四件事

踩坑：三个首轮配置的教训

小结

延伸阅读