解读

面试官把“10 倍 RT 突增”作为触发条件，考察的是：

1. 能否在秒级甚至毫秒级发现异常节点；
2. 摘除动作是否对正在处理的请求零损失（流量无损）；
3. 摘除后如何防止抖动、误杀以及后续自愈。

国内互联网生产环境普遍采用微服务 + 容器 + 云原生架构，因此答案必须围绕“注册中心 + 负载均衡 + 熔断/限流 + 可观测性”闭环展开，并给出可落地的参数与验证手段。

知识点

1. 节点异常探测模型
   • 被动探测：依赖客户端记录 RT、错误率，窗口滑动算法（如 Netflix 90% 分位 > 基线 3 倍且持续 3 个桶）。
   • 主动探测：Sidecar 或 Sentinel 发起对 /health、/p99 的探针，10 s 内失败 3 次即标记异常。
2. 摘除机制
   • 注册中心（Nacos 2.x、Consul、Polaris）提供“瞬时摘除”接口，推送版本号增量变更，客户端 200 ms 内完成路由表刷新。
   • 对于无注册中心的纯网关场景，利用 Nginx+Lua 或 Envoy 的 outlier detection，ejection time=30 s，max_ejection_percent=30%。
3. 流量无损
   • 熔断前已建立的长连接：通过“优雅下线”脚本先切走新建流量，再等待 2×maxRT 后关闭连接池。
   • 熔断瞬间的 inflight 请求：利用多路复用（gRPC HTTP/2）的“pending map”机制，重试到同可用区其他节点，重试次数≤2，backoff 20 ms。
4. 数据一致性
   • 摘除决策需分布式锁（基于 Redis RedLock 或 etcd），防止多实例并发修改导致“脑裂”。
   • 记录摘除事件到 MQ，供后续审计与根因分析。
5. 恢复与兜底
   • 节点恢复后先进入“冷启动”权重 10%，RT 连续 5 个周期回归基线 120% 以内再逐步上调到 100%。
   • 若 50% 节点同时被摘除，触发“大促兜底”预案：一键降级非核心接口、扩容 Pod 30%、线程池队列长度翻倍。

答案

生产级方案分四层实现：

1. 感知层 在客户端 SDK（或 Sidecar）内置 SlidingWindowMetric，窗口 1 s，分位线取 P99。当 P99>基线 10 倍且连续 3 个窗口即判定为“慢节点”，同时错误率>5% 作为二次确认，防止网络抖动误报。

2. 决策层 异常事件发送到“故障决策”微服务，由它调用注册中心 OpenAPI 把该实例的 enabled 置为 false，并写入 etcd /unhealthy/{ip:port} 节点，利用 Watch 机制推送到所有订阅者。决策服务本身采用 Raft 三节点部署，保证高可用。

3. 流量层 客户端收到路由变更后，新的建连请求立即剔除异常节点；对已发出的 inflight 请求，SDK 开启“backup request”：在 50 ms 内若未返回则自动重试到同可用区另一节点，超时时间=原超时×0.8，确保用户无感知。对于需要保持会话的 WebSocket，采用“双发单收”策略，客户端同时保持两条链路，优先取先返回的数据包，后返回的包丢弃，实现 0 丢包切换。

4. 恢复层 异常节点被摘除后，运维平台自动触发“线程 dump + GC log”采集，并通知 APM 关联最近 5 min 的变更事件。节点修复后，通过“预热流量”回放 200 QPS 的只读请求，RT 稳定 30 s 再上调权重到 100%，期间若再次触发慢节点条件则立即重新摘除，防止“带病上线”。

通过上述闭环，可在 3 s 内完成异常节点摘除，重试成功率>99.95%，用户侧平均 RT 涨幅<5%，实现真正的“流量无损”。

拓展思考

1. 若慢节点由“冷 JVM”导致，如何与 HPA 弹性伸缩配合？
   可引入“启动探针”+“延迟注册”策略，Pod 启动后先执行 5000 次预热调用，再向注册中心注册，避免新节点一接入就因 JIT 未预热被误摘除。

2. 在 Service Mesh 环境，如何减少 Sidecar 带来的额外 RT？
   采用 eBPF 加速，在 Linux 5.10+ 内核用 sockops 绕过 TCP/IP 协议栈，同节点东西向流量 RT 可下降 0.3 ms，降低 10 倍 RT 误判概率。

3. 如果业务是“写操作”，重试可能导致重复下单，如何做到幂等？
   在协议层加入 Token（订单号 + 业务标识），服务端利用唯一索引或 Redis SETNX 做幂等校验，确保重试流量不会带来脏数据，从而兼顾“流量无损”与“数据一致性”。