3. 网络层容灾：多可用区VPC设计、子网划分、路由策略

网络层容灾，说白了就是让你的业务流量在多个可用区之间“活起来”。

我见过太多团队，应用层做了双活，数据库做了主备，结果网络一抖，整个架构直接瘫痪。为什么？因为网络是骨架，骨架断了，肌肉再强也没用。

这一章，我们聚焦VPC设计、子网划分和路由策略。这三个东西，是网络层容灾的“三驾马车”。

3.1 多可用区VPC设计：一个VPC，多个AZ

我个人习惯，一个业务系统只用一个VPC。别搞什么跨VPC互联，那是给自己找麻烦。在一个VPC内部，通过子网划分来隔离不同可用区。

核心原则：

• 一个VPC覆盖所有可用区：比如你在华北2（北京）部署，那就创建一个VPC，CIDR块建议用10.0.0.0/8或者172.16.0.0/12，留足扩展空间。
• 每个可用区一套子网：比如可用区A、B、C，每个区都创建自己的公有子网和私有子网。
• 子网CIDR不重叠：这是铁律。重叠了，路由表就乱了。

你想想看，如果每个可用区都有独立的子网，那么当某个可用区故障时，流量可以平滑切换到其他可用区的子网。这就是容灾的基础。

3.2 子网划分：公有、私有、数据三层

子网划分不是随便切几刀就完事。我建议按功能角色来分，至少三层：

子网类型	用途	是否关联NAT网关	典型CIDR示例
公有子网	负载均衡器、NAT网关、堡垒机	否（直接通过IGW访问公网）	10.0.1.0/24（AZ-A） 10.0.2.0/24（AZ-B）
私有子网	应用服务器、微服务	是（通过NAT出公网）	10.0.11.0/24（AZ-A） 10.0.12.0/24（AZ-B）
数据子网	数据库、缓存、消息队列	否（完全内网隔离）	10.0.21.0/24（AZ-A） 10.0.22.0/24（AZ-B）

嗯，这里要注意：数据子网绝对不能关联NAT网关，也不能直接暴露公网。我见过有人图省事，把数据库放在私有子网里，结果被扫到端口，差点出事。

3.3 路由策略：让流量知道往哪走

路由策略是网络层容灾的灵魂。子网划好了，VPC建好了，但流量不知道往哪走，一切都是白搭。

核心路由表设计：

• 公有子网路由表：默认路由指向互联网网关（IGW），内网路由走VPC内。
• 私有子网路由表：默认路由指向NAT网关（用于出公网），内网路由走VPC内。
• 数据子网路由表：只有内网路由，没有默认路由。完全隔离。

为什么会这样设计？说白了，就是让不同角色的流量走不同的路径。公有子网的流量直接出公网，私有子网的流量通过NAT出去，数据子网压根不出公网。

多可用区路由策略的关键点：

• 每个可用区的子网使用独立的路由表：别把所有子网塞进一个路由表。否则一个可用区挂了，路由表也跟着乱。
• 跨可用区流量走内网：比如AZ-A的应用服务器访问AZ-B的数据库，走的是VPC内网，延迟低、带宽高。
• 故障切换时，路由表自动更新：比如AZ-A的NAT网关挂了，流量自动切换到AZ-B的NAT网关。这需要配合路由传播和健康检查。

3.4 核心逻辑图：多可用区网络架构

下面这张图，是我自己总结的多可用区网络架构核心逻辑。你看一眼，就能明白流量怎么走、故障怎么切。

这张图里，每个可用区都有独立的三层子网。流量从IGW进来，先到公有子网的负载均衡器，然后转发到私有子网的应用服务器，最后访问数据子网的数据库。跨可用区的流量走内网，延迟低、安全高。

如果可用区A挂了，负载均衡器会自动把流量切到可用区B。数据库主备切换后，应用服务器也能无缝连接到备库。这就是网络层容灾的核心逻辑。

3.5 实战避坑清单

最后，我把自己踩过的坑和总结的经验列出来，你直接拿去用：

1. 子网CIDR一定要留够：每个子网至少/24，别用/28那种小网段。后期扩容时你会感谢我的。
2. 路由表一定要独立：每个可用区的子网用独立的路由表。别图省事合并，否则故障时你会哭。
3. NAT网关要跨可用区部署：每个可用区至少一个NAT网关。别只部署一个，否则它挂了，整个私有子网都出不了公网。
4. 数据子网绝对不要关联NAT：数据库、缓存这些，完全内网隔离。出公网的需求，通过应用层代理解决。
5. 路由传播要开启：如果用了VPN或者专线，记得开启路由传播。否则故障切换时，路由表不会自动更新。

网络层容灾，说白了就是“规划好、隔离好、路由好”。VPC设计、子网划分、路由策略，这三件事做好了，你的架构就稳了一半。剩下的，就是应用层和数据层的事了。

---

公众号:蓝海资料掘金营，微信deep3321