SD-WAN 能不能替代 MPLS
什么该换，什么不能换

为什么这个问题会被反复问

过去十年企业网络有两个变化叠加在一起。一是业务上云：原本都在数据中心的应用搬到了公有云和 SaaS，流量模型从「分支 → 总部」变成了「分支 → 互联网」，再把所有流量回传总部绕一圈就显得很不划算。二是站点数量增长：连锁门店、区域办事处的扩张速度远超 MPLS 的开通节奏，一条专线等几周，门店等不起。

SD-WAN 正好对上了这两个痛点，于是「替代 MPLS」的说法流行起来。但流行的说法通常会丢掉前提条件 —— 它替代的是 MPLS 在某些站点、某些流量上的角色，不是 MPLS 的全部。

把问题拆成六个

与其争论能不能替代，不如逐项回答下面六个问题。每一项的答案都会把边界往一边推：

实际项目里六项很少全部指向同一边 —— 这恰恰说明正确答案通常是混合部署，而不是整网切换。

省下来的到底是哪部分钱

SD-WAN 的成本优势来自三处，值得分开看，因为它们的确定性差别很大：

• 带宽单价差：互联网带宽的单位成本远低于专线带宽。这部分节省是确定的、可测算的 —— 前提是确实有相当比例的流量可以安全地切到互联网上。
• 专线降档：非关键流量卸载后，原有专线可以降低带宽档位。这部分同样确定，但降幅取决于流量构成，需要先做一轮实际流量分析，不能拍脑袋估。
• 交付与变更成本：新站点 CPE 到场当天即可纳管，不必等专线开通；策略变更集中下发，不用逐站上门。这部分省的是时间和人力，账面上不明显，但对扩张快的企业往往是最大的一项。

需要同时算进去的是新增成本：CPE 设备（购买或租赁）、编排平台的使用、以及如果原本没有的话 —— 安全能力。流量走互联网出口意味着安全边界外移，这部分能力要么由 SASE 补上，要么在别处付出代价。

哪些地方不该换

数据中心之间的互联

DCI 承载的通常是数据库同步复制、灾备数据流和虚拟化平台之间的心跳。这类流量对时延抖动和丢包的容忍度极低，且带宽占用长期稳定 —— 正是专线（乃至裸纤）最划算的场景。用互联网加 SD-WAN 承载 DCI，省下的带宽费很可能不够赔一次同步失败。

交易与低时延链路

交易系统的国际互联属于另一个量级的需求。这类链路走的是超低时延专线产品线，时延目标以微秒计，接入点、路由路径和冗余方式都需要逐项设计。SD-WAN 在这里没有可发挥的空间 —— 它优化的是「选哪条链路」，而这类场景本来就只有一条可选。

有明确合规要求的流量

某些行业对流量路径有审计或隔离要求，规定不得经过公共互联网。这种情况下技术上的性价比让位于合规约束，专线是唯一选项。方案设计阶段需要把这类要求提前识别出来，否则做到验收阶段才发现要返工。

混合部署实际怎么落地

混合方案的难点不在技术，在策略怎么定、谁来维护。落地时通常按这个顺序推进：

1. 先做流量分析：搞清楚现有专线上跑的到底是什么。多数企业做完这一步会发现，关键业务只占专线带宽的一小部分。
2. 划分应用等级：把应用分成「必须走专线」「优先走专线、可降级」「走互联网即可」三类，这是后续所有策略的基础。
3. 确定站点分层：核心站点、区域站点、末端站点分别用什么承载方式，不必一刀切。
4. 分批割接：先在少量站点验证策略，跑一个业务周期确认无异常，再批量推开。多站点支持并行交付，但验证不能省。
5. 建立统一监控：混合部署最怕的是「专线归 A 家、互联网归 B 家、CPE 归 C 家」，出问题时互相推诿。统一编排与单一责任方，是混合方案能不能长期跑下去的关键。

弗雷德云把 VPN、专线、SD-WAN、SASE 作为同一套线路规划来部署，而不是各自独立的产品，就是为了避免出现网络和安全两套互不感知的策略。全网由 7×24 NOC 统一监控与主动告警，端到端链路可用性 99.5%，VIP 故障 100% 跟踪。