把业务部署到阿里云华东 ECS 之后,西南/西北用户陆续反馈"接口偶尔卡 1-2 秒"。但 ECS 监控、SLB 监控、应用日志全部正常,RT 平均值看着也没问题。
这种"看起来没事但用户体验在悄悄崩塌"的延迟抖动,是云上业务最难排查的一类问题。本文记录一次完整的跨地域延迟根因定位过程,以及最后沉淀出来的可复用排查清单。
背景:监控全绿,用户却在抱怨
我们一个 SaaS 业务,早期部署在阿里云华东 1(杭州),用户主要在长三角和珠三角,运行得挺好。后来产品扩张,西南和西北区域陆续接进来一批客户。
接入两周后,客服那边开始零星收到反馈:
"你们后台偶尔会卡一下,操作不连续,影响录单效率。"
我们第一反应是查应用层:
- ECS CPU / 内存 / 网络流量监控:全绿
- SLB 七层监控,后端 RT 平均 80ms,P99 180ms:正常
- 业务应用 trace,慢请求 < 1%:正常
- 数据库 RDS 慢查询日志:没异常
按传统思路这就是"用户网络不好"的故事——但用户分布在西南西北多个城市、多家运营商,不可能集体网络都坏了。
直到我们打开了云监控里"全国拨测"那个之前没怎么看的功能,问题才浮出来:特定时段从成都、西安、兰州等节点访问我们 SLB 的延迟,会从平均 60ms 飙到 1500ms+,然后几分钟内恢复。
而且这个抖动只针对部分跨地域路径,长三角内部访问完全不受影响——所以 ECS 端的监控才一直是绿的。
排查思路:云上跨地域问题的特殊性
云上跨地域延迟问题跟传统机房有几个本质区别,排查时要注意:
1. 你能看到的延迟 = 用户客户端 ↔ 入口接入点 + 阿里云内部骨干 + ECS 处理
后两段(阿里云骨干 + ECS 处理)是云厂商的"黑盒",有自己的 SLA 和监控,但你看不到细节。
第一段才是绝大多数跨地域抖动的根因——用户从他所在的运营商,经过若干个中间节点,最终到达阿里云华东接入点的这一路。
2. 阿里云入口节点不止一个
一个 SLB 公网 IP 背后,实际上是 BGP Anycast——不同地区的用户访问同一个 IP,会被路由到不同的实际接入点。你看到的"我从北京 ping 通 SLB 延迟 30ms"和"客户从兰州 ping 通延迟 80ms",可能都是真的,但走的是完全不同的物理链路。
3. 业务时段抖动 vs 全天抖动,根因完全不同
业务时段抖动(比如每天 9-11 点 / 19-22 点变慢)→ 几乎都是中间链路拥塞;
全天抖动 → 通常是单个跳变路由器问题 / 你 SLB 后端连接配置问题。
我们这次属于第一类——错峰时间(凌晨 2 点)用户报障基本没有,符合"链路拥塞"的画像。
第一步:多节点 ICMP 看延迟分布
第一件事是从全国不同节点同时 ping 我们的 SLB 公网 IP,看延迟和丢包的分布。
阿里云云监控的"站点监控"可以做这件事,但需要预先配置且要等数据采集。我们当时用了一个更快的办法——直接用在线多节点测试工具,几秒钟就能拿到全国 25+ 节点的 ping 结果。
SLB 公网 IP: 47.xx.xx.xx
节点 运营商 延迟 丢包率
北京 电信 28ms 0%
北京 联通 32ms 0%
上海 电信 6ms 0%
广州 电信 29ms 0%
广州 联通 35ms 0%
成都 电信 245ms 12% ← 异常
成都 联通 180ms 0%
重庆 电信 218ms 8% ← 异常
西安 电信 155ms 2%
兰州 电信 298ms 20% ← 严重异常
昆明 电信 188ms 5%
北京 移动 45ms 0%
上海 移动 18ms 0%
......
模式很清晰:电信用户在西南西北抖动严重,联通和移动正常。这个分布缩小了排查范围——问题在电信骨干网的西南/西北出口到阿里云华东杭州接入点之间。
如果你也遇到类似场景,这种"全国多节点同时 ping 一个 IP 看延迟分布"是云上跨地域问题排查的第一手段。除了阿里云自家的站点监控,在线工具如 BiuPing 多节点 Ping 能直接出结果且支持持续测试,适合快速定位。
第二步:路由追踪锁定具体跳
定位到电信跨地域链路有问题之后,下一步是找到具体哪一跳异常。
让客户端在异常时段(比如下午 3 点抖动复现时)从他们的兰州节点跑 mtr:
$ mtr -n -c 100 -r 47.xx.xx.xx
输出关键信息(脱敏):
HOST: client-lz Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 100 0.5 0.5 0.4 1.1 0.1
2.|-- 10.32.x.x 0.0% 100 3.2 3.4 2.9 8.1 0.6
3.|-- 218.x.x.x (兰州电信) 0.0% 100 8.7 9.1 8.2 15.4 1.0
4.|-- 202.x.x.x (西安电信) 0.0% 100 18.3 18.8 17.9 24.6 0.8
5.|-- 219.x.x.x (郑州电信) 0.0% 100 45.2 46.1 44.8 52.1 1.2
6.|-- 202.x.x.x (上海骨干网) 42.0% 100 185.5 245.2 152.9 458.3 72.4 ← 罪魁
7.|-- 203.x.x.x (上海骨干网) 45.0% 100 192.8 251.1 158.2 467.7 79.1
8.|-- 116.x.x.x (阿里云入口) 44.0% 100 198.2 252.0 162.1 478.4 82.2
9.|-- 47.x.x.x (SLB) 43.0% 100 201.6 249.5 160.8 475.2 81.6
读这个 mtr 几个要点:
第 6 跳是问题起点:从第 6 跳开始,丢包率从 0% 跳到 42%+,延迟从 45ms 跳到 245ms。一旦丢包从某一跳开始连续传染到所有后续跳,这就是真问题点(单跳高丢包但后续恢复 0%,只是路由器对 ICMP 限速,可以忽略)。
第 6 跳是电信上海骨干:对应电信 ChinaNet 在上海的核心节点。结合现象——"电信用户跨地域到阿里云华东延迟抖动"——基本可以判定是电信上海骨干网在业务高峰期出口拥塞。
第 7、8、9 跳延迟都被传染:这进一步佐证拥塞发生在第 6 跳之前进入第 6 跳的那段路径上,后面的跳都是无辜的。
到这一步,根因基本定位:电信跨省骨干网在业务高峰期出口带宽不足,导致跨地域 TCP 长链接出现大量重传,在用户端表现为接口偶发性卡顿。
第三步:验证根因 vs 找解决方案
定位到根因之后,有几条解法路径:
方案 A:换阿里云接入区(根治但工作量大)
最彻底的方案是给西南西北区域用户单独部署一份服务到阿里云西南 1(成都)节点,通过 GTM(全局流量管理)按地域调度。优点是延迟回到 30ms 以内,缺点是要搞双活/多活,数据同步、缓存同步全要重新设计。
方案 B:套阿里云全球加速 GA(立刻见效)
阿里云提供"全球加速"产品,本质是把用户先接到最近的阿里云接入点(比如成都),再走阿里云骨干网到达华东 SLB。绕开了电信骨干那一段拥塞链路。
我们最后选的就是这个方案——成本约几百块/月,延迟稳定到 60-80ms,丢包消失。
方案 C:CDN 接入静态请求(只能解决一部分)
如果你的接口是静态资源 + 少量动态接口,把静态部分挂 CDN 就能缓解。但我们这是 B 端 SaaS,接口动态居多,CDN 帮助有限。
方案 D:改用专线
预算足的话,可以让客户端直接走云专线接进阿里云。但 SaaS 业务用户太多,这条不适用。
复盘:云上业务跨地域排查清单
这次踩完坑之后,我们沉淀了一份云上跨地域延迟排查清单,后面遇到类似问题直接套:
Step 1 - 时间维度
抖动是全天还是特定时段?
- 全天 → 大概率是固定路由问题或后端配置问题
- 特定时段(业务高峰) → 大概率是中间链路拥塞
Step 2 - 空间维度
抖动是全国都有还是特定地区?(用多节点 ping 工具,5 分钟内能验证)
- 全国都有 → 阿里云接入点或后端 ECS 问题
- 特定地区 → 用户到接入点的链路问题
Step 3 - 协议维度
ICMP / TCP / HTTP 哪一层有问题?
- 同地区 ping 不通但 tcping 通 → 用户运营商屏蔽 ICMP,业务正常
- ping 通但 tcping 偶发不通 → 中间链路对 TCP 流量过滤或拥塞
- ping 和 tcping 都正常但 HTTP 慢 → 应用层问题或 SLB 配置问题
阿里云上常用的 TCPing 在线工具 适合验证 SLB 监听端口的连通性是否稳定,特别是 SLB 后端配置改动后做回归测试很方便。
Step 4 - 路径维度
mtr 锁定具体异常跳:
- 中间跳异常 → 联系运营商或换阿里云加速产品
- 阿里云入口跳异常 → 提工单,云厂商内部骨干问题
- ECS 内网跳异常 → 检查 VPC / 安全组 / NetworkACL
Step 5 - 端到端验证
修复方案上线后用同一套测试工具复测,确认全国节点延迟和丢包都恢复。
几个云上排查的反常识结论
最后总结几条容易被忽略的经验:
云监控不是万能的。云厂商提供的监控是"从云内部往外看",看不到用户客户端到入口的最后一公里。你必须有"从用户端往云看"的监控,才能发现跨地域抖动。这就是为什么我们后来给重要业务都加了多地区拨测。
SLB 公网 IP 的 ping 延迟不代表用户感受。同一个 SLB 公网 IP 不同地区用户访问的物理路径完全不同,你从办公室 ping 看着正常,可能某个城市用户那里就是拉胯的。别再用"我这边 ping 通了"作为故障关闭的理由。
业务时段抖动几乎都是链路问题。如果你抖动严格按业务高峰出现,根因 95% 在中间链路拥塞,不要在 ECS / RDS / 应用代码里反复折腾。直接上多节点测试 + mtr 看链路。
全球加速 / 高速通道这类付费产品是值得买的。很多团队为了省每月几百块加速费用,搭了一堆复杂的多 region 双活方案,运维成本高出几倍。先用钱解决,再考虑架构。
云上业务跟传统机房有个本质差异:你跑的代码在云厂商的数据中心,但用户体验取决于用户网络到云入口这段不可控的路径。这段路径必须主动监控、主动诊断,不然出问题永远查不到根因。
我们团队现在的做法是:重要服务每 5 分钟一次全国多节点拨测,基线数据存 6 个月。出问题时用 BiuPing 的多节点 ping/tcping/traceroute 即时复测做交叉验证——这个工具支持全国 25+ 节点同时测,比手动跑 mtr 快得多,特别适合排查云上跨地域抖动。
工具是辅助,核心还是这套从时间→空间→协议→路径→端到端的排查方法论。希望对在阿里云上做业务的同行有帮助。
