題幹與適用場景
設計一個协调器，持续判断多個區域的健康狀態，在满足条件時切換流量到备用區域，並在恢復後安全回切。說明控制面與資料面的边界、健康信号、切換保护、資料狀態、人工审批、审计和演练方式。
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、错误率、容量、人工步骤和回退结果，並把缺口转成有负责人的改进项。