2022 年 3 月，一个客户的 ERP 还在自己的机房，新做的应用放在云上。两边要通，业务方给的期限是两周，因为四月初有一批门店要上线。

我们先用了隧道，三天就通了。跑了半年，问题开始集中出现：早上八点半打卡和开单叠在一起，跨网访问的响应从二十毫秒抖到八十毫秒，收银端开始转圈。年底申请了专线，交付用了两个月。

这篇写两种方式各自解决什么问题，以及我们切换那晚踩的坑。

## 一、先把流量分成三类

### 1.1 交互、批量、备份

跨网流量看着是一股，实际是三股。交互类是页面查询和单据提交，特点是量小、对时延敏感。批量类是商品和库存同步，每天四十 G，跑在凌晨。备份类是数据库日志归档，一天十几 G，可以慢。

三类流量的要求完全不同。混在一条链路上，批量和备份会把交互挤掉，因为它们是长连接、大包、持续时间长。

### 1.2 时延怎么算

机房里到云上，物理距离决定了一个下限，光在光纤里走一个来回，一公里大约十微秒，加上设备转发，单程很难低于一毫秒。

隧道在公网上跑，实际时延是物理时延加上公网绕行和加解密，我们实测稳定在十八到二十五毫秒，抖动正负八毫秒。专线走固定路径，实测三毫秒，抖动不到一毫秒。这个差距对页面查询影响不大，对收银端的高频小请求影响很大。

### 1.3 谁依赖谁

梳理依赖关系时，我们画了一张图：门店终端依赖应用，应用依赖 ERP 的接口，报表依赖两边的数据。图上有四条跨网调用，其中三条是同步的。

同步调用的数量决定了这条链路的重要程度。四条里三条同步，意味着链路一断，门店就开不了单。这个结论直接影响了后面要不要做双线。

## 二、隧道：三天通，三个月开始难受

### 2.1 建起来很快

两端各一台设备，配好对端地址、预共享密钥、加密算法，半天能通。调试时间主要花在网段规划上，因为两边都有历史包袱，地址段撞了。

隧道的好处是交付快、成本低、不用等运营商。坏处是它跑在公网上，质量取决于公网，而你控制不了公网。

调试时两个地方容易卡住。一是加密算法两边不一致，日志只写"协商失败"，不写哪一项不匹配，只能逐项对比。二是两端都在 NAT 后面，需要开启穿透模式，否则协商的头一步就过不去。这两点文档里都有，但真遇到时不一定想得起来。

### 2.2 抖动来自重连

隧道断开重连的那几十秒，所有跨网请求全部失败。我们统计过，一个月平均断四次，其中三次是运营商侧线路调整，一次是我们自己的设备重启。

每次断的时间不长，二十秒到一分钟。但对收银来说是实打实的报错，店员会以为系统坏了，然后打电话。

### 2.3 MTU 和带宽上限

隧道封装要占包头，有效载荷变小。默认 MTU 一千五百的链路上，大包会被分片，分片一多，丢包率就上去了。我们把隧道接口的 MTU 调到一千四，问题明显好转。

带宽也是瓶颈。那条隧道签的是五十兆，跑批量同步时能打满，打满之后交互流量排队，页面就开始转圈。后来把批量限速到二十兆，交互才稳定下来。

限速之后批量同步的时间从两小时拉长到四小时，还在凌晨窗口里，没有影响业务。这个交换很划算：批量多花两小时没人感知，交互卡两秒店员就会打电话。

## 三、专线：两个月，一半时间在流程

### 3.1 交付周期不在施工

从提交申请到开通，用了五十八天。其中勘测和施工两周，剩下的时间在等两边机房的手续、等运营商排期、等割接窗口。

这件事没法压缩，只能提前规划。如果等到业务抱怨才申请，中间这两个月只能靠隧道扛着。

### 3.2 双线是花钱买确定性

单条专线也会断。施工挖断光缆、机房设备升级，这些事一年总会遇到一两次。所以我们签了两条，走不同路径，一条主用一条备用。

两条线的成本是单条的一点六倍，不是两倍，因为备用线带宽可以小一些。备用线只保证交互流量，批量和备份在切换期间暂停。

带宽怎么定，我们按高峰时段的一分钟均值乘三算。交互流量高峰是十二兆，乘三取四十兆，留出突发余量。按平均值定会不够，按理论峰值定会浪费，一分钟均值比较接近真实。

### 3.3 切换那晚的坑

专线开通那天，我们计划把路由从隧道切到专线。切换动作是改路由的优先级，理论上十秒完成。

结果切完五分钟，门店开始报超时。查下来是两端网段有重叠：机房有个测试网段和云上的一个网段地址一样，之前走隧道时被 NAT 挡住了，走专线之后路由直达，流量串了。那天回退了两次，后来把测试网段挪走才切成功。

## 四、路由怎么配才不乱

### 4.1 网段先规划，再谈线路

混合云的网络问题，一半出在地址规划上。两边各自扩容几年，地址段像两块拼图，看着能拼，边缘总有重叠。

我们的做法是先做一张地址分配表，两边共用，谁的网段谁负责登记。重叠的网段要么改，要么在边界做 NAT，改优先，NAT 只作为过渡。

表里记四列：网段、用途、负责团队、启用时间。启用时间这一列看着没用，实际上查历史问题全靠它，因为很多冲突是两个网段上线时间不同造成的，谁先谁后决定改哪一边。

### 4.2 主备靠度量值，不靠人

