云服务器和物理机差价30%：为什么我建议小公司别急着上云

过去七年，我帮三家创业公司做过基础设施选型。第一家在AWS上每月烧掉4.6万，业务峰值只有500 QPS；第二家因为直播弹幕功能临时扩容，AWS账单当月飙到9.3万，最后发现90%的流量来自两个测试节点在循环请求。这些真实事故让我对云厂商的宣传语越来越警惕：他们说“弹性”能省钱，但没告诉你弹性只对波动超过5倍的流量有意义；他们说“免运维”，但没告诉你运维成本只是从硬件工程师转移给了云费用审核员。

去年我对比了两家同等规模的公司——A公司用阿里云，B公司用托管机房的物理机。A公司配置是16核32G跑业务，8核16G跑数据库，预付一年加按量混合，月均账单1.87万；B公司买了三台Dell R750，一台R740，加一台备份机，分摊到36个月，月均硬件成本7300元，加上机房带宽托管费3000元，月总成本1.03万。差别不是30%，而是45%。但这只是账面上的。B公司第四个月遇到硬盘故障，托管的机房响应花了6小时才到现场，更换RAID盘后重建数据又用了4小时，那天的交易损失加上客户赔偿，单次事故成本接近2.8万——足够覆盖A公司半年的差价。

所以单纯比价格是没有意义的，真正的分界线是业务阶段和服务器的利用率。我用一个笨办法测过：在企业内部署一个Netdata监控，持续记录三周CPU和内存的平均使用率。小公司最常见的形态是峰值1小时内CPU冲到70%，其余23小时在8%~15%徘徊。这种形态在物理机上就是浪费——你为那1小时买了三台机器，剩下23小时都在空转。但云上按量付费同样不划算，因为云厂商的突发实例CPU是共享物理核，你测出的70%可能包含邻居的噪音，延迟毛刺能从1ms涨到120ms。我做过压测：同样一台8核16G的腾讯云标准型SA2和一台同配置的二手浪潮物理机，跑同样一个开源的向量检索服务，物理机的P99延迟是稳定的22ms，云服务器在晚高峰能飙到89ms。

这让我形成一个独立观点：小公司最应该采用的是“半云半物理”的混合策略——把数据库这种对延迟和IO敏感的核心服务放在物理机或独享宿主的云服务器上，把前端接入层和偶尔跑批处理的任务放在云上。具体做法是：用一台物理机跑PostgreSQL和Redis，配置写多份WAL同步到云上的冷备实例；用云上的弹性伸缩组接收HTTP流量，处理完的数据通过内网VPN写入物理机。这样即使云上的应用被流量打爆，物理机上的数据还在，恢复时间目标是15分钟而不是一夜。我按这个架构帮助一家月营收12万的SaaS公司重做预算，月成本从3.1万降到1.7万，并且把备份故障演练从季度一次改成每周一次，代价只是多花两台物理机的3000元存储租费。

最后一个要点是不要相信任何人的迁移承诺，包括我自己的。云厂商的迁移工具总是强调停机时间短，但真正卡住的是数据一致性验证。我们当时把一个MySQL 5.7的库从自建物理机迁到云数据库RDS，用官方DTS做全量加增量，跑了16小时，最后校验发现因为源库有18个未提交的XA事务，DTS把这些事务同步到了目标库，导致线上出现数据重复。后来我把切换窗口拉长到三天：第一天做全量迁移，第二天持续校验binlog位点和计数器，第三天凌晨切换写流量，同时保留物理机上的最终一致性回退脚本。整个过程比云厂商承诺的慢了6倍，但出错率降到了零。希望大家记住，云只是工具，不是宗教，真正决定你系统稳定的不是选哪家厂商，而是你对流量曲线和数据一致性的理解深度。