【Envoy 数据面】连接池、熔断与 Outlier：路由正确为何仍 503
内容提要
本文探讨Envoy代理中连接池、熔断和异常检测机制如何导致路由正确时仍出现503错误。连接池按线程/协议分池，熔断限额跨Worker共享但最终一致，溢出是503首要嫌疑。异常检测被动摘除异常主机，可与主动健康检查叠加。排障需检查熔断计数、驱逐事件和优先级分流，调参须按优先级独立阈值理解。
延伸解读
连接池并非每集群一个
连接池按线程、协议、传输套接字等维度拆分，例如2线程且同时支持HTTP/1和HTTP/2时，至少存在4个池。这意味着熔断限额虽是跨Worker共享的集群级配置，但池实例是每线程独立的，排障时不能仅看全局连接数，还需理解局部池状态可能不一致。
熔断溢出是503首要嫌疑
当路由配置正确时，若出现503，应优先检查熔断相关计数，如upstream_cx_overflow、upstream_rq_pending_overflow等。熔断限额按集群和优先级独立跟踪，且跨Worker最终一致，可能短暂超过阈值。重试有独立上限，推荐使用retry budget避免自激振荡。
Outlier检测的共享影响
Outlier detection是被动健康检查，根据连续失败、成功率等将主机移出负载均衡集合。共享同一集群的过滤器链会共享驱逐结果，例如HTTP链因5xx驱逐的主机，TCP链也会受影响。排障时应优先查看outlier事件日志，以定位具体主机和检测类型，而非仅依赖全局计数。
调参需按优先级独立理解
熔断和outlier的阈值均按优先级（default/high）独立设置，不能只看集群平均值。熔断过小或outlier过敏可能导致自激振荡或主机被过度驱逐。生产环境应结合优先级分流和事件日志，合理配置阈值，避免系统性503。
Q&A
Envoy 中连接池是如何划分的？为什么不是每个集群只有一个连接池？
Envoy 的连接池不是每个集群一个，而是按多个维度划分：每个 Worker 线程各自维护池；每主机、每协议（如 HTTP/1.1 和 HTTP/2）、以及不同的传输套接字或可哈希且标记共享的 downstream filter state 都可能再拆池。例如，2 线程 ×（HTTP/1 + HTTP/2）支持 → 至少 4 个池。
路由正确但返回 503 时，首先应该检查哪些熔断计数？
首先应检查熔断溢出计数，如 upstream_cx_overflow（连接数超限）、upstream_rq_pending_overflow（等待队列超限）、upstream_rq_retry_overflow（重试超限）等。这些计数上升表明资源配额打满，是路由正确时仍出现 503 的首要嫌疑。
Envoy 的熔断限额是跨 Worker 共享的吗？是否可能超过配置的阈值？
是的，熔断限额是跨 Worker 共享的 cluster 限额，但它是最终一致的，允许竞态短暂超过阈值。因此，实际连接数可能短暂高于配置的最大连接数。
Outlier detection 和主动健康检查有什么区别？它们可以同时使用吗？
Outlier detection 是被动健康检查，根据连续失败、成功率等将主机移出负载均衡集合；主动健康检查是主动探测。两者可以并行使用，且共享同一集群的过滤器链会共享驱逐结果。
在 Envoy 中，如果 gRPC 请求返回非 5xx 错误码，Outlier detection 会如何处理？
默认情况下，Outlier detection 会将 gRPC 状态映射到 HTTP 语义再计入。如果业务使用非 5xx 的 HTTP 码表示失败，需要在 cluster 的 extension_protocol_options 中显式配置 outlier 映射，将匹配的响应报为 5xx，否则被动检测会将其视为成功。
排障时，为什么不能只看全局熔断计数，还要关注 Outlier 事件日志？
全局计数只能说明有驱逐发生，但无法回答哪台主机被驱逐、因为哪种检测类型。Outlier 事件日志（Cluster manager 级配置）能提供具体主机和检测类型，有助于精确定位问题。
调参时，为什么不能只看集群平均值，而必须按优先级分流的独立阈值理解？
因为 Envoy 的熔断和 Outlier 配置是按 cluster × priority 跟踪的，不同优先级（default/high）有独立的连接池和熔断设置。只看集群平均值可能掩盖某个优先级的资源耗尽问题，导致调参不当。
