摘除决定流量去哪
负载均衡的健康检查决定后端是否继续接流量。摘除有两条路径：主动健康检查发现失败即摘除，被动观察真实请求的错误率与超时再摘除。摘除过快会把偶发失败放大成容量损失，过慢则让用户持续打到故障实例，联动参数就是在两者之间取值。
基本信息
| 主动检查 | 负载均衡按固定间隔探测后端，连续失败后摘除 |
|---|---|
| 被动检查 | 按真实请求的错误率或超时比例摘除 |
| 恢复条件 | 连续若干次成功后才重新放回流量 |
| 摘除粒度 | 实例级、可用区级、区域级效果差异明显 |
| 连带风险 | 摘除后剩余实例承压上升，可能触发连锁摘除 |
典型使用场景
- 滚动发布：新实例未就绪不接流量，旧实例先停止接收新请求再摘除
- 慢节点隔离：某实例响应明显慢于同组基线，通过被动检查降权
- 依赖故障：共享依赖不可用时不应全部摘除，需保留最小可用集合
- 区域容灾：按区域粒度摘除，单实例摘除在大的故障域内没有意义
- 恢复验证：放回流量前确认实例通过完整检查，而不是仅端口可达
摘除策略对照
| 策略 | 触发依据 | 适用与副作用 |
|---|---|---|
| 主动摘除 | 探测失败达阈值 | 发现快，误报直接减少容量 |
| 被动摘除 | 真实请求错误率或超时 | 贴近用户体验，反应略滞后 |
| 权重下调 | 延迟高于同组基线 | 缓释而非硬切，需持续观测 |
| 慢启动 | 新实例逐步加权 | 避免冷实例被瞬间打满 |
主动与被动检查搭配
主动与被动检查搭配
# 主动检查：inter 探测间隔、fall 连续失败次数、rise 连续成功次数
# backend app
# option httpchk GET /healthz
# default-server inter 2s fall 3 rise 2 slowstart 30s
# 被动检查：观察真实请求结果，作为主动检查的补充
# observe layer7
# 主动负责快速发现，被动负责贴近真实体验，两者互补而非替代
# 具体参数名称与默认值以所用负载均衡组件的官方文档为准摘除参数要与容量规划联动：一组后端只剩少量实例仍要承接全量流量时，剩余实例会因过载而相继失败，形成连锁摘除。关键服务应定义不可摘除的最小实例数或明确的降级策略。
主动检查若与被检服务共用同一入口，限流、鉴权或缓存异常都会导致整体实例同时被判失败，触发整组摘除。检查入口应独立于业务限流与鉴权链路。