图 1：本文封面——一台网关故障时，流量自动绕向健康实例。
先说明属性：这是一篇经典题解析，题目出自本地历史面试资料（见文末来源说明），与任何公司的当前招聘无关。API 网关是所有流量的总入口，「网关挂了怎么办」考的不是某个组件，而是你对「总入口必然单点」这件事的系统化解法。
想象面试现场，面试官问：「你们的系统所有请求都经过一个网关，这个网关本身怎么保证高可用？」
第一步，审题：把问题拆成两个。
「网关挂了怎么办」其实是两个问题：一是单台网关实例挂了，流量怎么自动绕开；二是网关这个环节整体如何避免成为瓶颈与单点。第一问的答案是冗余加故障转移，第二问的答案是「网关自己也要按高并发系统来设计」。两问都答到，才算完整。
第二步，基础回答：冗余加故障转移。
核心思路一句话：网关无状态，多实例部署，挂在负载均衡后面，健康检查自动摘除故障实例。
无状态是前提。网关的会话、配置、路由规则全部外置到配置中心或存储里，任何实例不保存只属于它的数据。无状态的实例才能随便加、随便切——这台挂了，请求落到任何一台上都一样正确。
故障转移靠健康检查。负载均衡器对每台网关实例定期发探测请求，连续若干次失败就把实例摘出流量池，恢复后再放回来。以 AWS 应用负载均衡器的官方文档为例：默认每 30 秒对每个目标做一次健康检查，连续 2 次失败即判定为不健康并停止路由，连续 5 次成功才重新纳入。整个过程秒级到分钟级自动完成，不需要人半夜上线。还有一个值得知道的细节：当池子里所有目标都不健康时，负载均衡器会「失败开放」（fail-open），把请求发给全部目标——宁可发给可能坏了的，也不全体拒答。
第三步，别忘了入口本身也要冗余。
把负载均衡器架在网关前面，那负载均衡器挂了怎么办？这是「总入口」问题的递归。标准做法是虚拟 IP 加主备漂移：两台负载均衡器共享一个 VIP，平时主机持有，心跳发现主机宕机后备机接管 VIP，流量几乎无感。再往上，DNS 层可以把域名解析到多个入口地址，跨机房部署时按地域分流。每一层的答案都一样：无状态、冗余、健康检查。
图 2：入口层、网关层、后端层的三层冗余与三条设计原则。
第四步，网关自己不能是瓶颈。
高可用不只是「挂了能切」，还包括「别让流量把它打挂」。所有请求都挤进网关，意味着网关的容量就是系统的容量上限。所以网关自身要压测——知道单机极限在哪，按峰值流量留出冗余实例数；还要限流——超出承受能力的请求在入口快速拒绝，保住池子里的健康实例。把一个会过载的组件做成集群，得到的只是一个会集体过载的集群。
第五步，可能的追问。
「健康检查多久发现一次故障？」取决于间隔与失败阈值的乘积，这个乘积就是故障转移的时延下限，配置时要按业务能容忍的中断时长倒推。「摘除故障实例期间容量够吗？」冗余设计要按「N 减一」甚至「N 减二」规划——任意一台被摘除，剩下的实例仍要扛住全部流量，否则故障转移的瞬间就是雪崩的开始。「会话亲和怎么办？」让网关无状态化就是为了消灭这个需求；真有黏性诉求，也应由负载均衡层的哈希策略解决，而不是把状态塞进网关。
易错点清单。
一，只答「部署多台」，讲不出无状态这个前提——有状态的实例多部署几台，故障转移时照样丢会话。二，忽略健康检查的参数语义——间隔、失败阈值、恢复阈值共同决定摘除有多快、抖动时会不会误杀。三，解决了网关层的冗余，却没解决负载均衡器自身的单点，递归断了一层。四，只谈「挂了怎么办」，不谈「怎么不被打挂」，容量与限流缺位。
回到面试现场，建议的答题节奏：先给一句话主线（无状态、冗余、健康检查三件套），再展开入口层与网关层各自的冗余方案，然后补健康检查的参数语义，最后落到压测与限流。这套结构对任何「总入口」组件都成立——消息队列、调度器、认证服务，都是同一个答案的变体。
AI 应用的模型路由、鉴权、限流都收敛在网关层，网关的 SLA 就是产品的 SLA。你维护的网关上，最值钱的一条高可用措施是什么？欢迎分享。
参考资料
- Health checks for Application Load Balancer target groups（AWS 官方文档：负载均衡器按间隔对目标做健康检查，连续失败达阈值即停止路由、连续成功达阈值恢复，全部目标不健康时失败开放） — https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html