4. 计算层多区域高可用设计

计算层是业务真正运行的地方，也是多区域高可用设计中最容易“看起来做了、实际没生效”的一层。原因在于：计算资源不像存储那样天然支持跨区域复制，它需要显式地在两个或更多区域中各部署一份，再通过流量分发把请求导向健康的那一份。本节围绕虚拟机（VM）、虚拟机规模集（VMSS）、App Service 和 AKS 四类计算资源，说明跨区域部署、流量分发与故障转移的具体做法。

先明确一个前提：计算层的“区域”是部署边界

在 Azure 中，区域（Region）是故障隔离域。计算资源一旦创建在某个区域，其计算、网络接口、可用区分布都绑定在该区域内。因此计算层多区域高可用的本质是：同一套应用在两个区域各部署一份独立实例，二者之间不共享计算状态，只共享数据层。流量分发组件负责在两者之间做健康探测与切换。理解这一点后，四类资源的差异只体现在“如何部署第二份”和“如何切换流量”上。

虚拟机与虚拟机规模集：可用区优先，跨区域兜底

单区域内的 VM 高可用应优先使用可用区（Availability Zone）。把同一角色的 VM 分散到 1、2、3 三个可用区，可抵御单可用区故障。但可用区无法抵御区域级故障，因此跨区域方案是在第二个区域再部署一套 VM 或 VMSS。

对于 VMSS，推荐使用 Flexible 编排模式，并设置 zones: [1,2,3]，使实例自动跨可用区分布。跨区域时，两个区域的 VMSS 通过负载均衡层对外提供服务。下面是一个 VMSS 跨区域部署的关键参数示例：

# 区域 A 的 VMSS（示例参数）
sku: Standard_D4s_v5
instances: 6
zones: [1, 2, 3]
upgradePolicy: Rolling
overprovision: true

# 区域 B 的 VMSS（与 A 对称）
sku: Standard_D4s_v5
instances: 6
zones: [1, 2, 3]
upgradePolicy: Rolling
overprovision: true

两个 VMSS 的实例数不必完全相等。若采用“主备”模式，区域 B 可保持较小规模（如 2 个实例）作为热备；若采用“双活”模式，则两侧规模接近，由流量分发按权重分配。故障转移时，健康探测失败的一方被摘除，流量全部导向另一方。需要注意：VMSS 的自动缩放规则应分别配置，避免故障切换后单侧被突发流量压垮。

App Service：用流量管理器或 Front Door 做跨区域入口

App Service 的多区域方案相对简单，因为它是 PaaS 服务，不需要管理底层 VM。做法是：在两个区域各创建一个 App Service 计划和应用，然后在前端挂一个全局流量分发器。常用两种选择：

• Azure Traffic Manager：基于 DNS 的全局负载均衡，支持优先级、加权、性能、地理等路由方式。故障转移依赖 DNS TTL，切换通常需要数十秒到数分钟。
• Azure Front Door：基于 Anycast 的七层入口，支持毫秒级健康探测和快速故障转移，同时提供 CDN、WAF 和 SSL 卸载。

若业务对切换时间敏感，优先选 Front Door；若只需简单的优先级主备，Traffic Manager 成本更低。无论选哪种，都要在两个区域的应用上配置相同的自定义域和证书，并确保应用配置（如连接字符串）指向可跨区域访问的数据层。

AKS：跨区域集群 + 全局入口 + 数据层对齐

AKS 的多区域设计是四类中最复杂的，因为它涉及集群、入口、服务发现和数据四个层面。推荐结构是：在两个区域各部署一个独立 AKS 集群，每个集群内部跨可用区部署节点池，前端用 Front Door 或 Traffic Manager 做全局入口，两个集群各自暴露一个入口 IP 或主机名。

关键点有三个。第一，两个集群的 Kubernetes 清单应保持一致，通过 GitOps（如 Flux 或 Argo CD）同步部署，避免手工漂移。第二，服务发现不要跨区域做，每个集群内部用自己的 Service 和 Ingress，跨区域只发生在入口层。第三，数据层必须能被两个集群同时访问，通常使用 Azure SQL 的异地副本、Cosmos DB 的多区域写入或 Azure Files 的跨区域复制。

下面是一个 AKS 跨区域部署的结构示意，展示了两个区域集群如何通过全局入口对外服务：

故障转移的判断依据与验证方法

无论哪类计算资源，故障转移是否生效，取决于三个可观察点：健康探测结果、流量分配比例、以及应用实际响应。以 Front Door 为例，健康探测默认每 30 秒一次，连续失败达到阈值后将该后端标记为不健康。验证时可以在区域 A 的应用上人为返回 500 或停止服务，观察 Front Door 的后端健康状态是否在预期时间内变为“不健康”，以及请求是否全部落到区域 B。

对于 VMSS 和 AKS，还需要额外验证数据层是否可写。一个常见陷阱是：计算层切换成功，但区域 B 的应用连的是只读副本，导致写操作失败。因此故障转移演练必须包含一次真实的写操作，例如创建一条订单记录，确认写入成功且能被读回。

四类资源的选型对照

选择时的一个实用原则是：切换粒度越细，配置越复杂，但资源利用率越高。VM 和 VMSS 适合对底层有控制需求的场景；App Service 适合快速交付的 Web 应用；AKS 适合微服务架构，但需要额外投入 GitOps 和数据层对齐的工作。无论选哪种，计算层的多区域设计都必须与数据层的多区域能力匹配，否则计算切换得再快，数据不可写也无法真正恢复业务。