【Linkerd】linkerd2-proxy 数据面：入站、出站与限流感知负载均衡

第 9 篇 把 ServiceProfile 与 destination 合流钉在 L7 轴。第 6 篇 已说明控制面经 destination.Get() / identity CSR 与代理对话。本篇落到 linkerd2-proxy 本身：一次 TCP 连接如何在入站/出站链上被探测、鉴权、路由与选端点。

常见误区有三：把 proxy 当成「另一个 Envoy」去查 Listener/Cluster；把 EWMA 当成可随意换的 round-robin；把 HTTP 429 当成「成功响应」却不理解 2.20 Load Biaser 为何要注入惩罚延迟。排障时数据面症状落在五轴的轴 5——但轴 1–4 未否证前不要先改负载均衡注解。

本篇在系列中的位置

篇目	核心内容
第 9 篇 · ServiceProfile	L7 路由/重试/超时进入 destination
第 10 篇 · linkerd2-proxy 数据面	协议探测、入站/出站链、EWMA 与 2.20 Load Biaser
第 11 篇 · Gateway API 与多集群	GAPI 1.5.1 门与南北向分工
系列目录	全部篇目

版本锚定：Linkerd 2.20（源码 tag version-2.20；公告 2026-06-23）。负载均衡与 Load Biaser 注解以 Load Balancing 参考文档为准。无真实集群则不粘贴伪造 proxy metrics / curl 延迟榜。

一、协议探测

linkerd2-proxy 在 accept 后先做协议探测（protocol detection），决定走 HTTP 语义还是 opaque TCP 直通。这与 Envoy HCM 里显式 filter_chains / codec_type 的配置模型不同：Linkerd 侧更少 CRD→xDS 翻译层，更多在数据面按字节流推断。

探测失败或与应用实际协议不一致时，表象常是「连得上但路由不命中」或「metrics 里没有 route 维度」——先核对端口是否被标为 opaque，而不是先改 ServiceProfile。

学术谱系上，sidecar 内嵌微代理承接 L7 语义，延续 Burns & Beda Designing Distributed Systems 的 sidecar 模式；Linkerd 选择专用 Rust 代理而非通用 Envoy，设计动机见官方 Why Linkerd Doesn’t Use Envoy（B 级叙述，机制仍以 linkerd2-proxy 源码与架构文档为 A 级）。

二、入站/出站处理链

一次 meshed 调用可拆成出站（outbound）与入站（inbound）两条链，均发生在同一 linkerd2-proxy 进程内，但监听与策略求值点不同。

flowchart LR
  app_out["App outbound syscall"]
  ob_proxy["proxy outbound listener"]
  dest_rpc["destination.Get stream"]
  peer_in["peer proxy inbound"]
  ob_proxy --> dest_rpc
  ob_proxy -->|"mTLS"| peer_in
  peer_in --> app_in["App inbound port"]

出站链（本 Pod 发起）：

1. 应用流量经 iptables/CNI 或 native sidecar 重定向进入 proxy 出站监听器（轴 1，第 3 篇）。
2. proxy 向 destination 订阅按目标的 Get() 流，拿到端点列表、identity 提示、策略与 ServiceProfile 派生路由（轴 3–4，第 5–7 篇）。
3. 选定端点后发起 mTLS（轴 2）；HTTP 层应用超时/重试（若 ServiceProfile 或 GAPI 已配置）。

入站链（本 Pod 接收）：

1. 对端 proxy 的 mTLS 连接进入 inbound listener。
2. 策略容器求值结果经 destination 下发：Server / AuthorizationPolicy / MeshTLSAuthentication（第 8 篇）。
3. 通过后转发到应用容器目标端口；入站 metrics 在 2.20 有增强（公告节），本篇不写未核对的指标名列表。

与控制面的分界：proxy 不 watch Kubernetes API；端点与策略陈旧、空流、拒绝等多半落在轴 3–4，而非「proxy 坏了」。502/超时在轴 5 否证前，应先确认 destination 流与 identity 证书（轴 2–3）。

三、负载均衡

出站选端点默认使用 EWMA（exponentially-weighted moving average）：按各后端近期延迟加权，倾向更快实例，并对慢端点降权。官方文档写明：典型部署无需额外调参即可工作。

争论点（工程而非论文排名）：自适应 LB 在尾延迟友好与可预测性之间取舍——EWMA 对慢端点敏感，但在全体端点同时过载时仍可能放大热点；rate-limit 响应因「返回极快」在纯 EWMA 下反而可能吸引更多流量（见下一节官方文档对反馈环的说明）。这是 2.20 引入 Load Biaser 的直接动机，不是未测的「更快百分之几」。

四、2.20 rate-limit-aware LB（机制，非 benchmark）

2.20 起，EWMA 可选配 Load Biaser：当后端用 HTTP 429 或 gRPC RESOURCE_EXHAUSTED 显式表达过载时，proxy 把这些响应视为负载信号，向 EWMA 注入可配置惩罚延迟，并把 Retry-After 等 pushback 提示纳入上界。

启用方式（Service 注解，Load Balancing 文档）：

机制链（不写本站 benchmark）：

1. 未启用时，429/RESOURCE_EXHAUSTED 在 LB 视角仍可能像「快速成功」，EWMA 反而抬高其权重 → 客户端看到限流风暴。
2. 启用后，惩罚项进入 EWMA，流量迁向未限流实例；与熔断/摘除逻辑在 2.20 公告中一并叙述为「限流感知」。
3. 限流可能来自上游 API，也可能来自 Linkerd 自身 rate limit 策略——Biaser 不区分来源，只认响应码语义。

开放问题：惩罚默认值是否应在不同 SLO 下统一；与 ServiceProfile 重试叠加时的风暴行为——需结合 workload 在变更单里写明注解开关，系列第 16 篇回收选型语境。

五、与 Envoy 边界（外链）

不要混读：在 Linkerd 集群里查不到 Envoy 的 cluster warming；在 Istio+Envoy 里也没有 destination.Get() 流。数据面实现对照见 istio-xds/14，本篇不展开 Envoy Filter 全书。

下一篇谈 Gateway API 1.5.1 门与 mesh 路由相对 Envoy Gateway 南北向分工。

参考资料

规范 / 官方文档（A/B）

• Linkerd Architecture — Data plane；Load Balancing（EWMA、Load Biaser 注解）
• Announcing Linkerd 2.20（rate-limit-aware LB、inbound metrics；2026-06-23）
• linkerd/linkerd2-proxy @ version-2.20；linkerd/linkerd2-proxy-api proto
• Why Linkerd Doesn’t Use Envoy（设计边界，B 级）

论文 / 设计谱系

• Burns & Beda, Designing Distributed Systems（sidecar 模式）

本系列

• 第 6 篇 · proxy-api；第 7 篇 · 发现流
• PLAN.md §九·10、§八轴 5

上一篇：ServiceProfile

下一篇：Gateway API 与多集群