【Linkerd】linkerd2-proxy 数据面：入站、出站与限流感知负载均衡
内容提要
本文介绍Linkerd 2.20数据面linkerd2-proxy的机制：协议探测区分HTTP与opaque TCP；入站/出站处理链经destination流获取端点与策略；负载均衡默认用EWMA，2.20新增Load Biaser，通过HTTP 429或gRPC RESOURCE_EXHAUSTED信号注入惩罚延迟，避免限流风暴。排障需先查控制面轴1-4，勿混读Envoy模型。
延伸解读
协议探测：先看端口是否 opaque
协议探测是数据面处理的第一步，它决定流量走 HTTP 语义还是 opaque TCP 直通。当出现“连得上但路由不命中”或“metrics 里没有 route 维度”时，应优先核对端口是否被标记为 opaque，而不是急于修改 ServiceProfile。这一排查顺序能避免在错误层面浪费时间。
EWMA 的局限与 Load Biaser 的动机
EWMA 默认按延迟加权，对慢端点敏感，但在所有端点同时过载时可能放大热点。更关键的是，限流响应（如 HTTP 429）返回极快，在纯 EWMA 下反而可能吸引更多流量，形成反馈环。这正是 2.20 引入 Load Biaser 的原因：通过注入惩罚延迟，将限流信号纳入负载均衡决策，避免限流风暴。
排障时先查控制面，再动负载均衡
数据面症状（如 502、超时）可能源于控制面问题，例如 destination 流陈旧、策略下发失败或 identity 证书异常。在修改负载均衡注解之前，应先确认轴 1–4 是否正常，否则可能掩盖真正的问题。proxy 不直接 watch Kubernetes API，端点或策略异常多半不在数据面本身。
Q&A
Linkerd 2.20 的 linkerd2-proxy 如何区分 HTTP 和 opaque TCP 流量？
linkerd2-proxy 在 accept 后先进行协议探测，根据字节流推断是 HTTP/1.x、HTTP/2 还是非 HTTP 的 opaque TCP。HTTP 流量会解析 :authority/Host、方法、路径，并可走 ServiceProfile 或 Gateway API 路由；opaque TCP 则按 Service 端口和 opaquePorts 配置直通或受限转发。
Linkerd 数据面入站和出站处理链分别是什么？
出站链：应用流量经 iptables/CNI 或 native sidecar 重定向进入 proxy 出站监听器，proxy 向 destination 订阅 Get() 流获取端点、策略和路由，选定端点后发起 mTLS，并应用超时/重试。入站链：对端 proxy 的 mTLS 连接进入 inbound listener，策略容器求值结果经 destination 下发，通过后转发到应用容器目标端口。
Linkerd 默认的负载均衡算法是什么？它有什么特点？
Linkerd 默认使用 EWMA（指数加权移动平均）负载均衡算法。它根据各后端近期延迟加权，倾向更快实例，并对慢端点降权，不是严格的 round-robin。典型部署无需额外调参即可工作。
Linkerd 2.20 的 Load Biaser 是什么？它如何工作？
Load Biaser 是 Linkerd 2.20 引入的可选功能，用于感知后端限流信号。当后端返回 HTTP 429 或 gRPC RESOURCE_EXHAUSTED 时，proxy 将这些响应视为负载信号，向 EWMA 注入可配置的惩罚延迟，并将 Retry-After 提示纳入上界，从而将流量迁移到未限流实例，避免限流风暴。
如何启用 Linkerd 2.20 的 Load Biaser？相关注解有哪些？
通过 Service 注解启用：balancer.alpha.linkerd.io/penalize-failures 设为 true（默认 false）；balancer.alpha.linkerd.io/load-biaser-penalty 设置惩罚延迟（默认 5s）；balancer.alpha.linkerd.io/load-biaser-max-retry-after 设置接受的 Retry-After 上限（默认 300s）。
Linkerd 数据面排障时，为什么不能先改负载均衡注解？
因为数据面症状可能由控制面问题引起，排障时应先检查控制面轴 1-4（注入、identity、destination、策略），在未否证这些轴之前，不要先修改负载均衡注解。否则可能掩盖真正的问题。
linkerd2-proxy 与 Envoy 在配置来源和扩展模型上有何不同？
linkerd2-proxy 使用 destination/identity 专用 gRPC API 获取配置，而 Envoy 使用 xDS（LDS/CDS/EDS/RDS/SDS）。扩展模型上，linkerd2-proxy 是 Rust 内建栈，不支持 Wasm/HTTP filter 生态；Envoy 则通过 Filter chain / HCM / network filter 组合扩展。