主用专线、备用隧道，切换靠路由的度量值。专线的度量值小，隧道的度量值大，专线断了，路由自动收敛到隧道。

这里有个细节：隧道要一直保持建立状态，不能等专线断了才去连。我们让隧道常连，只是不承载流量，切换时省掉了建立连接的时间。

### 4.3 配置长什么样

下面的配置是云侧的路由和链路定义，地址和密钥用变量占位，实际值从密钥管理里取。

```yaml
# hybrid-route.yaml
vpc:
  cidr: ${VPC_CIDR}
  route_table: rt-main

idc:
  cidr: ${IDC_CIDR}
  asn: 65010

links:
  - name: dx-primary
    type: direct-connect
    bandwidth_mbps: 200
    bgp:
      local_asn: 65020
      peer_asn: 65010
      advertise: ["${VPC_CIDR}"]
      receive: ["${IDC_CIDR}"]
    health_check:
      method: bgp-keepalive
      interval_s: 30
      fail_threshold: 3
    metric: 10

  - name: vpn-backup
    type: ipsec
    bandwidth_mbps: 50
    mtu: 1400
    psk_ref: "secret://net/vpn-backup"
    ike: aes256-sha256-dh14
    esp: aes256-sha256
    keepalive: true
    health_check:
      method: icmp
      target: ${IDC_GATEWAY}
      interval_s: 5
      fail_threshold: 3
    metric: 100

routes:
  - dest: "${IDC_CIDR}"
    next_hop: dx-primary
    metric: 10
  - dest: "${IDC_CIDR}"
    next_hop: vpn-backup
    metric: 100
    active_only_if: dx-primary.down

qos:
  - match: batch-sync
    link: dx-primary
    max_mbps: 120
  - match: interactive
    link: dx-primary
    min_mbps: 40
```

`active_only_if` 这个字段不是所有设备都支持，我们是自己在配置生成脚本里实现的：专线健康检查连续三次失败，才把备用路由下发。没有这个约束，两条路由同时生效会造成来回路径不一致，表现为时通时不通。

## 五、现在的边界

### 5.1 专线也不是不出事

今年三月，专线断过一次，原因是施工。备用隧道在一分半内接管，门店侧只是有几笔提交重试了一下，没有大面积报错。

这次之后，我们把切换演练改成每季度一次，主动断开主用线路，看备用能不能在预期时间内接管。演练比配置更能说明问题。

### 5.2 链路要单独监控

跨网链路的状态不能只看设备端口。我们加了三个探针：端到端时延、丢包率、TCP 建连时间，一分钟采一次，任何一项超过基线两倍就告警。

这条路的主备切换我后来做成了一张配置表，放在搭贝的定时任务里每五分钟核对一次实际路由和配置是否一致，不一致就推送告警，避免有人手改之后忘了回滚。

### 5.3 什么规模用隧道就够

日跨网流量不到二十 G、没有强同步调用、能接受偶尔重连的，隧道够用，成本差得很远。反过来，如果跨网是主链路、门店开单依赖它，专线加备用是必要的。

判断标准不是技术先进，是业务能不能忍。能忍二十秒中断的，不必花两个月等专线；忍不了的，早点去排队。

## 常见问题

**问：隧道和专线能不能同时用？**

答：能，而且建议。专线做主用、隧道做备用，切换靠路由度量值。要注意隧道要保持常连状态，否则故障时还要加上建连时间。两条链路的路由不能同时生效，否则会出现来回路径不一致。

**问：跨网访问慢，怎么判断是带宽还是时延？**

答：看两个指标。带宽不够的表现是大流量时慢、小请求正常，抓包能看到重传和窗口打满；时延高的表现是所有请求都慢一个固定值，小请求也慢。前者加带宽或限流，后者只能换线路。

**问：两端网段重叠怎么办？**

答：优先改，把测试段或者历史段迁移掉。改不动就在边界做 NAT，但 NAT 会让日志里的地址失去意义，排查问题时多一层换算。过渡期可以接受，长期不要留。

**问：专线断了备用没接管，常见原因是什么？**

答：多数是健康检查没配或者配错方向。检查要覆盖整条路径，不能只探对端接口地址，因为中间段断了接口还是通的。另外要确认备用路由的度量值确实比主用小，有些设备在 BGP 撤路由时不会自动切静态路由。

2022 年 3 月，一个客户的 ERP 还在自己的机房，新做的应用放在云上。两边要通，业务方给的期限是两周，因为四月初有一批门店要上线。

混合云的网络打通：专线与隧道怎么选

IDC 机房 ERP 与云上应用互通，先用 IPSec 隧道快速打通，交付快成本低，但公网抖动、带宽争抢影响收银交互；后续申请专线做主链路、隧道作为备用。按交互、批量、备份三类流量做 QOS 限速，依靠路由度量值自动切换，重点规避网段冲突、路由不对称等坑，链路稳定性由业务容忍度决定。

人工智能

跨网混合云架构面临时延抖动与业务连续性挑战，IPsec隧道快速交付但公网质量不稳，专线稳定但交付周期长。按流量分类管理、双线路主备路由设计、网段规范是核心策略，建议以业务容忍度选择链路方案。

代码解释

密钥管理

数据库

混合云

路由

CIDR

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

混合云的网络打通：专线与隧道怎么选-腾讯云开发者社区-腾讯云

混合云的网络打通：专线与隧道怎么选

混合云的网络打通：专线与隧道怎么选

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