4、专线技术基础：专线类型（MSTP、MPLS VPN、SD-WAN），专线接入方式，专线高可用设计
聊到多云互联，专线是绕不开的话题。很多刚入行的朋友觉得专线就是拉一根光纤，其实没那么简单。我做了十几年网络，见过太多因为专线选型不当导致的故障。今天咱们就把专线的底裤扒干净。
4.1 专线类型：MSTP、MPLS VPN、SD-WAN
专线不是一根线，而是一种服务。不同的业务场景，选不同的专线类型。我个人的习惯是：先看业务对延迟和抖动的容忍度，再决定用哪种。
4.1.1 MSTP（多业务传送平台）
MSTP 说白了就是基于 SDH 的升级版。它既能传传统的 TDM 业务，也能传以太网业务。我在早期做金融客户时，经常遇到这种需求——核心交易系统必须用 MSTP，因为它的延迟是确定的，不会因为网络拥塞而抖动。
核心特点：
- 物理隔离，安全性极高
- 延迟固定，通常在 1ms 以内
- 带宽固定，不支持突发
- 价格昂贵，部署周期长（通常 1-3 个月）
嗯，这里要注意：MSTP 虽然稳，但带宽扩展很麻烦。我曾经有个项目，客户从 10M 升到 50M，运营商硬是花了 2 周才调通。所以如果你业务增长快，MSTP 可能不是最佳选择。
4.1.2 MPLS VPN
MPLS VPN 是目前企业最常用的专线技术。它是在运营商骨干网上通过标签交换实现的虚拟专用网络。你想想看，它其实是在共享的物理链路上，给你划了一条逻辑上的专用通道。
为什么大家都爱用 MPLS VPN？因为它性价比高。相比 MSTP，MPLS VPN 的价格只有三分之一左右，而且部署快，一般 1-2 周就能开通。
| 对比项 | MSTP | MPLS VPN |
|---|---|---|
| 隔离方式 | 物理隔离 | 逻辑隔离（标签） |
| 延迟 | 固定，<1ms | 可变，通常 2-5ms |
| 带宽弹性 | 无 | 有（可突发） |
| 适用场景 | 金融核心交易 | 企业分支互联 |
避坑指南：我曾经遇到过一个案例，客户把视频会议跑在 MPLS VPN 上，结果一到下午 3 点就卡顿。后来发现是运营商的 MPLS 网络在高峰期有拥塞，而 SLA 里只承诺了延迟，没承诺抖动。所以，对实时性要求高的业务，一定要在合同里写明抖动指标。
4.1.3 SD-WAN
SD-WAN 是近几年的新宠。它其实不是一种新的物理线路，而是一种 overlay 技术。它可以在普通的互联网、4G/5G、MPLS 等多种链路上，通过软件定义的方式构建一个智能的广域网。
我个人特别喜欢 SD-WAN 的一点是：它能把多条链路捆绑起来用。比如你有一条 MPLS 和一条互联网，SD-WAN 可以自动把关键业务流量走 MPLS，普通流量走互联网。一旦 MPLS 断了，还能无缝切换到互联网上。
我的经验：SD-WAN 最适合多云互联场景。比如你的应用部署在阿里云和 AWS 上，SD-WAN 可以在两个云之间建立加密隧道，还能根据实时延迟自动选择最优路径。我去年帮一个电商客户做双云容灾，就是用 SD-WAN 实现的，切换时间控制在 10 秒以内。
4.2 专线接入方式
专线怎么接到你的机房？这里也有讲究。常见的接入方式有三种：
- 光纤直连：运营商直接拉一根光纤到你的机房，通过光模块对接。这种方式延迟最低，但成本也最高。
- PTN/IP RAN 接入：运营商在靠近你机房的地方部署一个接入设备，你通过网线或光纤连到这个设备上。这是最常见的接入方式。
- 互联网 VPN 接入：通过互联网建立加密隧道，比如 IPsec VPN。这种方式成本最低，但延迟和稳定性都不可控。
你可能会问：我该选哪种？我的建议是：核心业务用光纤直连或 PTN 接入，非核心业务用互联网 VPN。别为了省钱把核心业务跑在互联网上，我见过太多血的教训了。
4.3 专线高可用设计
专线再稳，也会断。所以高可用设计是必须的。我总结了一个「三三制」原则：
- 三条链路：至少两条不同运营商的专线，再加一条 4G/5G 备份
- 三个设备：核心路由器、汇聚交换机、接入路由器，每个节点都做冗余
- 三层检测：物理层（光功率）、链路层（BFD）、应用层（NQA）
高可用架构示例：
主用链路：中国电信 MPLS VPN 100M
备用链路：中国联通 MSTP 50M
应急链路：4G LTE（通过 SD-WAN 接入）
切换策略：
- BFD 检测到主链路故障（3 次丢包）
- 自动切换到备用链路（< 1 秒）
- 备用链路也故障时，切换到 4G（< 5 秒）
- 主链路恢复后，自动回切（需手动确认）嗯，这里有个细节很多人会忽略：回切策略。我曾经有个项目，主链路恢复后自动回切，结果因为回切瞬间导致业务中断了 3 秒。后来我改成手动回切，先观察 10 分钟，确认主链路稳定了再切回来。这个习惯我一直保留到现在。
重要提醒：专线高可用不只是技术问题，更是管理问题。你需要和运营商签好 SLA，明确故障响应时间。我建议至少要求 4 小时到场，8 小时恢复。另外，每季度做一次切换演练，别等到真出事了才发现脚本有问题。
最后说一句：专线技术看起来简单，但坑很多。你想想看，一条专线从运营商机房到你机房，中间经过了多少个跳点？每个跳点都可能出问题。所以，做好监控、做好冗余、做好预案，这才是专线高可用的真谛。