题目与使用场景
这是一个多区域高可用设计题。重点不是画出多个区域，而是说明流量决策依据、健康信号传播、故障时的容量与数据边界，以及如何演练和回切。
面试官考察什么
- 是否区分 DNS、边缘代理和应用层路由的职责与时效。
- 是否使用多来源、分层的健康信号，而不是只探测一个端点。
- 是否计算故障转移后的容量、连接和限流压力。
- 是否明确有状态数据的读写、复制延迟和区域约束。
- 是否防止脑裂、振荡切换和回切放大事故。
- 是否定义 RTO、RPO、SLO 与演练证据。
作答前的澄清问题
- 目标区域、流量峰值和单区域失效模型是什么？
- RTO、RPO、数据驻留和合规限制是什么？
- 请求是无状态读为主，还是包含写入和长连接？
- 调度粒度是 DNS、Anycast、边缘代理还是服务网格？
- 健康判定需要哪些用户路径和依赖检查？
- 客户端 DNS TTL、连接迁移和回切窗口有什么要求？
30 秒回答框架
“我先定义单区域故障、峰值和 RTO/RPO。入口由边缘或 DNS 按延迟选择候选区域，但只把通过多层健康检查且有余量的区域放入集合。区域容量不足时逐步降级和限流，避免把故障流量压垮备用区。写请求遵循数据主从或分片边界，明确复制延迟和重试语义。切换由有抖动保护的控制器执行，回切前先演练、预热并验证指标。”
分步骤深入解答
步骤 1：定义故障与目标。 写出区域、依赖、网络和控制面的故障范围，并把 RTO、RPO、峰值和降级等级量化。
步骤 2：分离决策层。 DNS 或全局入口负责粗粒度区域选择，边缘/服务层负责实时权重、连接和局部限流；不要让单一控制面承载全部故障切换。
步骤 3：构建健康信号。 结合多地点探针、关键用户路径、依赖状态、错误率和容量水位；连续失败、恢复窗口和多数判定用于避免瞬时抖动。
步骤 4：计算容量保护。 预留备用余量，设置每区域并发、队列和速率上限；故障时按优先级丢弃非关键流量，避免级联过载。
步骤 5：处理数据边界。 说明读副本延迟、写入归属、冲突解决、幂等键和跨区域重试；路由切换不能掩盖数据不可写的事实。
步骤 6：执行切换。 控制器记录原因、版本和审批，逐步降低故障区权重，先小比例导流，再扩大；长连接需要重连退避和会话恢复策略。
步骤 7：回切与演练。 备用区预热、指标稳定并完成数据校验后再回切；定期注入区域、依赖和控制面故障，保存真实 RTO/RPO 证据。
高质量示范回答
“我会把每个区域分成入口、无状态服务和数据单元。全局入口按延迟选候选区域，但只有同时满足多地点关键路径检查、错误率阈值和容量余量的区域才接收流量。控制器对权重变化设置最小持续时间和冷却期，先把 5% 流量导向备用区；若备用区达到并发上限，优先保护登录和写入，暂停低优先级报表。写入按租户归属区域处理，跨区重试带幂等键并暴露复制延迟。切换和回切都通过演练验证 RTO、RPO、重连成功率和数据校验结果。”
常见错误
- 只画 DNS 和两个区域 → 忽略容量与数据 → 补充控制器、护栏和写入边界。
- 单次探针失败就摘除区域 → 产生振荡 → 使用连续窗口、冷却期和多数信号。
- 默认备用区能接收全部流量 → 故障时级联过载 → 计算余量并设置分级降级。
- 把 TTL 当成切换完成时间 → 客户端仍缓存旧结果 → 说明连接、缓存和边缘层的实际时延。
- 只说 active-active → 没有冲突策略 → 明确写入归属、复制与幂等。
追问及应对
追问 1：DNS TTL 很长怎么办？
让边缘入口承担更快的权重调整，并把 TTL、递归缓存和连接存活时间纳入 RTO 预算；不能承诺瞬时切换。
追问 2：健康检查本身故障怎么办？
使用多地点、多探针和独立控制面，记录探针新鲜度；检查过期时保持上次安全状态或进入人工保护模式。
追问 3：备用区容量不够怎么办？
预留容量并在切换前预热，按优先级限流、降级或排队；用压测证明单区域故障下的上限。
追问 4：如何避免切换来回震荡？
设置失败与恢复的不同阈值、最小驻留时间、冷却期和人工确认，记录每次权重变化原因。
追问 5：跨区写入出现冲突怎么办？
优先按租户或键指定写入归属，使用版本或幂等条件；若必须多主，明确冲突规则与不可自动合并的数据。
追问 6：如何证明设计有效？
演练区域、依赖、网络和控制面故障，测量 RTO、RPO、错误率、恢复容量、重连成功率和数据校验结果。
追问 7：什么时候不该做多区域？
当数据驻留、复制语义、运营能力或成本无法满足目标时，先做单区域加可验证的灾备；多区域不是默认答案。