4. 计算资源的多区域高可用设计

计算资源的高可用，核心不在于“多开几台虚拟机”，而在于让实例分布、扩缩容、健康检查与自愈形成一条闭环：流量进入负载均衡，负载均衡把请求分发给健康实例；实例由托管实例组（MIG）统一编排；MIG 依据模板和策略在多区域或单区域内维持期望容量；健康检查持续判定实例可用性；自愈机制在判定失败后自动重建实例。理解这条闭环，才能判断一个多区域计算架构到底能不能扛住单区域故障。

区域级 MIG 与区域 MIG 的本质差异

Google Cloud 的 MIG 有两种作用域。区域级 MIG（zonal MIG）把实例固定在一个可用区，例如 asia-east1-a；区域 MIG（regional MIG）则把实例分散在同一区域的多个可用区，例如 asia-east1-a/b/c。两者都使用实例模板，但故障域不同：区域级 MIG 遇到该可用区整体故障时，整个实例组不可用；区域 MIG 在某个可用区故障时，其余可用区实例仍可继续服务，并且 MIG 会尝试在健康可用区补足容量。

选择时可以用一个简单判断：如果业务只要求单可用区内的快速重建，区域级 MIG 足够；如果要求“单可用区故障不中断服务”，应使用区域 MIG，并配合跨区域的外部应用负载均衡或全局负载均衡。需要强调的是，区域 MIG 解决的是“区域内多可用区”的高可用，不等于“多区域”容灾。真正的多区域高可用，通常要在两个或更多区域分别部署区域 MIG，再由全局负载均衡统一入口。

自动扩缩容：让容量跟随负载而不是跟随猜测

MIG 的自动扩缩容基于自动扩缩器（autoscaler）。它周期性采集实例的利用率指标，与目标值比较后调整实例数量。常用配置包括：目标 CPU 利用率、最小实例数、最大实例数、冷却期、扩缩容控制。例如一个 Web 前端 MIG 设置目标 CPU 利用率 60%、最小 3、最大 12，当平均 CPU 持续高于 60% 时扩容，低于目标并稳定后缩容。

多区域场景下，扩缩容要特别关注两点。第一，每个区域的 MIG 应独立配置自动扩缩容，避免一个区域的负载波动被误判为全局需求。第二，最小实例数要保证“单区域故障后剩余容量仍能承接全部流量”。例如两个区域各最小 3 台、单台可承载 100 QPS，总容量 600 QPS；若一个区域整体故障，剩余 3 台只能承载 300 QPS，若峰值是 500 QPS 就会过载。因此最小实例数应按“N+1 区域容量”反推，而不是只按日常均值设置。

健康检查与自愈：判定标准决定恢复速度

健康检查分为两类：负载均衡健康检查决定是否把流量发给实例；MIG 自愈健康检查决定是否重建实例。两者可以共用同一个健康检查端点，但参数含义不同。以 HTTP 健康检查为例，关键参数包括：检查间隔（checkIntervalSec）、超时（timeoutSec）、健康判定阈值（healthyThreshold）、不健康判定阈值（unhealthyThreshold）。例如间隔 10 秒、超时 5 秒、不健康阈值 3 次，意味着实例连续约 30 秒失败后被判定不健康。

自愈的触发条件是：实例被判定为不健康，或实例被删除、停止、进入修复状态。MIG 会尝试重建实例以维持目标容量。这里有一个常见误区：自愈不是“修复原实例”，而是“用实例模板重建一个新实例”。因此实例模板必须包含完整的启动配置，包括启动脚本、镜像、服务账号、网络标签和元数据。如果应用依赖本地磁盘数据，重建后数据会丢失，必须把状态外置到 Cloud Storage、Cloud SQL 或 Firestore。

多区域部署的落地要点

一个可参考的多区域计算部署如下：在 asia-east1 和 asia-east2 各创建一个区域 MIG，使用同一个实例模板；两个 MIG 都挂到全局外部应用负载均衡的后端服务；后端服务开启健康检查，并配置故障转移。自动扩缩容按区域独立设置，最小实例数按“单区域可承接全量流量”反推。发布时使用滚动更新（rolling update），设置 maxSurge 和 maxUnavailable，例如 maxSurge=1、maxUnavailable=0，保证更新期间容量不下降。

验证高可用是否真正生效，不能只看控制台显示“健康”。可以按以下顺序做故障演练：先手动删除一个实例，观察 MIG 是否在数十秒内重建；再模拟一个可用区不可用，观察区域 MIG 是否在其余可用区补足；最后模拟一个区域整体不可用，观察全局负载均衡是否把流量切到另一区域，以及剩余区域是否因容量不足而出现延迟上升。每一步都应记录恢复时间、错误率和容量变化，作为后续调整最小实例数和健康检查阈值的依据。

最后要区分“高可用”和“灾备”。区域 MIG 解决的是区域内多可用区的高可用；多区域 MIG 加全局负载均衡解决的是区域级故障的持续服务能力。两者叠加，再配合合理的自动扩缩容下限和健康检查阈值，才能让计算资源在真实故障中保持可服务，而不是只在纸面架构上看起来可靠。