1.3 机器准备：CVM 规格与域名备案

场景：第一次买服务器被备案拦住

选型定下来后，我周一下单买了一台广州地域的 CVM，两核四G，想着周三就能把接口部署上去。结果周五还在折腾备案。原因是小程序的域名必须备案过、而且必须是 HTTPS，否则 wx.request 连不上。我们第一次备案，管局审核花了九个工作日，中间因为网站备注里写了社区互动类描述被打回来一次，说表述太模糊，改成具体的信息资讯服务说明后才通过。这九天里，后端写好的接口只能在自己电脑上跑，前端对着 mock 数据联调，白白等了一周多。

机器规格的纠结也花了时间。一开始我倾向买四核八G一步到位，但财务提醒我先跑两个月看看实际压力。于是先买两核四G，加了弹性告警，CPU 连续十分钟超过百分之八十就自动升级或加机器。后来证明这个决定是对的，日志量大涨之后瓶颈不在 CPU 而在磁盘 IO，升配的方向完全不一样，一步到位的钱会花在错误的地方。

证书也是个小坑集中地。第一年我们用的免费证书，每三个月要手动换一次，有次换晚了一天，小程序里直接整个接口不可用，用户还以为我们倒闭了。后来全部改成自动续期的长期证书，把到期提醒挂到 CLS 告警群，这才没有再出过岔子。这件事告诉我们：任何有到期时间的资源，都必须配上自动续期或者告警，靠人记是不靠谱的。备案、域名实名、SSL 证书申请、对公账户验证，每一步都有各自的工作日周期，串行排布可以拖到三周，并行排布一周能搞定大半。

还有一件事值得交代：机器不是买完就一劳永逸。第一台 CVM 陪我们跑了四个月，从八千日活撑到三万，期间加过一次内存、换过一次带宽计费方式。等到日活破五万，两核四G明显吃力，接口耗时九十五线从两百毫秒涨到六百毫秒，我们才按扩容流程升到四核八G。整个过程中真正帮我们做决定的不是经验，是上线时存下来的那组压测基线，没有基线的话升不升、升哪里全是拍脑袋。

方案：规格按监控选，拓扑就近 Region

方案的核心就一句话：先买小，靠监控决定扩容方向，而不是先买大。我们最终确定下来的初始规格如下表，核心原则是应用、数据库、缓存尽量同地域同可用区，内网互通不费公网流量。组件之间的调用只要走内网，既便宜又快，还天然安全：

规格演进也留个表，给同样在犹豫买多大的同学一个参照。整个升级路径是被动监控驱动的，没花过一次冤枉钱在没必要的提前升级上：

同地域这条经验是用延迟换来的。最初我把 CLS 选成了北京地域，日志写入要走公网，高峰期丢日志偶尔还阻塞接口，改到广州内网后写入耗时从四十毫秒降到三毫秒。备案直接走腾讯云的小程序备案通道，主体是公司的就准备营业执照和对公账户，个人主体需要身份证和人脸核验，审核期间网站不能对外提供访问，但可以先用 IP 跑自动化测试。规格选择上我们还做了一个压力基线：上线前用压测脚本把接口打一遍，记录 CPU、内存、响应耗时三个基线值，后续扩容判断全部对照基线做。

配置与代码

机器拿到手第一件事不是装 Node，而是配安全组。只开 22 和 443，MySQL 和 Redis 一律只在内网放行，CVM 上的 Node 进程监听内网卡。这一步如果漏了，等于把数据库暴露在公网，是一件非常危险的事。清单里还有一项容易漏：安全组规则改完要养成随手复核的习惯，我们出过一次乌龙，本想加一条测试规则，结果写错了端口把 HTTPS 自己堵了，自查脚本加上规则比对之后才杜绝：

安全组入站规则：
  22/tcp    源：公司出口IP
  443/tcp   源：0.0.0.0/0
  3306/tcp  源：内网网段
  6379/tcp  源：内网网段
出站规则：
  全部放行

Node 环境用 nvm 装长期支持版，进程管理交给 PM2，开机自启和崩溃重启都靠它。部署完先用压力脚本打一轮基线，基线数据存档，扩容时拿出来对比：

