企业完成单云部署后，往往因为成本、合规或容灾要求引入第二个云平台。此时最先遇到的瓶颈通常不是计算也不是存储，而是网络——两朵云之间怎么通、通得多快、通得有多可控，直接决定了后续架构的复杂度和运维成本。
一、三类主流互通方式
1. VPC 对等连接
VPC 对等是最轻量的方案：两端各划一个网段，建立对等关系后即可通过内网地址互访。它的优点是开通快、成本接近于零，适合两个 VPC 之间的简单互通，或者同云内多账号、多环境的打通。
限制也很明确：不支持网段重叠，且大多数云厂商不支持跨对等的路由传递，也就是 A 对 B、B 对 C 不会自动得到 A 到 C。规模一上来，对等连接数量会呈平方级增长，路由表迅速失控。
2. VPN 隧道
基于公网建立 IPSec 隧道，适合对带宽要求不高、但对开通速度敏感的场景。典型用途是临时打通、开发测试环境互联，或者作为专线的备份链路。
需要注意两点：一是实际吞吐受限于公网质量和加密开销，通常单隧道稳定在百兆级别；二是需要关注隧道的保活与重协商策略，否则容易出现「链路在但业务不通」的假象。
3. 云专线 / 专线网关
通过物理专线把两个云环境接入同一张骨干网，是承载生产流量的主流选择。时延稳定、带宽可保底、不经过公网，适合核心交易与数据同步链路。
代价是开通周期长（通常数周）、成本高，并且需要规划冗余——单条专线本身就是单点故障，生产环境一般会配合第二条专线或 VPN 做备份。
二、选型时真正该看的四个维度
- 带宽与稳定性要求：决定是 VPN 还是专线。核心链路不要用 VPN 硬扛。
- 网段规划：如果两端网段已经重叠，对等连接直接出局，只能走 NAT 或专线网关做地址转换。
- 是否需要多环境互通：超过三个 VPC 时，对等连接的维护成本会明显高于星型（Hub-Spoke）或云企业网方案。
- 故障切换时间：明确主备切换的收敛目标，并据此选择路由协议与探测机制。
三、几个容易踩的坑
网段规划要在最前面做。很多项目是先各建各的，等到要互通时才发现生产环境和测试环境都用了 10.0.0.0/16，只能回头改 IP，代价极大。建议在规划阶段就给每个云、每个环境预留独立的地址块。
MTU 容易被忽略。隧道封装会占用额外字节，如果两端 MTU 不一致又没做路径 MTU 发现，大包会被静默丢弃，表现为「小文件正常、大文件卡住」这类难查的问题。
DNS 解析要设计。互通之后紧接着的问题就是服务怎么被找到。建议提前规划私有域名空间和转发规则，避免出现只能通过 IP 硬编码访问的尴尬局面。
四、一个务实的落地顺序
建议按「先打通、再优化、后治理」推进：第一步用 VPN 或对等连接快速验证应用层的连通性，把依赖关系和流量模型摸清楚；第二步根据实测流量确定带宽与路径，把核心链路切到专线；第三步补上网段规范、路由策略与监控告警，把这条通道纳入日常运维体系。
混合云网络的复杂度不来自技术本身，而来自「先建后想」。把地址规划、路由策略和故障切换这三件事提前想清楚，后续的每一次扩容都会轻松很多。
