2. Azure虚拟网络设计与规划

Azure虚拟网络（VNet）是Azure中所有私有网络能力的边界与容器。它既是虚拟机、容器、应用网关、数据库等资源的网络归属，也是网络安全组、路由表、私有终结点、对等互连等策略的施加对象。设计一个VNet，本质上是在回答四个问题：地址空间留多大、子网怎么切、区域与可用区如何分布、多环境之间如何组织拓扑。这四个问题一旦确定，后续的IP冲突、扩容受限、跨环境互通困难等麻烦大多可以避免；反之，返工成本极高，因为地址空间和子网在承载资源后很难无损修改。

一、VNet地址空间规划

VNet地址空间使用私有IP地址段，遵循RFC 1918：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。Azure允许在创建后向VNet追加地址空间，但已分配的子网不能随意扩大或移动，因此规划时应按“未来3～5年规模”预留，而不是只按当前需求切分。

规划的核心是分层分配。建议企业先确定一个全局地址池，再按环境、区域、业务域逐级切分。例如某企业使用10.0.0.0/8作为整体私有地址池，可按如下方式划分：

这里有一个关键约束：如果VNet需要与本地数据中心通过VPN网关或ExpressRoute互通，那么VNet地址空间与本地网络地址空间不能重叠。重叠会导致路由无法正确选择，表现为部分流量被黑洞丢弃。因此在规划阶段，必须把本地网络、其他云、分支机构、容器网段全部纳入统一地址管理，形成一份“IP地址分配表”并作为变更受控文档维护。

另一个常见误区是地址空间过小。例如只给生产VNet分配10.10.0.0/24，看似有254个地址，但Azure每个子网会保留5个地址（网络地址、网关地址、DNS映射地址、广播地址、保留地址），且子网一旦创建就无法扩容到超出VNet地址空间的范围。当需要新增子网或扩大节点规模时，就会被迫重建VNet。因此建议单个VNet至少使用/16，子网按/24起步，大规模集群子网可用/22或/21。

二、子网划分原则

子网是VNet内的逻辑分段，也是安全策略和路由策略的最小施加单位。子网划分应遵循“按功能分层、按信任级别隔离”的原则，而不是按服务器数量平均切分。

典型的三层子网结构如下：

• Web/前端子网：承载应用网关、负载均衡器、公网入口，通常与Internet有受控连接。
• 应用/中间层子网：承载业务应用、API服务，只接受来自前端子网的流量。
• 数据/后端子网：承载数据库、缓存、存储私有终结点，禁止任何Internet出站。

此外，Azure中有些服务要求专用子网，必须提前预留，不能与普通业务子网混用：

• GatewaySubnet：VPN网关或ExpressRoute网关专用，名称固定，建议/27或更大。
• AzureFirewallSubnet：Azure防火墙专用，建议/26。
• AzureBastionSubnet：堡垒机专用，建议/26。
• 应用网关、API Management、容器实例等也可能需要独立子网。

子网划分时还要注意：子网不能与同一VNet内其他子网重叠，也不能与对等互连的VNet或本地网络重叠。建议在地址表中为每个子网标注用途、CIDR、可用地址数、所属安全组和路由表，形成可审计的配置基线。

三、区域与可用区考量

Azure区域（Region）决定资源的物理位置和延迟边界，可用区（Availability Zone）是同一区域内物理隔离的数据中心组。设计VNet时，区域选择主要影响三件事：合规与数据驻留、用户延迟、服务可用性。

如果业务要求高可用，应优先选择支持可用区的区域，并将关键资源分布到多个可用区。例如在“东亚”区域创建VNet，子网本身是区域级资源，但其中的虚拟机可以分布到可用区1、2、3。此时VNet地址空间不需要按可用区拆分，因为子网跨可用区共享同一CIDR；真正需要规划的是负载均衡、数据库副本和存储冗余策略。

对于跨区域场景，通常采用“每个区域一个VNet”的模式，再通过VNet对等互连或Azure Virtual WAN实现互通。这样做的原因是：VNet是区域级资源，不能跨区域直接创建；跨区域通信必须依赖全局对等互连或网关。跨区域对等互连的流量会经过Azure骨干网，延迟通常低于公网，但会计费，需要在成本模型中体现。

四、企业多环境VNet拓扑设计

企业通常需要生产、测试、开发、共享服务等多套环境。拓扑设计要在“隔离”和“互通”之间取得平衡。常见模式有三种：

• 完全隔离：每个环境独立VNet，互不连通。安全性最高，但共享服务需要重复部署，运维成本高。
• 中心辐射（Hub-Spoke）：一个中心VNet承载防火墙、网关、DNS、跳板机等共享服务，各环境作为辐射VNet通过对等互连接入中心。这是企业最常用的模式。
• Virtual WAN：由Azure托管的分支互连服务，适合多区域、多分支、大规模场景，配置更集中，但灵活性略低于自建Hub-Spoke。

下面这张图展示了一个典型的企业Hub-Spoke拓扑：中心VNet位于东亚，包含GatewaySubnet、AzureFirewallSubnet和共享服务子网；生产、测试、开发三个辐射VNet分别与中心对等互连，并通过中心防火墙和网关访问Internet与本地数据中心。辐射之间默认不直接互通，如需互通必须显式配置对等互连或经由中心防火墙转发。

在Hub-Spoke模式中，有几个设计要点需要明确。第一，中心VNet的地址空间要足够大，因为所有共享服务子网都集中在这里，且未来可能新增防火墙、DNS转发器、日志收集等组件。第二，辐射VNet的路由表（UDR）需要将默认路由0.0.0.0/0指向中心防火墙的私有IP，实现出站流量统一检查；同时将本地数据中心网段的路由也指向中心网关，避免辐射VNet直接暴露。第三，对等互连是非传递的：生产VNet与中心对等、测试VNet与中心对等，并不意味着生产与测试可以直接通信。如果确实需要，必须显式建立生产与测试之间的对等互连，或在中心防火墙上配置转发规则。

对于多区域企业，可以在每个区域各建一套Hub-Spoke，再通过全局VNet对等互连或Virtual WAN Hub将各区域的中心VNet连接起来。这样既保证了区域内的流量本地化，又实现了跨区域的统一策略管理。实际落地时，建议先用地址分配表和拓扑图作为设计基线，再通过Azure Policy或IaC模板（如Bicep、Terraform）固化VNet与子网的创建规则，避免手工配置导致命名、CIDR、NSG关联不一致。

总结来看，Azure VNet设计不是一次性任务，而是需要与IP地址管理、安全策略、成本模型同步演进的持续过程。把地址空间、子网、区域、拓扑四件事在规划阶段想清楚，后续的运维和扩展才会从容。