双机房多活是大多数团队的过度设计吗——延迟预算、专线成本与故障恢复这笔账怎么算

背景

做了 5 年网络工程，最近一年反复遇到同一个争论：核心服务到底要不要上双机房/多活。我见过两种极端——一边是「核心链路必须两地三中心，否则一次机房断网就全崩」，一边是「就一个机房加个快照备份，省下的钱够发三个月工资」。两边的声音都有道理，但都没把账算清楚。真正的分歧其实不在「要不要高可用」，而在「为哪个级别的高可用付多少钱」，而大多数团队恰恰是在这一步含糊带过的。

常见分歧 / 几种做法

1. 全上多活：核心服务双机房热备、跨机房 RTT 一般 2–5ms、专线按带宽计费（一条 10G 专线月租常落在几万到十几万量级，视运营商与线路而定），故障自动切换，RPO≈0。适合金融、支付这类「宕 1 分钟就是真金白银」的场景。
2. 单机房 + 异地容灾：主在本地机房，异地只做冷备/快照，RPO 几分钟到几小时，RTO 以小时计。省专线、省双写复杂度，但真切换时是「能恢复」而不是「无感」。
3. 分级水位：不是所有服务同一标准。按业务关键度分 P0/P1/P2，P0 双活、P1 单机房+快照、P2 甚至允许手动恢复。

我的倾向与理由

我倾向第 3 种，而且会先从「延迟预算」倒推，而不是从「要不要多活」开始。理由有三：

• 跨机房每一跳都在吃延迟预算。两地之间 RTT 2–5ms 看着不多，但一条请求链路里跨机房往返 3–4 次，P99 直接被顶上去。社区 #18 那篇连接池 P99 抖动的排查里，很多「找不到原因的抖动」，根因往往就是跨机房这一跳没算进预算。
• 多活的运维成本是指数级的，不是线性。双写一致性、脑裂、数据冲突、切换演练，每一项都要持续投入人力，这笔「隐藏成本」经常比专线本身还贵。
• 高可用的目标不是「永不宕」，而是「宕了能在业务可接受窗口内恢复」。所以应该先定 RTO/RPO，再反推架构，而不是反过来——先拍架构再找理由。

想听大家在什么场景下怎么选

• 你们定多活水位时，是按 SLO 数字、按业务关键度、还是按「领导要求」？有没有一个能复用的判断框架，能直接拿去跟业务方谈钱？
• 你们怎么把「跨机房延迟」量化进延迟预算的？有没有具体的 RTT 实测数据或压测方法可以分享？
• 单机房团队，你们是怎么在「不花双活的钱」的前提下，把 RTO 压到业务能接受的？靠的是快照、备份链路还是别的？

欢迎从网络层、应用层、DBA、SRE 各自视角来聊，越具体越好。