题干与适用场景
设计一个协调器，持续判断多个区域的健康状态，在满足条件时切换流量到备用区域，并在恢复后安全回切。说明控制面与数据面的边界、健康信号、切换保护、数据状态、人工审批、审计和演练方式。
AWS ARC 文档把跨区域路由控制描述为可靠的数据面开关，并强调故障机制本身要在灾难期间可用。Kubernetes 文档则提醒副本、跨可用区分布和 PodDisruptionBudget 共同决定可用性。Amazon 的软件开发面试主题要求把知识应用到系统问题，而不是罗列服务名。
本题不同于“设计多区域 API 网关”：重点是切换决策和恢复编排；也不同于普通健康检查：需要处理误判、脑裂、数据追赶和回切风险。
面试官考察点
- 健康判定是否基于多信号并避免单点误判。
- 切换开关、路由传播和控制面是否能在故障时工作。
- 是否明确 RPO、RTO、数据复制和写入策略。
- 是否有防抖、租约、审批、审计和停止条件。
- 是否通过演练、指标和回切计划证明系统有效。
回答前需要澄清的问题
- 目标 RTO、RPO、可用性和允许的人工介入时间是多少？
- 区域故障是整区不可达、依赖异常、延迟升高还是数据损坏？
- 备用区域是热备、温备还是冷备？
- 哪些数据同步，哪些请求可丢弃或降级？
- DNS、Anycast、网关或客户端如何接收新路由？
- 自动切换失败时谁能人工接管？
- 如何避免两个区域同时接收写入？
- 回切前需要满足哪些健康和数据追赶条件？
- 题目是否要求跨云或只讨论抽象架构？
30 秒回答框架
“我先定义 RTO、RPO 和备用区域的准备级别。每个区域独立运行数据面，协调器只发布经过规则校验的路由状态。健康判定结合业务探针、依赖指标和复制延迟，并用多数信号、防抖和租约避免误切。切换前冻结或降级写入，确认备用区域达到数据门槛，再通过高可用路由控制转移流量。所有状态变化可审计、可回滚；回切需要重新验证数据追赶和一小部分流量试切。”
分步骤深入解答
步骤一：定义故障模型和目标
区分 AZ 故障、区域网络分区、单个依赖故障、错误发布和数据损坏。用 RTO/RPO 决定热备成本、复制模式和自动化程度。
步骤二：划分控制面与数据面
数据面负责服务请求和路由执行，控制面负责计算建议状态、审批和记录。切换依赖应尽量走高可用数据面，避免控制面故障时无法恢复。
步骤三：构建健康判定
组合业务成功率、关键依赖、延迟、复制延迟、容量和人工信号。单个探针失败只产生候选状态；达到阈值并持续一段时间才进入切换流程。
步骤四：执行安全切换
切换状态应有准备、候选、已批准、切换中、稳定和回切等阶段。使用租约或版本号防止并发操作，设置冻结写入、最大切换时长和自动停止条件。
| 阶段 | 关键检查 | 失败动作 |
|---|---|---|
| 准备 | 备用区域就绪、复制延迟达标 | 不允许切换 |
| 候选 | 多信号持续异常 | 进入审批或观察 |
| 切换中 | 路由传播、错误率、容量 | 暂停或回退 |
| 稳定 | 业务指标恢复、写入单一 | 结束切换 |
| 回切 | 主区域健康、数据追赶完成 | 保持备用承载 |
步骤五：处理数据一致性和脑裂
明确单写区域、全局序列或冲突解决策略。分区期间宁可拒绝部分写入，也不要让两个区域同时接受不可合并的写入。记录切换时点和数据缺口。
步骤六：传播路由并控制容量
路由可以通过 DNS、网关或边缘控制传播；说明 TTL、缓存和客户端重试影响。备用区域必须有容量上限、预热步骤和降级策略，避免切换后立即过载。
步骤七：可观测、审计和人工接管
记录健康证据、规则版本、操作者、状态变化和路由结果。告警覆盖切换延迟、错误率、复制滞后、容量和双写迹象。人工操作必须幂等且有权限边界。
步骤八：演练和安全回切
定期做故障注入和分阶段流量切换。回切前确认主区域健康、数据追赶、依赖稳定和容量恢复；先小流量试切，再逐步恢复，并保留快速回退路径。
高质量示范回答
“我设计一个双区域、单写主区域的协调器，目标 RTO 为 5 分钟、RPO 为 30 秒。两个区域都有完整数据面，备用区域保持热缓存和可接收流量的容量。
健康判定同时看业务成功率、关键依赖、复制延迟和容量。连续三个窗口异常才生成切换候选；租约和单调递增版本号保证只有一个协调器能推进状态。切换前暂停主区域写入，确认备用复制延迟低于门槛，再通过高可用路由控制把流量转移。路由传播后观察错误率和延迟，超过阈值立即回退。
所有状态、规则、审批和证据写入审计日志。演练每月验证 DNS 缓存、客户端重试和备用容量。回切必须等主区域完成数据追赶，先转 5% 流量，确认稳定后再逐步恢复；若出现双写或延迟异常，保持备用承载并停止回切。”
常见错误
- 只画两个区域，没有定义谁决定切换。
- 依赖单个 ping 或基础设施指标判断业务健康。
- 自动切换没有防抖、租约、审批和回退。
- 忽略 DNS TTL、缓存和客户端重试。
- 让双区域同时写入，却没有冲突策略。
- 备用区域没有容量预热，切换后立刻过载。
- 只讨论故障切换，不讨论回切和演练。
- 把 RTO/RPO 当口号，没有映射到复制和成本。
追问及应对
追问一：健康检查误报怎么办？
使用多信号、连续窗口和防抖；业务探针失败时先观察或降级，只有达到规则才切换。
追问二：控制面挂了还能切换吗？
把执行开关和必要查询放在高可用数据面，预先分发安全状态；控制面不可用时限制自动化范围并提供受审计的人工操作。
追问三：两个区域都认为自己是主区域怎么办？
使用租约、围栏令牌或外部仲裁；无法确认单写权时拒绝写入，优先保护数据一致性。
追问四：备用区域容量不足怎么办？
预留容量、分级降级和限流；切换前检查容量，不满足就只承接关键流量或保持原区域。
追问五：为什么不完全自动化？
可逆、证据充分的故障可以自动化；数据损坏、脑裂和低置信度事件需要人工确认，以降低错误切换代价。
追问六：怎样证明演练有效？
记录从检测到恢复的时间、RPO、错误率、容量、人工步骤和回退结果，并把缺口转成有负责人的改进项。