高可用架构设计 · 面试问答框架
高可用架构模式对比
| 模式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 主从集群 | 实现简单，部署成本低 | 主节点切换有短暂中断，存在脑裂风险 | 非核心服务，允许分钟级故障恢复 |
| 对等（无状态）集群 | 无单点，高可用性好，水平扩展强 | 依赖外部注册中心（Consul/Etcd）进行协调 | 核心业务，要求秒级自愈 |
| 异地多活 | 极致容灾能力，实现用户就近接入 | 架构复杂，数据一致性保证困难，成本高 | 大型互联网 P0 级核心业务 |
健康检查与自动摘除流程
- 探测： 定时发送健康检查请求（TCP/HTTP/gRPC）。
- 判定： 统计连续失败次数或错误比例。
- 摘除： 超过阈值，从注册中心或负载均衡池中标记下线。
- 熔断： 触发熔断器，快速失败，停止对该节点的请求。
- 恢复： 探测节点恢复后，通过慢启动/低权重策略重新加入。
1. 集群部署
面试问题：请介绍一下API网关的集群部署方案，以及如何避免脑裂问题？
面试官考察点：
- 分布式系统基础（CAP理论、一致性协议）
- 实际集群部署与配置经验
- 对脑裂问题的理解与应对策略
回答框架：架构模式（主备/Paxos/Raft） → 注册中心协调（Consul/Etcd） → 节点无状态化 → 防脑裂设计（Quorum/选举）
简短示例回答：我们采用了Nginx+Gateway集群，基于Consul进行服务发现与健康检查。通过Raft协议确保配置一致性，避免脑裂。所有节点无状态化，流量通过SLB均匀分发，单节点故障秒级摘除。
可能追问：集群节点配置不一致时如何处理？集群扩缩容时的流量迁移策略是什么？
2. 多活方案
面试问题：如何设计API网关的异地多活方案？会面临哪些数据一致性挑战？
面试官考察点：
- 容灾架构设计能力
- 数据复制与同步技术
- 流量调度与灰度能力
回答框架：架构模式（同城/两地三中心/单元化） → 流量接入（DNS/GSLB） → 数据同步（MQ/DRC） → 一致性保障（最终一致性/幂等）
简短示例回答：方案采用“两地三中心”基架，DNS智能解析实现流量就近接入。网关层无状态，依赖单元化分片保证数据隔离，通过MQ保证最终一致性。核心在于业务设计支持幂等与对冲。
可能追问：多活切换的自动容灾策略和回滚方案是什么？如何防止故障时流量滚雪球？
3. 健康检查与自动摘除
面试问题：API网关如何对后端节点进行健康检查与自动摘除？设计关键点有哪些？
面试官考察点：
- 探活机制与故障隔离设计
- 优雅启停流程
- 应对抖动的防御性编程思想
回答框架：探活方式（主动HTTP/被动心跳） → 摘除策略（熔断、连续失败阈值） → 优雅下线（等待请求完成） → 恢复策略（慢启动预热）
简短示例回答：采用主动健康检查+被动监听心跳结合。连续3次失败则标记为摘除状态并熔断。摘除前等待10s保证请求处理完毕，恢复后采用低权重慢启动初始接入流量。
可能追问：健康检查抖动如何处理（亚健康/半开状态）？摘除节点的流量如何不丢失？
项目案例 · 统一API网关高可用架构升级
项目名称：统一API网关高可用架构升级项目
业务背景：原单机房架构因机房故障导致全站不可用，需构建多活高可用网关层。
规模指标：峰值QPS 100W+，节点数 50+，日处理请求 80亿+。
技术栈：OpenResty + Lua / Kong, Consul, Kubernetes, Prometheus, Kafka, Aliyun SLB/DNS。
核心难点：
- 多机房流量实时调度与数据最终同步。
- 秒级故障自动探测与无感摘除。
- 全链路压测与精准容量评估。
面试高频追问：
- 项目最终实现的RTO和RPO是多少？（期望：RTO < 30s, RPO ≈ 0）
- 灰度发布或蓝绿部署如何与网关层配合？（通过网关流量权重进行无缝切换）
- 如何避免健康检查风暴导致雪崩？（使用慢启动、分桶检查、异常值检测）