3. 高可用与灾备设计原则

在 Google Cloud 上构建多区域高可用与灾备架构，核心不是“堆资源”，而是用一组可验证的设计原则约束系统行为。这些原则包括：冗余、故障隔离、优雅降级、自动化恢复，以及混沌工程思想。它们共同支撑 Google Cloud 架构框架中的可靠性支柱——可靠性支柱强调系统在预期负载和故障条件下持续正确服务的能力，并用量化目标（SLO、错误预算）驱动工程决策。

冗余：消除单点，但避免“冗余即高可用”的误区

冗余的本质是让任一组件失效时，系统仍有替代路径继续服务。冗余分为几个层次：

• 实例级冗余：同一区域内部署多个无状态实例，通过托管实例组（MIG）或 GKE 多副本分散故障域。
• 区域级冗余：跨多个可用区（zone）部署，例如 Cloud SQL 高可用配置、GKE 多 zone 节点池、区域级后端服务。
• 多区域冗余：跨 region 部署，用于抵御区域级灾难，通常配合全局负载均衡和异步/同步复制。

冗余不是越多越好。每增加一个副本，都会带来一致性、成本和运维复杂度的上升。例如，跨区域同步复制会显著增加写延迟；异步复制则可能带来 RPO（恢复点目标）窗口。设计时需要先明确 RTO（恢复时间目标）和 RPO，再决定冗余层级。一个常见的教学示例是：某业务要求 RTO ≤ 15 分钟、RPO ≤ 5 分钟，则单区域多 zone 加异步跨区域复制通常足够；若要求 RPO ≈ 0，则必须考虑同步复制或强一致方案，并接受延迟代价。

故障隔离：把爆炸半径限制在最小范围

故障隔离的目标是防止局部故障扩散为全局故障。Google Cloud 提供了多种隔离边界：

• 区域与可用区：zone 是物理隔离的故障域，region 是逻辑隔离边界。
• 项目与 VPC：不同环境、不同业务线使用独立项目或 VPC，避免配额、网络策略和 IAM 故障互相影响。
• 配额与限流：为关键服务设置独立配额，防止某个租户或任务耗尽共享资源。
• 熔断与舱壁：在应用层对下游依赖设置超时、重试上限和熔断阈值，避免级联失败。

一个实用的隔离检查方法是：假设某个 zone 完全不可用，系统是否仍能满足 SLO？假设某个下游服务延迟翻倍，调用方是否会线程耗尽？如果答案是否定的，说明隔离边界不足。

优雅降级：在资源不足时仍提供核心价值

优雅降级是指系统在部分能力受损时，主动关闭非核心功能，保证核心链路可用。例如：

• 推荐服务不可用时，返回热门榜单而非个性化推荐。
• 图片处理服务过载时，返回低分辨率占位图。
• 跨区域复制延迟过高时，读请求降级为本地读，并明确提示数据可能不是最新。

降级策略必须提前设计并经过测试，而不是故障发生时临时决定。建议为每个关键依赖定义“降级开关”和“降级后的用户可见行为”，并纳入发布流程。

自动化恢复：用健康检查和自愈替代人工介入

自动化恢复依赖三个要素：可观测性、健康判断和自动动作。在 Google Cloud 中，常见组合包括：

• 健康检查（HTTP/TCP/HTTPS）配合后端服务，自动剔除不健康实例。
• MIG 自动修复（autohealing）根据健康检查重建实例。
• Cloud Monitoring 告警触发 Cloud Functions 或 Cloud Run 执行修复脚本。
• GKE 的 liveness/readiness probe 与 Pod 重启、节点自动修复。

自动化恢复的关键是“判断条件要保守，恢复动作要幂等”。例如，健康检查失败阈值设置过小会导致误杀，过大则恢复缓慢。通常建议连续失败 3 次、间隔 10 秒作为起点，再根据业务调整。

混沌工程思想：主动验证，而不是等待故障

混沌工程不是“随机破坏”，而是在受控条件下主动注入故障，验证系统是否按预期降级和恢复。Google Cloud 上可以结合以下方式实践：

• 使用 Fault Injection Service 或自建脚本模拟 zone 故障、实例终止、网络延迟。
• 在预发布环境先验证，再逐步扩大到生产环境的非高峰时段。
• 每次实验必须有明确的假设、观测指标和回滚方案。

混沌工程与可靠性支柱中的“持续验证”一致：通过实验发现隐藏的单点、错误的超时配置、不合理的重试策略，从而在真实故障前修复。

把原则落到可执行的检查项

下面给出一份可直接用于评审的检查清单，覆盖上述五个原则。它不替代架构设计，但能帮助团队在发布前发现明显缺口。

最后需要强调：所有原则都必须与可观测性绑定。没有指标、日志和追踪，就无法判断降级是否生效、恢复是否完成、SLO 是否被突破。建议为每个关键用户旅程定义 SLI（如可用性、延迟、正确性），并设置错误预算告警。当错误预算消耗过快时，优先暂停新功能发布，转而投入可靠性修复——这正是 Google Cloud 架构框架中可靠性支柱的工程化体现。