一个内部工单系统从物理机迁到虚拟服务器负责的同事按以前那台机器差不多的思路提了 4 核 8G 的配置存储随手选了 100G 通用盘网络直接用默认带宽。上线头一周风平浪静第二周开始出问题早高峰 CPU 跑到 95%磁盘写入延迟从 2ms 涨到 40ms日志里时不时冒出内存溢出。排查下来没有一行代码是错的问题全在规格规划上——核数不够扛并发内存没给页缓存和堆外留余量存储的 IOPS 上限只有几百网络带宽在批量导出时被打满。这类事故我见过太多次虚拟服务器规划这件事难的不是点几下鼠标开一台机器而是把业务需求翻译成 CPU、内存、存储、网络四个维度的具体数字并且给每个数字找到依据。下面这套方法是我在多个项目里反复校准过的从估算公式到实测手段到上线后的调参阈值都有适合刚接手基础设施工作的开发者也适合需要自己开机器做压测的后端同学。1. 先算业务账虚拟服务器规划真正的起点在哪1.1 规格申请单上最该填的不是核数而是业务画像很多人拿到开一台虚拟服务器的任务第一反应是打开配置页面看套餐。这个顺序反了。正确的顺序是先写清楚这台机器要干什么再倒推规格。我习惯在工作笔记里先列三张表第一张是负载类型表标明这台机器跑的是 Web 服务、数据库、缓存、消息队列、批处理还是文件服务一台机器只跑一种角色最好混合部署会让后面所有估算失真第二张是流量特征表写清楚日均请求量、峰值 QPS、峰值出现的时段、单次请求的平均响应体大小第三张是数据特征表写清楚每日新增数据量、数据保留周期、是随机小 IO 为主还是顺序大 IO 为主。这三张表填完很多参数自己就浮出来了。举个例子一个日均 20 万次请求的接口服务平均响应体 30KB那每天的出网流量大约是 6GB峰值时段如果集中在两小时内峰值带宽需求就能直接算。反过来如果只有我要一台服务器这句话任何配置都是拍脑袋。我见过最典型的错误是把开发和测试环境的规格直接搬到生产。开发环境一天几百个请求4 核 4G 绰绰有余生产环境峰值几千 QPS同样的配置必然崩。环境之间的负载差异往往是数量级的不是百分之几十。1.2 基线数据从哪来三种可用的取数方式规划要有数据支撑但新项目上线前哪来的数据实践中我常用三种取数方式按可靠性从高到低排列。第一种是历史系统实测。如果是从旧系统迁移直接抓旧机器的监控曲线最有说服力。至少要取连续 14 天的数据覆盖工作日和周末重点看 P95 和 P99 而不是平均值。平均值这个东西特别会骗人一台机器平均 CPU 20%听起来很闲但仔细看曲线会发现每天有两个小时稳定跑到 90%那这两个小时就是你的真实瓶颈。第二种是本地压测。在开发机上用压测工具跑出单请求的 CPU 耗时和内存增量再乘以预估 QPS。这种方法精度一般因为开发机的性能和生产虚拟机的性能不可比但用来判断数量级够用。第三种是同类系统类比。找公司内部业务量级相近的系统看它的规格和实际负载率。这种方法最粗糙但比完全拍脑袋强得多。用类比法的时候记得打个折扣因为每个系统的实现质量差异很大一个写得好的服务和一个 N1 查询满天飞的服务同样的 QPS 下资源消耗能差三倍。1.3 峰值系数与冗余系数把够用翻译成留有余量估算出基础资源量之后必须乘两个系数。峰值系数解决的是平均到峰值的放大问题冗余系数解决的是故障时单点扛全量的问题。峰值系数看业务形态。内部管理系统通常 2 到 3 倍面向公众的电商类业务在大促期间能到 8 到 10 倍定时任务型负载可能是 20 倍以上的瞬时尖峰。冗余系数则跟部署架构有关如果是三节点集群单节点故障时另外两台各承担 1.5 倍负载冗余系数取 1.5 就够如果是双节点故障时单台要扛 2 倍冗余系数必须到 2单机部署没有任何冗余可言系数只能靠加大本身配置来兜底。这两个系数不是拍出来的是架构决定的。我通常会在规划文档里明确写出本规格按 N1 冗余设计单节点故障时 CPU 峰值预计达到 75%把假设摆到台面上后面出问题也容易定位是假设错了还是实现错了。2. CPU 规划的实质vCPU 数字背后的算力折扣2.1 物理核、超线程与 vCPU 的换算关系虚拟服务器上看到的核数是 vCPU它和物理核不是一对一。主流平台的换算逻辑是一颗开启超线程的物理 CPU 核暴露为 2 个 vCPU。也就是说你买到 8 vCPU底层可能只占用了 4 个物理核的超线程资源。这个区别在计算密集型场景下影响很大。超线程的原理是让两个线程共享一个物理核的执行单元当一个线程在等内存时另一个线程可以填进来。对于访存密集、分支预测失败多的负载超线程能带来 20% 到 30% 的吞吐提升但对于纯浮点运算、编译、视频转码这类把执行单元吃满的负载两个超线程抢同一套执行单元实际算力可能只有单线程的 1.2 倍左右。所以估算 CPU 时我心里有个换算表Web 服务、API 网关这类负载vCPU 基本可以当物理核用计算密集型负载我会把 vCPU 数除以 1.6 到 1.8 再评估实际算力。这不是精确科学但能避免买了 16 核还是跑不动的困惑。负载类型vCPU 与物理核的等效折算说明Web/API 服务1 : 0.9 左右大量等待 IO超线程收益明显数据库1 : 0.8 左右混合负载缓存命中时偏计算编译/转码1 : 0.6 左右执行单元饱和超线程收益有限加密计算1 : 0.55 左右纯计算几乎无等待2.2 用单请求 CPU 耗时倒推核数最靠谱的核数估算方法是抓住单请求消耗多少 CPU 时间这个指标。公式很朴素所需 vCPU 数 峰值 QPS × 单请求 CPU 耗时秒× 冗余系数假设一个订单查询接口压测下来单请求平均消耗 8 毫秒 CPU 时间峰值 QPS 500冗余系数 1.5那么 500 × 0.008 × 1.5 6 核。再往上取到 8 核留出一点系统开销和突发空间。这里有个容易忽略的点单请求 CPU 耗时要用 P95 的值而不是平均值。因为 CPU 是全核并行处理的理论上 500 QPS 均匀分布时总耗时是固定的但请求不是均匀的长尾请求会拉长排队。用 P95 的耗时算出的是保证 95% 请求不排队的核数比平均值更贴近真实体验。获取单请求 CPU 耗时的方法可以看应用层的性能剖析数据也可以用压测时观察虚拟机的 CPU 使用率反推压测 100 QPS 时 CPU 使用率涨了 40%单核 100% 计那么单请求大约消耗 4 毫秒这个反推方法粗糙但快捷。2.3 超分比便宜背后的争抢代价虚拟化平台普遍支持 CPU 超分也就是把物理核卖给多个租户超分比从 1:1 到 1:8 都有可能。共享型实例便宜就是因为超分比高。这意味着当邻居机器忙起来的时候你的 vCPU 可能拿不到完整的时间片表现出来的症状是CPU 使用率显示 60%但请求就是慢。判断一台机器有没有被超分影响看两个指标CPU 就绪等待时间steal time和 CPU 使用率与吞吐的比值。steal time 在 Linux 下用 top 命令能看到在 %Cpu 那一行里的 st 列持续超过 3% 就说明你的 vCPU 在等物理 CPU。另一个信号是同样的吞吐量CPU 使用率莫名涨了 20%而代码没改。我的建议很直接数据库、缓存、实时计算这类对延迟敏感的负载一定选独享型或超分比 1:1 到 1:2 的规格普通的 Web 前端、离线任务用共享型完全没问题。别为了省那点成本把 MySQL 放在超分比 1:8 的机器上后面排队排到怀疑人生。2.4 一个反直觉的实测核数翻倍吞吐不涨我在一个模拟项目里做过对比同一个 Java 服务把 vCPU 从 4 核加到 8 核压测峰值 QPS 只从 3200 涨到 3600涨幅 12%。原因是通过线程池最大值配的是 200而单请求里有大量串行等待真正的瓶颈在数据库连接池只有 20 个连接数据库端每次查询 15 毫秒20 个连接的理论上限就是 1300 QPS 左右服务端再加核也只是多开几个线程一起等。这个案例说明CPU 规划不能脱离整条链路。规划之前先找瓶颈在哪一段——如果瓶颈在下游存储或数据库加 CPU 是纯浪费钱。判断方法很简单压测时同时看应用服务器的 CPU 使用率和数据库的 CPU、连接数、慢查询数量哪一段先饱和瓶颈就在哪一段。3. 内存规划操作系统和运行时悄悄吃掉的那部分3.1 三层内存占用系统、运行时、业务很多人算内存只算业务数据比如我的缓存有 2GB那 4G 机器够了。实际情况是内存被三层结构瓜分最底层是操作系统自身和内核页缓存中间层是运行时环境JVM、Python 解释器、Node 运行时的固定开销最上层才是业务数据。操作系统这层Linux 最小也要留 512MB 到 1GB 给内核、基础进程和页缓存。页缓存看着是被占用其实是可回收的但页缓存太小会导致磁盘读频繁穿透性能明显下降。我给数据库和文件服务类机器留的页缓存空间通常是总内存的 15% 到 25%。运行时这层JVM 的固定开销包括Metaspace默认无上限实际常见 128MB 到 256MB、代码缓存几十 MB、线程栈每线程默认 1MB200 个线程就是 200MB、直接内存Netty、NIO 用的堆外缓冲常见 256MB 到 1GB、GC 自身需要的额外空间。这些加起来轻松占掉 1GB 以上。Python 和 Node 相对轻但也有几百 MB 的常驻。3.2 JVM 堆大小到底该给多少Java 服务的内存规划有个经验区间堆内存占总内存的 50% 到 65%不要超过 70%。原因在于堆外还有一大堆东西要放而且堆内的对象在 GC 时需要额外的空间做复制和整理。举个具体例子一台 8GB 内存的机器跑 Spring Boot 服务。我通常这么分配堆 4.5GB-Xms4g -Xmx4g固定大小避免动态扩缩带来的抖动Metaspace 上限 512MB直接内存上限 1GB-XX:MaxDirectMemorySize1g线程栈按 300 线程 × 1MB 算 300MB剩下的 1.7GB 留给操作系统、页缓存和碎片余量。这个配比在多数业务下都跑得比较稳。堆给太小会频繁 GC给太大会让单次 Full GC 的停顿时间变长。一个粗略的判断堆在 8GB 以内时G1 的停顿通常能控制在 200ms 以内堆超过 16GB就需要更仔细地调 Region 大小和暂停目标。如果不知道自己的服务堆该多大可以先按常驻活跃对象大小的 2 到 3 倍给再通过 GC 日志里的存活对象曲线校正。3.3 缓存类服务的内存预留fork 那一刻的隐形炸弹跑 Redis 这类缓存服务时只按数据量算内存是危险的。Redis 执行持久化时会 fork 出子进程虽然用的是写时复制但只要主进程在持久化期间有写入被修改的内存页就会被复制一份最坏情况下内存占用接近翻倍。我的做法是把maxmemory设在物理内存的 60% 到 70%留足 30% 以上给 fork。一台 16GB 的机器maxmemory给 10GB 左右。如果数据量确实超过这个数正确做法是分片而不是硬塞。同时把vm.overcommit_memory设为 1避免 fork 时因为内存分配检查失败而报错。另一个常被忽略的是日志和临时文件。应用频繁打印日志、生成临时文件、做文件上传落盘这些都会消耗页缓存和磁盘空间间接影响内存可用量。给这类机器规划内存时我会额外留出 1GB 到 2GB 的缓冲。3.4 swap 开不开分场景给结论这个问题争论了很多年。我的结论是按角色分数据库和缓存坚决不开或者只开很小的 swap 并把vm.swappiness调到 1普通 Web 应用可以开 2GB 到 4GB 的 swap 作为防崩溃的最后一道保险。不开 swap 的理由是性能一旦热点数据被换出到磁盘延迟从微秒级变成毫秒级数据库的查询响应会直接崩掉。但完全不开的代价是内存一旦短时超限内核的 OOM Killer 会直接杀掉进程服务硬重启。对 Web 应用来说被换出一点内存只会慢一些被杀掉却是直接不可用所以留一点 swap 更划算。配置上vm.swappiness1意味着内核只在内存极度紧张时才使用 swap平时基本不碰。这个值设在 10 以下既能保留兜底能力又不会让系统主动把热数据挪到磁盘。4. 存储选型容量只是入场券IOPS 和吞吐才是天花板4.1 容量估算要算三笔账容量规划最常见的错误是按当前数据量 × 2给结果三个月就满了。完整的容量账要算三笔。第一笔是数据本身的增长。取当前数据量按历史增长率外推。如果系统还没上线就按业务预估每天新增多少条记录、每条记录多大、索引占多少通常数据量的 30% 到 50%、保留多久。一个有索引的关系型数据库实际占用往往是裸数据量的 2 到 3 倍。第二笔是日志和临时文件。应用日志按每天 1GB 到 5GB 估访问日志更大加上 GC 日志、慢查询日志、临时导出文件我通常预留总容量的 15% 到 20%。这些文件如果是只写不删几个月就能吃掉几十 GB。第三笔是快照和备份。如果在这台机器上做本地快照快照本身也占空间备份文件如果落在本地盘更要算进去。通常预留 20% 左右。算完三笔再加 20% 的安全水位就是初始容量。真实环境中磁盘使用率超过 80% 就应该开始考虑扩容超过 90% 很多系统会出问题——数据库写入失败、日志轮转失败、临时文件创建失败连锁反应很快。4.2 IOPS、吞吐、延迟三个指标对应三种负载存储性能有三个维度不同的负载卡在不同的维度上。随机小 IO 看 IOPS。数据库的索引查找、元数据操作、小文件的读写每次都是 4KB 到 16KB 的随机读写瓶颈在每秒能完成多少次 IO。一块普通云盘的 IOPS 可能在 3000 到 5000高性能盘能到 2 万以上。如果跑 MySQL 且每天有几百万次查询3000 IOPS 是肯定不够的。顺序大 IO 看吞吐。日志写入、文件上传下载、备份、大数据处理都是大块顺序读写瓶颈在 MB/s。这时候 IOPS 再高也没用关键看带宽。延迟看单次操作耗时。这个指标对数据库最敏感尤其是写操作因为写要等落盘确认。普通网络盘的写延迟在 1ms 到 5ms本地 SSD 能到 0.1ms。延迟高的盘即使 IOPS 够事务型负载的响应时间也会被拖长。下面这张表是我做选型时的对照参考数值是常见区间的粗略量级存储类型典型 IOPS典型吞吐写延迟适用场景普通网络盘3000~5000100~150 MB/s2~5 ms日志、文件、低频访问高性能网络盘2万~5万300~500 MB/s1~2 ms中小型数据库、缓存持久化本地 SSD5万~10万500 MB/s~1 GB/s0.1~0.3 ms高并发数据库、搜索索引独立数据盘阵列10万以上1 GB/s 以上0.5~1 ms大型数据库、分析型负载本地盘的性能优势明显但有个致命问题它绑定在单台物理机上机器故障数据就没了而且不能跨机迁移。所以本地盘只适合做主从架构里可以重建的副本节点或者临时计算用的缓存盘。4.3 用 fio 摸清一块盘的真实底线不看规格书直接测。规格书上的 IOPS 往往是理想条件下的峰值实际表现受块大小、队列深度、读写比例影响很大。我用 fio 做两轮测试一轮测随机读写一轮测顺序读写。# 随机读写混合测试模拟数据库负载 fio --namerandrw --ioenginelibaio --direct1 --rwrandrw \ --bs4k --iodepth32 --numjobs4 --size2G --runtime60 \ --group_reporting # 顺序写测试模拟日志和大文件写入 fio --nameseqwrite --ioenginelibaio --direct1 --rwwrite \ --bs1M --iodepth16 --numjobs1 --size4G --runtime60 \ --group_reporting看结果里的iops、bw和lat三个值。重点看lat的 p99 而不是平均值——平均值好看但 p99 很差说明有偶发的长尾延迟对数据库来说这是灾难。我遇到过一次某块盘的 IOPS 跑到了标称值的 90%但 p99 延迟是平均值的 30 倍原因是同一批物理盘上的其他租户在做大规模写入这种邻居噪声只能通过换盘或换可用区解决。4.4 分区与文件系统几个少走弯路的默认选择分区规划上我的习惯是至少分三个区系统盘 40GB 到 60GB只放操作系统和应用数据盘单独一块挂载到/data放数据库文件、上传文件、日志如果做容器化再加一块给容器运行时和镜像存储。分开的好处是系统盘被日志写满时不会拖垮数据扩容时也只需要动数据盘。文件系统选择上通用场景用 ext4 足够数据量特别大、目录特别多比如百万级文件用 xfs 更合适它的目录索引效率更高对象存储或大数据场景用专门的分布式文件系统。挂载参数上数据库盘的noatime一定要加避免每次读文件都更新访问时间白白多出一次写 IO。云环境的云盘还有一类细节小容量盘的性能是打折的。很多平台按容量阶梯给 IOPS100GB 的盘可能只有 1000 多 IOPS500GB 以上才给到标称上限。所以如果性能需求高宁可开大一点的盘哪怕用不满容量。5. 网络配置默认值往往是最不合适的那个5.1 带宽估算从请求大小倒推网络带宽的估算公式也很直接所需带宽Mbps 峰值 QPS × 平均响应大小MB× 8 ÷ 目标利用率假设峰值 QPS 800平均响应 80KB约 0.078MB目标利用率 70%那么 800 × 0.078 × 8 ÷ 0.7 ≈ 713 Mbps。这个数字说明 100Mbps 的公网带宽肯定不够需要至少 1Gbps 的内网带宽公网侧可能还需要配负载均衡分摊。三个易错点一是只算了出向流量没算入向文件上传类业务入向流量可能更大二是忽略了重传网络质量差的时候 TCP 重传会让实际带宽消耗涨 10% 到 20%三是忘了 CDN 和对象存储可以卸载大量静态资源流量把图片、静态文件挪到对象存储后服务器本身需要的带宽可能直接降一个数量级。公网带宽通常按峰值计费或按流量计费成本差异很大。按带宽计费的适合流量平稳的业务按流量计费适合有明显波谷的业务。这个选择要在规划阶段就定下来。5.2 内网与外网物理隔离的价值虚拟服务器一般至少两块网卡或者两个网络平面内网和公网。内网走机器之间的通信包括数据库访问、缓存访问、服务间调用公网走对用户的出入口。分开的核心价值有两个。第一是性能和成本。内网带宽通常免费且带宽大万兆甚至更高公网带宽贵且受限。把数据库、缓存、消息队列全部走内网只在入口层用公网能省下大量成本。第二是安全边界。数据库、缓存、内部管理接口只绑内网地址公网根本访问不到这是最基本的一道防线。安全组规则上我的习惯是默认拒绝所有入向然后按需放通——Web 端口只对负载均衡放通SSH 只对跳板机或办公网段放通数据库端口只对应用服务器网段放通。这个白名单模式一开始配置麻烦但能挡掉绝大多数扫描和暴力尝试。5.3 连接数与内核参数小配置引发的大问题网络性能问题里有相当一部分不是带宽不够而是连接数或内核参数配置不当。TIME_WAIT 堆积是最常见的。作为服务端主动关闭连接多的场景比如短连接 API大量连接处于 TIME_WAIT 状态会占满本地端口。默认net.ipv4.ip_local_port_range是 32768 到 60999只有不到 3 万个端口高并发短连接场景很快耗尽。调整方式是扩大端口范围并允许复用net.ipv4.ip_local_port_range 10240 65000 net.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_fin_timeout 30 net.core.somaxconn 65535 net.ipv4.tcp_max_syn_backlog 65535另一个是ulimit -n文件描述符上限。默认 1024 对现代服务来说太小每个连接占一个 fd几千并发就爆了。系统级要改/etc/security/limits.conf进程级在服务启动脚本里设置容器化环境还要注意容器的 fd 限制。MTU 的问题相对隐蔽。默认 1500如果做隧道封装或者跨可用区通信路径 MTU 可能小于 1500导致大包分片甚至丢包。表现是小请求正常大响应超时排查的时候用ping -s逐步加大包大小测试就能定位。6. 完整推演把一个业务需求变成规格清单6.1 场景设定一个日订单十万的内部交易系统拿一个我经手过的模拟项目做完整推演。业务是内部交易系统日均 10 万笔订单其中 80% 集中在 9 点到 18 点峰值时段比如上午 10 点到 11 点占全天流量的 15%也就是 1.5 万笔订单在 1 小时内完成约 4.2 笔每秒。每笔订单涉及 6 到 8 次接口调用查商品、查库存、算价格、下单、写日志等所以峰值 QPS 约 30。每个接口平均响应体 20KB。先别急着说这点量随便一台机器就行。规划的价值不只在于算大也在于算准——算准了才能既不浪费也不冒险。6.2 CPU 与内存的逐项计算CPU 方面压测单个接口平均消耗 6 毫秒 CPU峰值 QPS 30那么 30 × 0.006 0.18 核。这个数字小得离谱说明纯从应用逻辑算完全用不到 1 核。但实际规格不能这么给因为要考虑操作系统基础开销约 0.2 核定时任务和批处理占 0.3 核日志和监控代理占 0.1 核然后按最保守的冗余系数 2 计算最终 2 到 4 核是合理的。再考虑未来业务翻三倍的预期选 4 核。内存方面JVM 应用常驻活跃对象预估 800MB按 2.5 倍给堆就是 2GB加上 Metaspace 256MB、直接内存 512MB、线程栈 200MB、系统和页缓存 1GB合计约 4GB。选 8GB 留出余量实际使用率大概在 60% 左右属于健康的范围。如果这个系统还带一个 Redis 缓存缓存数据预估 2GB那 Redis 至少要 4GB 内存按 60% 的 maxmemory 比例最好单独一台机器不要和应用混部避免互相抢内存。6.3 存储与网络的规格推导存储方面订单数据每天 10 万条每条记录加索引约 2KB每天 200MB一年约 70GB保留三年就是 210GB。加上订单日志、操作审计、临时导出文件再算上快照和 20% 安全水位初始给 500GB 比较合适。性能上订单系统的写入是随机小 IO每次下单至少 3 次写订单主表、明细、状态峰值 4 笔每秒就是 12 次写 IOPS这个负载很低普通盘完全够用。但如果这个系统还提供报表查询报表的聚合查询会产生大量随机读那就需要考虑高性能盘。网络方面峰值 QPS 30 × 20KB × 8 4.8 Mbps加 70% 利用率系数后约 7 Mbps。这个量很小但因为是对内服务走内网万兆链路毫无压力。如果还要对外提供文件下载那要另外算一个 10MB 的文件被 100 个用户同时下载就是 8Gbps这种场景必须上对象存储加 CDN不能让虚拟服务器直接扛。最终规格清单应用服务器 4 vCPU / 8GB / 系统盘 60GB 数据盘 500GB / 内网万兆缓存服务器 2 vCPU / 4GB / 系统盘 40GB。另外配一个同规格的备用节点组成双节点加负载均衡的架构。6.4 上线后第一次校准看什么、调什么上线后第一周是校准窗口期。我会盯五个指标CPU 使用率的 P95、内存可用量available而不是free、磁盘 IOPS 和 p99 延迟、网络带宽峰值、应用层的 P99 响应时间。如果 CPU 的 P95 长期在 30% 以下说明规格给大了可以考虑降配如果在 70% 到 85%属于合理区间超过 85% 且伴随响应时间上升就该扩容了。内存看available低于总内存的 15% 就要警惕尤其是它持续下降的趋势——这通常意味着有内存泄漏或缓存无上限增长。磁盘方面重点看 IOPS 是否接近规格上限的 80%以及 p99 延迟是否显著高于均值。网络看峰值带宽利用率和重传率重传率超过 1% 就要查链路质量。7. 长期运维视角扩容阈值、监控盲区与成本回收7.1 把扩容决策变成一条可执行的规则感觉该扩容了不是规则。我给每个资源维度设一个明确的阈值和观察窗口写进运维文档里CPUP95 连续 3 天超过 70%触发扩容评估连续 7 天超过 80%直接扩容。内存available连续 24 小时低于 15%或者 7 天内出现 3 次以上 OOM 记录扩容。磁盘使用率超过 75% 触发告警和清理超过 85% 扩容不留到 90%。存储性能IOPS 使用率超过 80% 或 p99 延迟超过 20ms 持续 1 小时评估升级盘型。网络峰值带宽利用率超过 70% 持续 3 天扩容带宽或加 CDN。这些阈值不是绝对的但比没有阈值强得多。关键是要有观察窗口因为单次尖峰和持续高负载是两回事前者扩容是浪费后者不扩是冒险。7.2 那些监控面板上看不见的盲区默认的监控面板通常只展示 CPU、内存、磁盘、网络四个基础指标但真正导致故障的往往是面板上看不见的东西。第一个盲区是磁盘 inode。小文件特别多的系统比如邮件队列、缓存文件、容器镜像层可能出现磁盘还有空间但写不进去的情况因为 inode 用完了。df -i能看到 inode 使用率规划时如果预计小文件数量在百万级要选择支持大 inode 数量的文件系统或者提前调整。第二个盲区是文件描述符。前面提过但要强调它在监控上的隐蔽性——CPU、内存、磁盘全部正常服务却开始报too many open files。这个指标要单独采集。第三个盲区是连接数。数据库连接池耗尽、TCP 连接数打满、TIME_WAIT 堆积这些都不会直接反映在四个基础指标上需要针对性地采集。第四个盲区是时钟和 DNS。虚拟机的时钟漂移会导致证书校验失败、分布式锁失效、日志时间错乱DNS 解析慢或失败会导致服务间调用莫名超时。这两个问题排查起来极其费时但在规划阶段配好 NTP 同步和本地 DNS 缓存就能大幅降低概率。7.3 缩容与成本回收规划的另一半规划不只是往上加。业务有波峰波谷很多机器的资源在大部分时间里是闲置的。定期做一次资源盘点把长期低负载的机器降配能省下可观的成本。我的做法是每个季度看一次资源使用报告找出连续 30 天 CPU P95 低于 25%、内存 available 高于 50% 的机器逐个确认是否需要降配。降配前要确认三件事业务是否有明确的增长预期、是否有季节性波动、冗余是否足够。有些系统平时闲着但大促时是主力这种机器降配后在大促前要升回来来回折腾的成本可能超过省下的钱。还有一种回收方式是把多台低负载的小机器合并。比如五台 2 核 4G 的机器各跑一个内部小工具CPU 都在 10% 以下合并到一台 8 核 16G 上用容器隔离既省成本又便于统一运维。但合并的前提是这些服务之间没有强隔离要求且故障域可以接受——合并之后一台机器挂了会同时影响五个服务这个风险要评估清楚。规划这件事做久了会发现最难的从来不是记住那些公式和参数而是养成先量化再决策的习惯。我早期也干过凭经验拍配置的事运气好没出问题但那种够用就好的心态在业务量涨上来之后一定会付出代价。现在每次开机器之前我都会强迫自己在文档里写下这台机器的负载画像、估算过程、假设条件和扩容阈值哪怕只有半页纸。这份记录在半年后回头看的时候价值比配置本身大得多——它能告诉你当初为什么这么选也能在出问题时快速定位是哪个假设失效了。