luckygood logo

跨境物流系统跑香港独立服务器3个回国延迟堵点实测记录

StrataServer

凌晨两点十七分,oncall电话炸了。海外仓WMS回传揽收状态超时,TMS那边分拣流水线直接卡住,300多票货扫不了码。一看监控,API网关到HK机房的RTT飙到380ms,丢包率4.7%。(别问我怎么知道的,问就是这种电话一个月能接四五回。)

后来把整套物流系统从内地机房迁到香港独立服务器,走CN2 GIA直连回国,延迟压到35ms上下,丢包0.01%。跑了8个月,双十一峰值没翻过车。这里把3个最要命的网络堵点和处理过程摊开说。

物流系统回国延迟飙高的网络堵点

跨境物流系统跟普通web站不一样。WMS要实时同步海外仓库存,TMS要推送轨迹给国内客户,OMS要拉取各平台订单——全是高频短连接+长连接混着跑,TCP重传一多,整条分拣线停摆。

堵在哪?拆开看就3个地方:

  • 163骨干网晚高峰拥塞。普通国际线路走这个,19点到23点丢包能到5%,物流轨迹直接"断流",客户刷不到更新,投诉电话打爆客服。
  • TCP窗口没调。默认window size 64KB,HK到内地虽然物理距离近,但经过的跳数多,RTT 30ms+的情况下吞吐直接被掐死。开了TCP Window Scaling把窗口拉到4MB,吞吐翻了6倍不止。
  • BGP路由不对称。去程走电信、回程绕联通,路径不一致导致中间某跳QoS策略不同,延迟波动(就是那种忽高忽低的毛刺)特别烦。做了BGP多线接入+策略路由之后,来回走同一条路,毛刺消了。

还有一个容易忽略的:物流系统API大多是HTTPS短连接,TLS握手本身就要1-2个RTT。HK到内地35ms的话,一次握手70-105ms,加上业务响应,总共150ms以内能搞定。但要是走普通国际线路200ms+的RTT,一次请求光握手就400ms,并发一上来直接雪崩。

3种部署方案跑分数据对比

当时选型拉了3个方案实测,数据是连续跑了7天、每天取晚高峰均值:

对比项内地机房+国际加速普通HK云VPSHK独立服务器CN2 GIA
回国晚高峰RTT220-380ms80-150ms(共享带宽波动大)32-42ms
丢包率(7天均值)3.2%-5.1%0.8%-2.3%0.01%-0.05%
带宽独占是(但国际出口共享)否,邻居偷带宽是,物理独享
物流API 500并发承载超时率12%超时率6%超时率0.3%
月成本量级8K-15K1.5K-3K4K-8K
适合体量纯内地业务为主日单200以下小卖家日单500+、有海外仓对接

说个反直觉的事:内地机房加"国际加速"(就是那种UDP转发隧道),对物流系统的HTTPS短连接基本没用。加速隧道对长连接流媒体有效,对高频短连接反而多一层封装开销,延迟不降反升。

物流系统选HK机房的翻车实录

说清楚什么情况别上HK独立服务器,省得花冤枉钱:

  • 纯内地业务、没有海外仓API调用的,别上。HK到内地再怎么快也多一跳,内地用户访问你后台反而比本地机房慢10-20ms,没必要。
  • 日单量200以下的小卖家,共享云主机绑个CN2线路就够用。独立服务器的独占带宽对你来说是浪费,月省下来的钱够吃好几顿。
  • 需要内地ICP备案对接某些支付接口的,HK服务器备不了案,这条路走不通,得另想办法(比如内地放个备案的API网关做转发)。

另外一嘴,选机房的时候别只看"CN2 GIA"四个字。有些小机房号称CN2 GIA,实际上是CN2 GT(普通等级)套了个GIA的壳。验证方法很简单:traceroute看回程是不是走59.43.x.x段(GIA专属AS4809),如果走的是202.97.x.x(163骨干网AS4134),那就是挂羊头卖狗肉。

说到选服务商,我们当时对比了四五家HK机房的独立服务器,最后落在StrataServer上,主要是两个原因:一是他们的CN2 GIA带宽是电信直签的,不是二道贩子转售,晚高峰不缩水;二是支持ECMP等价多路径,物流系统API网关做双活的时候,两条线路同时跑、自动分流,不用自己折腾策略路由。

排障命令放这里,HK机器上直接跑:

#!/bin/bash
# 从HK独立服务器测回国物流API网关的丢包和延迟
# 把 api.your-wms-gateway.com 换成你实际的物流API域名
mtr -r -c 100 -T -P 443 api.your-wms-gateway.com

看TCP重传率,retrans超过5%就别看了,先换线路

ss -ti | grep -A1 "your-wms-gateway" | grep retrans

确认回程是不是真CN2 GIA(看有没有59.43段)

traceroute -T -p 443 api.your-wms-gateway.com | grep "59.43"

这步要是grep没输出,说明回程走的163,不是GIA

作者简介

前某东南亚专线跨境物流SaaS公司运维组长,干了6年WMS/TMS系统的服务器运维和线路调参,经历过3个双十一峰值保障。现在在IDC圈做售前技术方案,专门给物流和跨境电商客户做HK/SG机房选型和回国线路调优。日常爱好是收集各种奇葩网络故障的mtr截图。

该动手了就别拖

物流系统每多跑一天高延迟线路,客户投诉就多攒一天,轨迹断流导致的差评是实打实影响店铺权重的。先拿mtr跑一把你现在的回国线路,丢包超过1%、RTT超过80ms,就该认真考虑迁HK独立服务器了。迁移本身不复杂,API网关层做个DNS切换+灰度放量,一个晚上能搞定。

常见问题解答

01 mtr测HK到内地物流API网关,第5跳开始丢包率突然飙到8%,怎么判断是CN2 GIA线路问题还是对端机房入口拥塞?

看丢包是从哪一跳开始的。如果59.43段(AS4809)中间跳丢包,是电信骨干拥塞;如果只有最后一跳(对端IP)丢包,大概率是对方机房入口带宽打满了,跟线路无关,找对端扩容。

02 物流WMS系统从内地迁到HK独立服务器后,内地仓库扫码枪访问后台延迟反而多了15ms,正常吗?

正常。HK到内地物理上多了一跳,35ms RTT比本地机房5ms肯定慢。解法是在内地放一层Nginx反向代理做缓存,静态资源和登录态走内地,只有库存同步API走HK,体感就没差别了。

03 TCP Window Scaling调到4MB之后,物流API的并发连接数反而下降了,ss看到大量TIME_WAIT,什么原因?

窗口拉大后单连接吞吐上去了,但TIME_WAIT回收没跟上。把net.ipv4.tcp_tw_reuse打开,再把net.ipv4.tcp_fin_timeout从60改到15,同时确认你的API网关连接池max_connections够大,别被TIME_WAIT占满了池子。

04 HK独立服务器做BGP多线接入,电信和联通两条线路的AS号不同,物流API网关怎么做故障自动切换?

用Keepalived做VRRP主备,或者直接在API网关层(比如OpenResty)配upstream health_check,5秒探测一次,连续2次超时自动摘掉故障线路。别依赖BGP收敛,那个要30秒以上,物流系统等不起。