Envoy 的“智能诊断师”：被动健康检测如何让服务不再“带病上岗”
在微服务的世界里，一个后端服务的健康状态并不只是简单的“活着”或“死亡”。有时候，一个服务虽然还在运行，但可能因为某个内部 Bug、数据库连接池耗尽，或是偶尔的网络抖动，导致它响应变慢、频繁出错。它就像一个“带病上岗”的员工，虽然没有倒下，但已经无法高效工作，甚至会拖累整个团队。
传统的健康检查（主动健康检查）就像是定期点名：“你还在吗？”。只要服务能回答“在”，它就被视为健康。这种点名式的检查，无法发现那些“带病”的节点。
而 Envoy 的被动健康检测（Outlier Detection）则像是一个“智能诊断师”。它不问“你在吗？”，而是观察你的“工作表现”。它持续监控每个后端节点的实际请求，一旦发现某个节点工作效率低下或错误频出，就会果断地将其暂时隔离。
一、为什么被动检测是必不可少的？
想象一个电商平台的下单服务。当某个节点出现问题，开始返回 503 错误，但由于它没有宕机，主动健康检查依然认为它是健康的。于是，Envoy 继续将一部分宝贵的流量送向这个“问题节点”，导致用户的下单请求失败。
如果这个“问题节点”的错误率达到了一定阈值，被动健康检测就会立即介入。它会像一名果断的医生，将这个节点“隔离”起来，确保后续的流量不再被浪费。它所做的，不仅仅是避免了用户的失望，更是保护了集群中其他健康节点不被这个“病患”所拖累。
二、两种“诊断”模式：连续错误与成功率偏差
Envoy 的被动检测主要依赖两种诊断模式：
- 连续错误诊断：这是最直接的诊断。如果一个节点连续返回了指定数量的 5xx 错误，Envoy 就会认为它不可信，并立刻将其驱逐。这就像是发现了一个员工连续犯了多次同样的严重错误，无需再观察，直接请他休息。
- 配置示例：
consecutive_5xx: 5，意味着连续 5 个 5xx 错误就会触发驱逐。
- 配置示例：
- 成功率偏差诊断：这是一种更高级、更智能的诊断。Envoy 会实时计算整个集群的平均成功率，然后用成功率标准差因子来衡量每个节点的表现是否异常。
这个标准差因子是理解被动检测精髓的关键。它代表着 Envoy 在“容忍”和“严格”之间做出的权衡。
- 如果因子值较低（例如，100，即1倍标准差）：Envoy 会变得非常敏感。只要某个节点的成功率比集群平均水平低了一点点，就可能被视为异常。这适用于对稳定性有极高要求、不允许任何性能偏差的场景。
- 如果因子值较高（例如，200，即2倍标准差）：Envoy 会变得更加“宽容”。它会容忍更大的成功率波动，只有当一个节点的表现显著低于平均水平时，才会被驱逐。这适用于流量不稳定或偶尔会有小幅波动的服务。
通过调整这个因子，你就像是给 Envoy 的“智能诊断师”设置了不同的“性格”：严厉还是宽容，从而使其行为完全符合你的业务预期。
三、被动与主动：完美的“黄金搭档”
被动健康检测并非要取代主动健康检查。事实上，它们是互补的**“黄金搭档”**。
- 主动健康检查：用于处理最简单、最粗暴的故障——服务宕机。它能快速发现并移除那些已经“死亡”的节点。
- 被动健康检测：用于处理更复杂、更隐蔽的故障——服务“带病”。它能智能地识别和隔离那些还在运行但性能下降的节点。
两者结合，形成了完整的、多层次的健康保障体系。Envoy 能够迅速响应各种故障类型，无论是简单的宕机，还是复杂的性能退化，确保你的服务始终保持高可用、高稳定的状态。
四、关键配置项与工作流程
以下是被动健康检测的一些重要配置项及其作用：
- consecutive_5xx: 节点在被驱逐前，需要连续出现 5xx 错误的次数。
- consecutive_gateway_failure: 节点在被驱逐前，需要连续出现网关错误（如 502/503/504）的次数。
- interval: Envoy 运行异常检测算法的时间间隔，通常建议设置为秒级。
- base_ejection_time: 节点被驱逐后的基础隔离时间。
- max_ejection_percent: 在任何时间点，最多可以被驱逐的节点百分比。这个参数用于防止大规模的节点故障。
除了基于连续错误的驱逐，Envoy 还支持基于成功率的更精细的驱逐策略：
- enforcing_success_rate: 一个 0-100 的权重值，用于控制成功率驱逐机制的执行强度。
0表示禁用，100表示完全启用。 - success_rate_minimum_hosts: 开启成功率驱逐前，集群中需要最少健康主机数。
- success_rate_request_volume: 节点在被计算成功率前，需要最少处理的请求数。
- success_rate_stdev_factor: 成功率标准差因子，这个参数是成功率驱逐的核心。
评论区