VPC 对等连接成了流量瓶颈：云原生网络架构选型与 5 个生产级决策
概述 凌晨两点，某出行项目的告警群炸了。下单服务的 P99 延迟从 80ms 飙到 600ms，用户端开始大面积超时。排查了一圈，发现是 VPC 之间的对等连接（VPC Peering）成了瓶颈——两个核心业务 VPC 之间的跨 VPC 调用量在业务高峰期打满了单条 Peering 的并发连接数，而与此同时，另一个刚上线的 VPC 通过 Full Mesh 模式新建的 12 条 Peering 连接中有 3 条因为 CIDR 重叠配置失败，路由表混乱导致部分流量绕了远路。 这不是个例。当你的云上 VPC 数量超过 5 个，Full Mesh Peering 的维护成本就开始指数级增长。超过 10 个，运维团队基本就在疲于奔命了。 我曾经在某新能源物流平台主导过 120+ 微服务的 K8s 迁移，迁移之前花了很多精力做网络架构评审。当时就发现一个规律：很多团队的网络故障不是出在应用层，而是出在网络架构选型阶段埋下的坑。VPC Peering 看起来简单直接，但它有几个硬伤——不支持传递路由、Full Mesh 连接数 N*(N-1)/2 增长、无法集中管控路由策略。等你发现问题的时候，架构已经固化了，改造的代价远大于初始选型时多花两天做决策。 这篇文章不讲"VPC 是什么"这种入门概念。我假设你已经在用云、在管 VPC，遇到过多 VPC 互联的痛点。我要拆解的是：什么时候该用 VPC Peering，什么时候该切换到 Transit Gateway / CEN 转发路由器，混合组网怎么做，CIDR 规划怎么避免"网络一上线就得返工"。每个决策点我都给出生产环境的真实数据和踩坑细节，不是泛泛说"各有优劣"。 VPC Peering 的三个硬伤 VPC Peering 是两个 VPC 之间的点对点网络连接，流量走云厂商骨干网，同地域不收费，延迟低。听起来很美。但它在生产环境中有三个绕不过去的问题。...