2.2 首次上云：CVM 实例选型清单

场景：第一次买云服务器，选型表全是术语

本地集群跑顺之后，老板批了一笔预算：先把三个服务搬到云上。按量计费的控制台甩过来，几十个规格族、七八种系统盘、带宽还要分按流量和按固定带宽，五个人各查各的，会上吵了三轮没结论。最后大家承认：不是没文档，是文档太多了，缺的是一张和业务对得上的决策表。

我们的业务画像很具体：日活三万的电商，峰值 QPS 大概两千，大促时能冲到五千；Go 服务本身是 CPU 密集加少量 IO，内存占用不高。这一节就是我们从零到买完机器的全过程，主打一个可复制。

方案：先画像，再对表

选型的第一步不是看规格族，而是把业务账算清楚。我们拉了单体应用最后三个月的监控数据：峰值 CPU 使用率多少、内存占用多少、磁盘 IO 是读多还是写多、出口带宽峰值多少 Mbps。有了这些数，选型才有方向。云服务器 CVM 的官方文档在 cloud.tencent.com/document/product/213，规格族说明非常全，但第一次读容易迷路，建议先粗扫一遍记住分类逻辑，再回来对表。

规格族上我们对比过三档：

价格也拉过一张表对照（包年包月、月价，不同活动可能有出入，仅作决策参考）：

差价不大，但把每台机器对应到具体服务后，采购理由清楚，财务那边也好签字。后来大促复盘证明这个分配是合理的：订单服务的 CPU 曲线永远比另外两个尖，多花的钱花在了刀刃上。这张表现在还贴在团队 wiki 里，每次扩容先拿出来改两行。价格会随活动波动，表的存在意义不是数字精确到几块几，而是让“为什么买这个”这件事永远有据可查。

这里有个真实的教训：我们最早给订单服务也买了标准型，大促预演时压测到 1200 QPS，CPU 直接拉满，p99 抖到两秒。换了计算型实例后同样压测稳在 60% 以下。同样是 8 核，主频差一档，Go 这种计算密集的服务感受特别明显。买机器不能只看核数，这个道理课本上不写，账单教你做人。

计费方式我们也吵过一轮，最后定下组合：长期稳定的服务用包年包月（价格低），压测和临时扩容用按量计费（随开随关）。新购入口走的是腾讯云 CVM 活动页，新用户首单往往有额外折扣：https://cloud.tencent.com/act/cps/redirect?redirect=3002&cps_key=2886aaf7fd441c23ba682c6fda7a9aff&from=console 。说实话我们第一次买就是冲着活动价去的，算下来比列表价便宜三成。

系统盘最初选了高性能云硬盘，后来发现 MySQL 落在云数据库上，业务盘压力不大，改回 SSD 云硬盘省钱。真正要注意的反而是一个隐性配置：实例的公网带宽计费模式。按流量计费适合突发，按固定带宽适合长期跑满。我们按固定带宽 100 Mbps，是因为大促那几小时即使按流量也省不了几个钱，稳定最重要。这块思路和 轻量应用服务器建站指南 里聊带宽选型是一套逻辑，小业务可以直接抄。

踩坑与排查

坑一：只看 vCPU 数。 标准型 8 核和计算型 8 核价格差一截，性能也差一截。压测证明订单服务值得多花这份钱后，我们才把规格族写进采购清单，而不是随手默认标准型。

坑二：忘买弹性公网 IP。 有同事按量计费开了实例，默认不带公网 IP，结果 SSH 死活连不上，还以为安全组没配。后来养成习惯：开机先确认公网 IP 或 EIP 已绑，再进下一环节。

坑三：跨可用区裸连。 三个服务各买一台，手滑选了不同可用区，内网延迟从 0.1ms 变成 1.5ms，gRPC 调用链一长就明显。排查后统一收到同一可用区，仅在 高可用方案 里保留跨可用区容灾的讨论。

坑四：账单惊吓。 按量计费的压测机忘关，周末两天烧掉一杯奶茶钱。从此 Prometheus 里加了告警：按量实例连续运行超过 24 小时就提醒，治好了健忘症。

坑五：操作系统选错发行版。 团队里一半人习惯 Ubuntu，一半人用惯 CentOS，结果三台机器各装各的，部署脚本写两套。最后统一成 Ubuntu 22.04，原因是内核版本对 Docker 生态友好，社区资料也多。如果是历史包袱重的团队，至少保证新购实例同一发行版，别给自己加难度。

交付：一台机器到手的标准化动作

机器买完不是结束，我们固定了一套初始化流程，谁买都照着做。这件事的起因是一次低级事故：有同事新开了一台机器，直接用 root 跑服务，某天手滑执行了个带通配符的删除命令，整个运行目录没了。从那以后初始化不再是个人习惯问题，而是流程问题：脚本统一、用户统一、目录统一，任何人接手任何机器都不需要问一句“你这服务装哪了”。

# 更新系统与装齐基础工具
apt update && apt install -y build-essential git curl vim
# 装 Docker 与 compose 插件
curl -fsSL https://get.docker.com | bash
# 建工作目录与普通用户，禁掉 root 直连
useradd -m -s /bin/bash deploy
echo "deploy ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
# 改 SSH 端口并重启服务
sed -i 's/^#Port 22/Port 2222/' /etc/ssh/sshd_config
systemctl restart sshd

这几条命令看着朴素，但每一条背后都有故事：禁 root 直连是因为日志里每天几千次爆破尝试；改 SSH 端口不是为了安全（端口漂移不等于安全），但确实让日志清净了一大半，排查时不再被无效登录淹没。初始化脚本跑完，才进入装 Go 运行时、起服务的正题。

初始化的同时顺手挂一块监控。云监控的自定义维度先不搞，把基础 CPU、内存、带宽的告警阈值配上即可（文档见 cloud.tencent.com/document/product/248）。我们的阈值是 CPU 五分钟均值超过 80% 就告警，先粗后细，跑两周后再根据真实水位收敛阈值——这个思路在 第五篇云监控告警 会展开成完整做法。

另外一个小习惯：每台机器落盘一份“机器档案”，就是一个 Markdown 文件，记录谁买的、跑什么服务、规格多少、续费日期。文件放在 git 仓库里，不放在某个人的电脑里。团队小的时候觉得多此一举，等机器超过十台就知道，这份档案能省下无数次翻账单和问人的时间。

小结

选型的本质是把业务画像翻译成资源参数：峰值定 CPU，缓存定内存，IO 定硬盘，出口定带宽，稳定性定可用区。把这些填进一张表，比读十篇选型攻略都清楚。回头看，我们花在选型讨论上的时间并不冤：前三小时的对照与压测，换来了后面半年没人再为“机器是不是买亏了”开会。机器到手之后，下一件事不是装环境，而是先把这台干净的机器沉淀成镜像——这是 下一节镜像与快照 要解决的问题。如果你想把选型放进更大的视角，本书的治理篇 还有成本复盘等着你。

延伸阅读

• 2.3 镜像与快照：上线失败就回滚
• 2.4 安全组与 VPC：端口开放最小权限
• 腾讯云实践手册