nvm install --lts
npm i koa @koa/router ioredis mysql2 -S
pm2 start app.js --name api --max-memory-restart 300M
pm2 startup && pm2 save
curl -s http://127.0.0.1:3000/health

Nginx 这边的配置也贴一段，主要是 HTTPS 转发和接口限流，证书走自动续期不用人管。小程序后台的 request 合法域名要和这里的一致，少一个二级域名都会联调失败：

server {
  listen 443 ssl http2;
  server_name api.xiangyi.example;
  ssl_certificate     /etc/ssl/xiangyi/fullchain.pem;
  ssl_certificate_key /etc/ssl/xiangyi/privkey.pem;
  location /api/ {
    proxy_pass http://127.0.0.1:3000;
    limit_req zone=api burst=20 nodelay;
  }
}

压力基线的采集脚本留着复用，每次扩容前后各跑一遍，CPU 曲线和耗时分布对比着看，效果比拍脑袋强得多。压测时记得带上真实参数分布，我们最早用全相同的参数压，数据全走缓存，看起来性能好得不得了，换成线上抽样参数后真实耗时立刻现原形。

踩坑

第一个坑就是备案被打回，原因上文说了，备注描述太笼统。第二个坑是安全组忘了放内网网段，CVM 连 MySQL 直接超时，排查了半小时才想到不是密码错，是安全组没放行。第三个坑是系统盘五十 GB 眼看够用，结果 CLS 采集器默认把日志在本地落了一份，一周写满了磁盘，Node 进程被杀，清理本地副本并把采集器改成直接投递后才好。第四个坑是弹性告警阈值设得太宽松，CPU 阈值百分之八十连续十分钟，等多触发的时候接口已经慢到用户投诉，后来调成百分之六十连续五分钟，并加上接口耗时告警联动。第五个坑是带宽，一开始按固定带宽五 Mbps 买，图片走 COS 后带宽其实够用，但某次活动页直接用了 CVM 上的静态资源，带宽瞬间跑满，所有静态资源全部搬去了 CDN。第六个坑是 SSH 安全，装完机器忘了改默认端口和禁止密码登录，某天 CLS 里出现大量扫描日志，紧急改成密钥登录加 fail2ban 才消停。第七个坑是扩容时机判断，有一阵接口变慢，直觉告诉我是 CPU 不够，升级之后才发现瓶颈在 MySQL 的连接数，白花了一次升配的钱，从那以后扩容前必先看压测基线的三项指标再下结论。第八个坑是忘记给磁盘做监控，Redis 做了一次持久化调试，快照文件把磁盘写满，整个服务直接假死，补上磁盘使用率告警后这类问题再没出现过。第九个坑是内网网卡搞错，CVM 上配了双网卡，Node 一开始监听成了公网网卡，安全组形同虚设，扫了一眼监听端口才发现，改回内网卡并加入发布检查清单。第十个坑是备案信息变更没及时同步，公司换了办公地址后营业执照更新了，但备案主体信息拖了两个月，期间被管局要求整改一次，从此任何主体变更都当天同步更新备案。

小结

机器准备这步没什么技术含量，但细节全是要命的红线：备案周期、安全组、磁盘占用、告警阈值、SSH 加固。建议下单前先跑通备案流程，规格先小后大，所有内部组件都收进内网，监控基线先于扩容。如果团队还没有自己的部署节奏，也可以先照着 Node 建站实战 的流程走一遍，把整套发布链路在测试环境磨熟，再往生产机上搬。我们的惨痛教训是：生产环境从来不应该是第一次部署的地方，多花一天在测试环境走全流程，能省下无数个半夜。特惠入口在这里：【腾讯云】云服务器 CVM，新用户限时特惠中，新用户的价格比我们当时买的续费价便宜不少。把机器当基础设施而不是一次性耗材，后面的所有运维都会顺畅很多。

延伸阅读

• Node 建站实战（从零部署的具体步骤）
• 轻量服务器建站实战（备案与域名的完整流程）
• 腾讯云综合实践（内网拓扑与组件搭配）