探活与摘除怎么配合
上游探活有两种机制配合使用：被动摘除按真实请求的失败计数把异常实例暂时移出，主动探针定期请求轻量端点确认实例还活着。探针端点要选不触发推理的路径，否则探针本身就会变成额外的负载来源。
基本信息
| 适用平台 | 网关与推理服务实例 |
|---|---|
| 被动机制 | 按失败次数与失败窗口临时摘除 |
| 主动机制 | 定期请求轻量探针端点 |
| 端点选择 | 健康检查类路径，避免触发推理 |
被动摘除片段
被动摘除片段
upstream llm {
server 127.0.0.1:8000 max_fails=3 fail_timeout=30s;
server 127.0.0.1:8001 max_fails=3 fail_timeout=30s;
}典型使用场景
- 实例异常：连续失败后自动摘除，减少错误暴露
- 后端扩容：新实例通过探针后才接入流量
- 滚动重启：靠探针判断实例是否已经就绪
- 容量核对：摘除之后剩余容量是否足够，要一起看
- 来源限制：探针端点加鉴权或限制来源，避免成为公网可探测的接口
机制与注意点
| 机制 | 触发条件 | 注意 |
|---|---|---|
| 被动摘除 | 真实请求连续失败 | 失败计数窗口不要设得太短 |
| 主动探针 | 按固定间隔请求轻量端点 | 间隔要在及时性与额外负载之间平衡 |
| 就绪判断 | 实例启动完成可接流量 | 存活与就绪是两个不同概念 |
开源网关的主动健康检查能力有限：需要时可引入外部探活组件或应用网关替代。
区分存活与就绪：进程活着不代表模型已加载完成，探针要能反映是否真能接流量。
摘除之后要能自动恢复：只摘不还就得靠人工介入，恢复条件需要明确写下来。
摘除与排空要分开：摘除只是不再分新流量，已在处理的长请求仍占着连接，排空需要另外安排。
探活结果也值得记录：把失败次数与恢复时间做进监控，才能发现实例在反复抖动。