云端攒机避坑：云虚拟机实例规格、云盘性能与安全组配置指南

“攒机”这个词现在听着有点复古但凡是自己装过机器的人都懂那种感觉CPU、主板、内存、硬盘、电源、散热一样样挑参数对得上接口插得进最后按下电源键一次点亮那种爽快感是买整机给不了的。云虚拟机其实是一回事只不过你手里那堆零件变成了网页上的下拉框和滑块——选规格族、选云盘、选带宽、选镜像、选安全组。麻烦的地方在于本地攒机你至少能摸到实物插槽不对就是插不进去云端攒机你面对的是一张规格表和一串数字很多约束藏在“小字”和“另一份文档”里配错了机器照样能开起来也能跑但跑着跑着就开始掉链子。这篇聊的就是云端“攒机”里那些最容易被跳过的要点从实例规格的隐性约束、云盘性能与容量的绑定关系、公网与内网两套网络指标一直到开机前那几分钟的镜像和安全组配置。适合刚接手云上部署、或者正准备把一套本地服务整体搬到云虚拟机上的朋友也适合那些“机器买回来了但总觉得慢半拍”的人。1. 云端“攒机”里哪些零件其实轮不到你选1.1 从本地配置单到云端配置单的映射关系先把两边的零件对一遍心理预期就稳了。本地攒机你挑的是具体型号云端你挑的是“规格族”厂商在背后替你定了 CPU 型号、主板、内存颗粒、网卡芯片你能控制的只是档位和配比。这个差别看着抽象落到实操上就是一句话云端不存在“我要这颗 CPU”这种选项只存在“我要这一类算力”。我第一次搬服务上云的时候花了半小时在找“CPU 型号在哪选”最后发现根本没有这个字段那一刻才明白过来。本地攒机的零件云端对应的东西你能控制到什么程度CPU 型号与主频实例规格族通用型/计算型/内存型等只能选族和档位具体型号由厂商混配内存条容量与频率与 vCPU 绑定成固定配比不能单独加内存只能换更大的规格主板与芯片组不存在这个概念无硬盘容量颗粒云盘类型 容量完全可控但性能跟容量挂钩电源与散热由平台负责无网卡内网带宽 公网带宽 收发包能力部分可控小规格有硬上限机箱风扇噪音无顺带说一句云上确实安静这张表最有价值的一行是“内存不能单独加”。本地攒机你可以先上 16G过两月再加一条云上不行内存和 vCPU 是焊死的配比想加内存就得整个规格往上跳一档vCPU 也跟着涨钱也跟着涨。所以云上选型的第一原则不是“够用就行”而是“先算清配比再定档位”否则你会陷入“内存不够→升规格→CPU 浪费一半钱”的循环。我见过一个团队为了给一个内存吃紧的缓存服务加 8G 内存硬生生把 4 核 8G 换成了 8 核 32GCPU 利用率长期在 5% 以下纯属给平台交学费。1.2 那些“看不见但会咬人”的硬上限规格表里除了 vCPU 和内存还塞了一堆容易被划过去的数字内网带宽、内网收发包能力、云盘挂载数量上限、单块云盘的性能上限、网卡队列数。这些数字在业务量小的时候毫无存在感一旦上来就是硬墙撞上去不会报错只会表现为“莫名其妙变慢”。举个具体的小规格实例的内网带宽可能只有 1~2 Gbps你做单机压测跑得飞起一上集群做数据分片传输节点之间互相拉数据带宽瞬间打满CPU 却在旁边闲着。还有人做小包转发类服务比如高频的短连接请求带宽才用了几十兆机器的收发包能力先到顶了表现为连接超时率上升、延迟毛刺变多——因为瓶颈根本不在带宽而在每秒能处理多少个数据包。这两件事在规格表里是分开列的两行很多人只看了第一行。提示选规格的时候把“内网带宽”和“收发包能力”当成和 vCPU、内存同等级的一等公民来看。尤其是做网关、消息队列、缓存集群、分布式存储节点的这两项比 CPU 主频更决定成败。2. 规格族选型CPU 积分、混配与配比这三道坎2.1 突发性能型实例的积分机制别把它当普通机器用云端有一类便宜的规格价格能比同档常规规格低一半甚至更多宣传语通常写着“适合轻负载、间歇性负载”。它的底层逻辑是给你一个基准性能线比如按 20% 的 CPU 算力持续供给你闲的时候攒积分忙的时候花积分往上冲。听着很美坑在于积分是有限的花完就掉回基准线。我吃过一次这个亏。一套做定时任务的调度服务放在这类实例上白天基本空转积分攒得满满的压测也漂亮。结果某次上游数据源延迟触发了一次大规模补偿任务几十个进程同时跑二十分钟就把积分烧光了之后 CPU 被死死压在基准线上任务队列越堆越长等积分慢慢回血已经是两小时后的事。整个过程没有任何报错监控上就是 CPU 使用率一条平线加一条缓慢爬升的队列长度曲线特别迷惑。这类规格的正确用法明确知道自己的负载有长时间的低谷且高峰是短促的、可容忍降级的。个人博客、测试环境、内部工具站、定时触发的轻量任务都合适。反过来常驻的 API 服务、数据库、消息中间件、任何“高峰期同时也是用户高峰期”的业务一律不要碰。选之前去控制台看一眼积分余额曲线跑一周心里就有数了。2.2 同一规格族拿到不同代际的 CPU这事得提前接受云厂商通常不会承诺某个规格族对应的具体 CPU 型号同一款规格在不同时间开通、不同可用区开通底层硬件可能来自不同批次。对绝大多数业务这没影响但对两类场景有实际影响一是依赖特定指令集做加速的比如某些向量化计算、编解码库会检测 CPU 特性走不同代码路径二是做性能基线管理的你今天压测出来的 QPS明天扩容出来的新机器可能差 10%。我的处理办法很土但有效新机器上线前跑一遍统一的开机自检脚本输出 CPU 型号、核心数、缓存大小、支持的指令集标志位、磁盘顺序读写的粗测结果记到 CMDB 或者一张表里。不用每次都看但出问题时能立刻排除“是不是这批机器硬件不一样”这个变量。顺带说容器化部署的话这个差异会被调度放大——同一个服务的多个副本跑在性能不同的节点上负载均衡看起来是均分的实际慢的那个副本拖尾延迟更明显。2.3 vCPU 和内存的配比用压测定而不是拍脑袋配比这件事有行业惯例1:2 偏通用计算1:4 偏均衡1:8 偏内存密集。但惯例只是起点真正该做的是拿真实流量压一遍看两个指标CPU 使用率的稳态值和内存的常驻量。稳态 CPU 长期低于 15% 而内存吃紧说明你该往内存型方向调反过来内存长期只用三成而 CPU 顶格就该往计算型走。还有一个细节经常被忽略1 个 vCPU 通常是 1 个超线程不是 1 个物理核。对计算密集且对缓存敏感的服务比如某些编译任务、高性能计算超线程带来的收益有限甚至为负实际可用算力要打折看。如果业务确实吃满物理核选型时要么直接按 1.5~2 倍 vCPU 估算要么挑明确标注“独占物理核”或者关闭了超线程的规格类型。这个信息一般写在规格说明的角落里值得翻一翻。再补一个实操层面的别在业务低峰期做选型决策。我有次图省事凌晨两点看了眼监控CPU 8%、内存 40%愉快地定了个小规格。第二天上午业务高峰直接被打回原形。选型压测必须在真实高峰时段做或者至少拿一周的 P95 数据来算峰值和均值之间的差距往往就是规格跳档的那一档钱。3. 云盘不是硬盘容量决定性能这条暗规则3.1 三类云盘的边界别拿便宜盘跑数据库云盘大致分三档普通盘机械介质便宜、IOPS 低、延迟高、SSD 盘主流选择随机 IO 够用、高性能/低延迟盘贵给数据库、搜索、高并发写入用。选型的判断依据不是容量是随机 IO 的模式如果你的业务是大量小块的随机读写数据库的 redo log、索引查找普通盘的延迟会让你怀疑人生如果是顺序大块读写日志追加、视频转码落盘、备份归档普通盘完全够用省钱。我见过最典型的误配是拿普通盘装数据库然后抱怨“云上数据库怎么这么慢”。排查下来单次随机写延迟比 SSD 高一个数量级事务提交被拖得一塌糊涂。换盘之后同样的代码同样的数据量TPS 直接翻几倍。云盘的差价在整机成本里占比很小但在性能表现上权重极大这是少数“加钱立竿见影”的地方。3.2 IOPS 和吞吐随容量线性增长系统盘默认值是个陷阱这是云端攒机最反直觉的一条同一类云盘容量越大性能越高。厂商通常按“每 GB 给多少 IOPS、多少吞吐”来标定同时有一个规格上限。也就是说你买 40G 的盘和买 500G 的盘不只是容量差IOPS 可能差十倍。举个示意性的算例具体系数以你所用平台公布的为准这里只为说明计算方式假设某类 SSD 云盘每 GB 提供 30 个随机 IOPS单盘上限 20000。那么 100G 的盘能拿到 3000 IOPS想要跑满 20000 得买到 666G 以上。如果你的业务峰值需要 8000 IOPS按这个规则至少得 266G 起买 50G 系统盘是绝对扛不住的。由此得出两条实操结论系统盘别抠。很多人默认 40G 或 50G装完系统再放点日志就满了同时 IOPS 也低得可怜。系统盘建议直接 100G 起步成本增加有限省下的麻烦很多。需要高 IOPS 就加数据盘而不是无限扩系统盘。数据盘可以独立挂载、独立快照、独立换类型还能在多台机器之间迁移运维弹性远好于把东西全塞系统盘里。至于“一块盘不够快就用多块盘做条带”这个思路在云上是成立的两块 500G 的盘做软 RAID0 或者文件系统级别的条带性能接近翻倍。代价是可靠性下降坏一块全完所以只适合能接受重建的场景比如缓存目录、临时计算数据、可再生的中间结果。3.3 扩容可以缩容基本别想本地硬盘你可以买大了之后分区闲置云盘也一样但区别在于云盘扩容是单向的容量只能加不能减。想“变小”只有一条路——新建一块小盘、把数据拷过去、切换挂载点、删掉老盘。系统盘更麻烦涉及引导很多平台干脆不支持缩容。所以第一次开机器时的容量决策要偏保守一点宁可多买 50G。多出来的空间不会浪费日志、临时文件、镜像层、容器运行时都会偷偷吃掉不少。另外提醒一句云盘挂载数量的上限。小规格实例能挂的数据盘数量有限做多盘条带或者大规模的独立盘规划时要先确认这个数别设计完了发现挂不上去。4. 网络这一段最容易被跳过公网、内网和位置4.1 固定带宽和按流量计费用峰值和时长算一遍公网带宽的计费方式通常两种按固定带宽包月或者按实际使用流量计费。选哪个不是看感觉算一下就行。判断逻辑可以简化成这样先估出你的月总出方向流量GB再看峰值带宽需求。如果业务是访问量平稳、但峰值带宽不高比如内部管理系统、API 服务按流量往往更划算如果是持续有大流量外发文件下载、视频分发、镜像仓库固定带宽包月更稳因为流量单价乘以大流量会非常肉疼。举个粗算的例子假设固定带宽 10 Mbps 包月费用为 A 元按流量计费单价为 B 元每 GB。10 Mbps 持续跑满一个月大约能跑出 3.2 TB 左右的流量10 Mbps ÷ 8 × 86400 × 30 ÷ 1024 ≈ 3164 GB。拿这个上限值去乘 B跟 A 比较如果你实际用量远低于 3.2 TB按流量就划算接近或超过固定带宽更省。真实决策时把“峰值会不会超出固定带宽被限速”也算进去——固定带宽超了就限速业务会掉响应按流量模式一般有峰值上限但不会因为用量大而限速。还有一条常识但确实有人不知道入方向流量通常不收费出方向才收费。所以“用户上传文件到我这里”这种场景带宽成本压力比“我这边给用户下发文件”小得多。4.2 内网带宽和收发包能力分布式场景的隐形天花板前面提过一次这里展开说。内网带宽决定的是同地域同可用区内机器之间通信的上限这个数字在小规格上可能只有 1~2 Gbps而大规格能给到 10 Gbps 甚至更高。如果你在做的是需要频繁跨节点传数据的架构——分布式缓存、消息队列集群、搜索集群的副本同步、大数据作业的 shuffle——那么小规格 × 多台的组合经常会输给大规格 × 少台因为前者每台机器的内网管道都太细。收发包能力通常标为 PPS是另一个维度。它衡量的是每秒能处理多少个小数据包。带宽跑满和 PPS 跑满表现完全不同带宽跑满表现为传输慢、大文件下载时间变长PPS 跑满表现为延迟抖动、丢包、连接建立失败率上升而带宽监控看起来还很空闲。做网关、做 DNS、做短连接密集的 API 服务一定要盯这个指标。排查的时候怎么确认是 PPS 瓶颈看网卡的丢包计数和 softirq 分布如果 CPU 里软中断占用高、单核被打满而整体利用率不高同时业务侧表现为延迟毛刺基本就能锁定了。解决方向要么换规格、要么开多队列、要么把单机连接数摊到多台机器上。4.3 可用区和地域选错延迟和库存都会找你地域决定物理距离进而决定网络往返延迟这个道理大家都懂。容易被忽略的是可用区同地域内不同可用区之间的网络延迟通常比同可用区内高一个量级虽然是毫秒级但对高频交互的服务是实打实的差距而且跨可用区通信可能产生额外的流量费用。选可用区的三个考量业务机器尽量同可用区部署降低延迟关键服务做跨可用区双活保证可用性以及库存。热门规格在某些可用区可能长期缺货扩容时开不出来只能跨可用区补机器这时候前面两条就得让步。我建议的做法是主业务固定在一个可用区同时在另一个可用区预留一套可快速扩容的镜像和启动脚本缺货时不至于手忙脚乱。5. 开机前的最后几分钟镜像、初始化和安全组5.1 镜像里藏着的驱动和内核版本镜像不只是“装了什么系统”还决定了这台机器能不能正确识别虚拟化硬件。云上的磁盘和网卡都是虚拟设备需要对应的驱动支持。老版本内核、精简版系统、某些来源不明的第三方镜像可能缺驱动表现为磁盘识别不到、网卡起不来、或者能起来但性能极差比如没用多队列驱动全部流量挤在一个队列上。我的做法是构建自己的标准镜像从一个干净的公共镜像出发装好驱动、监控代理、日志采集、基础安全配置、常用诊断工具然后打成自定义镜像后续所有机器都从这个镜像开。好处有三个开机即可用不用每次跑一堆安装脚本版本统一排查问题时环境一致镜像本身可以版本化管理出问题能回滚到上一版。提示别在市场里随手挑一个“一键部署某环境”的镜像直接上生产。这类镜像往往内置了固定的账号密码、开放的端口、以及你不清楚的启动脚本。要用也得先拆开看一遍改掉默认凭据再谈别的。5.2 初始化脚本写什么以及失败时去哪看日志开机时通过用户数据注入一段初始化脚本是标准化部署的关键一环。我通常让它干这几件事设置主机名跟资产编号对应方便日志检索、注入 SSH 公钥并禁用密码登录、挂载并格式化数据盘注意判断盘是否已有文件系统避免误格式化、配置时间同步、写入基础监控配置、拉取配置管理工具的引导脚本。初始化脚本最大的坑是静默失败。脚本只在实例首次启动时执行一次如果中间某步出错机器照样开起来你以为一切正常实际上数据盘没挂、监控没装。所以脚本第一行就该开日志落盘把输出重定向到固定路径出问题时直接去看那个文件。另外脚本里每一步都要有失败退出别让错误被吞掉继续往下跑。写脚本的时候顺手加一句“完成标记”开机后检查这个标记存不存在比逐条核对省事得多。5.3 安全组的第一条规则决定后面所有事安全组是实例级别的虚拟防火墙默认策略通常是拒绝所有入方向。这意味着机器开出来之后除了平台自带的一些基础连通性外面什么都进不来。第一次配的人经常犯两个极端要么忘了放行连不上机器还以为网络坏了要么图省事直接全放通把管理端口暴露在公网。合理的顺序是这样先只放行管理端口且源地址限定为你自己的固定出口 IP 段不要用任意来源。没有固定 IP 的话用跳板机或者会话管理通道别直接开公网。再按业务需要逐条放行每条规则都写清楚用途备注端口范围精确到单个端口不要用大段区间图省事。出方向默认放通但如果业务明确只需要访问特定目标收窄出方向能挡住不少意外外连。分层管理把“管理入口”“对外服务”“内部服务间通信”拆成不同的安全组按机器角色绑定。这样改一条规则影响面可控而不是所有机器共用一个大而全的组。安全组规则是有数量上限的堆到几百条之后维护成本会爆炸。定期清理不再使用的规则比不断加规则更重要。6. 计费与生命周期钱是怎么在你不注意时流走的6.1 关机不等于不收费这条是新手最常见的认知偏差。按量付费的实例关机之后计算资源vCPU 和内存的费用照收只有部分平台提供“节省停机模式”开启后关机才免计算费但有条件不支持本地盘、公网 IP 可能被释放、再次开机时如果库存不足可能起不来。所以“晚上关机省钱”这个策略只在开了节省停机模式的前提下成立而且只适合开发测试环境。生产环境本来就要 7×24这条不用考虑。云盘是另一回事不管机器开不开机云盘都在收费因为数据还在。快照也收费按实际占用容量算。6.2 快照不是备份这两件事得分开做快照是块存储层面的增量备份它保证的是“这块盘在某个时刻的字节状态”。问题在于如果快照时刻数据库正在写、页缓存没落盘、事务处于中间状态那么回滚出来的数据文件在逻辑上可能是不一致的数据库起不来或者需要长时间崩溃恢复。正确做法是两条腿走路快照负责整机快速回滚系统坏了、误删文件、配置改崩了几秒钟回到昨天逻辑备份负责数据可靠性数据库自带的导出工具或者物理备份工具保证事务一致性。只有快照没有逻辑备份遇到数据损坏类问题时是救不回来的只有逻辑备份没有快照恢复一台整机要花上几小时。快照策略本身也要设计多久做一次、保留多少份、保留几天、是否跨可用区存储。全量快照策略定得太激进存储费用会悄悄涨上去而且快照数量有配额上限删旧的不及时会导致新快照创建失败——这个失败通常只发一封邮件通知很容易漏看。6.3 抢占式实例便宜但要接受被随时收走有一类实例价格极低代价是平台在资源紧张时可以回收它回收前通常只给很短的通知时间几十秒到两分钟级别。这类实例适合无状态、可中断、能重跑的任务批处理计算、视频转码的分片任务、离线数据清洗、CI 的临时构建节点。不适合的场景同样明确数据库、有状态的中间件、长连接服务、任何“中断了要人工介入”的东西。用它的正确姿势是在应用层做好中断处理——监听回收通知收到后主动把任务标记为未完成、保存检查点、优雅退出让调度系统把任务重新派到别的机器上。没有这套机制就用抢占式实例等于给自己埋雷。7. 一份开机前的检查清单和我踩过的几个坑把上面这些收敛成一张清单每次开机器之前过一遍能省掉后面 80% 的返工检查项具体动作常见错误规格族确认负载类型避开突发型跑常驻服务只看价格选最便宜的配比用高峰 P95 数据定 vCPU:内存拿凌晨监控数据做决策系统盘至少 100G别用默认值40G 盘跑满导致服务异常数据盘按 IOPS 需求反算容量不够就多盘条带用系统盘扛数据库内网能力核对带宽和收发包上限集群节点选了小规格公网带宽按流量/固定带宽算一遍再定拍脑袋选 5M可用区主业务集中预留扩容方案扩容时发现缺货镜像用自定义标准镜像含驱动与代理随手选第三方镜像初始化脚本落日志、失败退出、完成标记静默失败无人察觉安全组管理端口限源 IP规则带备注3389/22 开全网计费确认关机策略、快照保留期以为关机就不收钱配额提前确认 vCPU、EIP、快照配额扩容时被配额卡住说几个我印象最深的坑。第一个是系统盘默认 40G装了个容器运行时加几个镜像再加上日志没做轮转两周后盘满整个节点上的容器全挂了监控报的是一堆看不懂的运行时错误。后来统一改成系统盘 100G并且把所有容器日志目录单独挂到数据盘上问题再没出现过。第二个是快照策略定成每小时一次保留 30 天一个月后账单里存储费用翻了一倍多还触发了快照数量配额上限导致新快照创建失败——这个失败只有邮件通知没人看等于有一周时间的快照其实是不存在的。第三个是跨可用区部署了一套集群图的是高可用结果应用层的心跳超时设得比跨区延迟还短节点之间不停互相判定对方失联日志里全是重连记录查了两天才定位到是网络延迟和超时参数不匹配。最后分享一个我觉得最值钱的习惯每开一批机器就把这次的配置决策和理由写进一份文档哪怕只有五行字。三个月后你要么扩容要么迁移那时候你不会记得当初为什么选了这个规格、为什么系统盘给 200G、为什么这个可用区。写下来是在给未来的自己省时间。我现在的做法是在资产表里加一列“选型备注”简单写一句“内存型因为缓存常驻 28G压测高峰 CPU 35%”回头看的时候一目了然也方便别人接手。