Linkerd2-proxy 深度实战：从 Tower Service 抽象、P2C + Peak EWMA 负载均衡到重试预算与协议探测的服务网格数据面工程全解

Linkerd2-proxy 深度实战：从 Tower Service 抽象、P2C + Peak EWMA 负载均衡到重试预算与协议探测的服务网格数据面工程全解

谈起服务网格数据面，多数人的第一反应是 Envoy 的过滤器链与 xDS。但 Linkerd 走出了一条完全不同的路：它的数据面 linkerd2-proxy 是一个用 Rust 写的单体代理，核心不是"可插拔过滤器"，而是 Tower 中间件栈的编译期组合。理解这条技术路线，你会重新认识"代理"这件事——它不是配置的堆叠，而是类型系统的表达。

一、Tower：把中间件编译成类型

Tower 的全部魔法浓缩在两个 trait 里。Service 描述"能处理一个请求的东西"，Layer 描述"把一个 Service 变成另一个 Service 的东西"：

pub trait Service<Request> {
    type Response;
    type Error;
    type Future: Future<Output = Result<Self::Response, Self::Error>>;
    // 背压入口：调用方必须先 poll_ready，才能 call
    fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>>;
    fn call(&mut self, req: Request) -> Self::Future;
}

pub trait Layer<S> {
    type Service;
    fn layer(&self, inner: S) -> Self::Service;
}

poll_ready 是 Tower 与绝大多数中间件框架的分水岭。它把"我还能不能接一个请求"变成了可轮询的一等公民，于是背压不再是"队列无限增长 + 超时兜底"，而是一路从连接池 → 限流器 → 负载均衡器 → 客户端逐层反压回去。链路中任意一环满了，最外层立刻感知，请求在进入系统之前就被拒绝或降级，而不是在内部堆积到 OOM。

写一个自己的中间件因此变得极其规整。下面是一个生产里真会用到的"按端点并发闸门 + 指标"层：

use std::task::{Context, Poll};
use tower::{Layer, Service};

#[derive(Clone)]
pub struct Gate<S> { inner: S, sem: Arc<Semaphore>, inflight: Gauge }

impl<R, S: Service<R>> Service<R> for Gate<S> {
    type Response = S::Response;
    type Error = S::Error;
    type Future = S::Future;

    fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>> {
        // 先向下游问背压，再问自己的闸门；顺序错了会漏掉下游的错误
        futures::ready!(self.inner.poll_ready(cx))?;
        match self.sem.clone().acquire_owned().poll_unpin(cx) {
            Poll::Ready(Ok(_)) => Poll::Ready(Ok(())),
            Poll::Pending => Poll::Pending,
            Poll::Ready(Err(_)) => Poll::Ready(Ok(())), // 闸门关闭时的降级策略
        }
    }

    fn call(&mut self, req: R) -> Self::Future {
        self.inflight.inc();
        self.inner.call(req)
    }
}

关键在于：这个 Gate 是零成本抽象。编译期单态化之后，Gate<Balance<PeakEwma<Pool<Client>>>> 就是一段被完全内联的直线代码，没有虚表、没有堆分配、没有运行时的"过滤器链遍历"。Linkerd 的整个代理就是一个巨大的嵌套类型，由 linkerd-stack 的 svc::stack(inner).push(...) 显式拼装。

二、负载均衡：P2C 与 Peak EWMA 的组合拳

代理的核心价值之一是"把请求发给正确的那个 Pod"。轮询（Round-Robin）在真实集群里几乎是错误的选择：实例规格不同、混部下的邻居噪声不同、GC 停顿不同，轮询会让你把流量均匀倒进一个正在 Full GC 的 JVM 里。

Linkerd 的做法是 Power of Two Choices（P2C）+ Peak EWMA：

• P2C：随机挑两个候选端点，取负载更低者。复杂度 O(1)，不需要全局扫描，且在数学上已证明能把最大负载从 O(log n / log log n) 降到 O(log log n)——相比轮询这是数量级的改善。
• Peak EWMA：端点负载 = RTT 的指数加权移动平均，且取"峰值"——即 max(ewma, 最近一次 RTT)。为什么要取峰值？因为纯 EWMA 是平滑的，一个刚刚从 5ms 劣化到 500ms 的端点，其 EWMA 要爬升好几秒才会被"看见"；取峰值后，一次坏响应时间就能立刻把它从候选里踢出去。衰减窗口（Tower 默认 10 秒量级）决定记忆长度，Linkerd 会按集群规模拉长以避免在窗口边界抖动。

use tower::balance::p2c::Balance;
use tower::load::{PeakEwma, PendingRequests, Load};

type Endpoint<S> = PendingRequests<PeakEwma<S>>;
// 组合负载指标：在途请求数 + 峰值延迟，两者互补
// - PendingRequests 对"慢但未返回"的请求敏感
// - PeakEwma 对"刚刚变慢"的请求敏感
let svc = Balance::new(stream_of_endpoint_updates);

仅用 PendingRequests 会偏向把流量全给响应快但吞吐差的实例；仅用 PeakEwma 则在突发流量下会集体踩踏同一个"看起来最快"的实例。二者相加才是工程上可用的形态。

一个常被忽略的细节：健康检查不等于负载均衡。k8s readiness 探针是秒级粒度的离散信号，Peak EWMA 是毫秒级连续信号。前者决定"能不能收",后者决定"该收多少"。把两者混为一谈，是所有"网格装上了但 P99 没改善"案例的共同病因。

三、重试预算：为什么"最多重试 3 次"是错的

传统配置是"最多重试 N 次"。这个模型在依赖抖动时是灾难：假设下游成功率掉到 50%，客户端全量重试 3 次，打到下游的请求量瞬间翻 4 倍——重试风暴，把一次局部故障放大成雪崩。

Linkerd 用重试预算（retry budget）从根本上改变单位：预算约束的不是"每个请求重试几次"，而是"重试量占正常流量的比例"。

# ServiceProfile
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: checkout.prod.svc.cluster.local
spec:
  retryBudget:
    retryRatio: 0.2        # 重试最多占正常流量的 20%
    minRetriesPerSecond: 10 # 低流量时的地板值，避免小 QPS 服务被饿死
    ttl: 10s               # 预算统计窗口
  routes:
    - name: POST /api/order
      condition:
        method: POST
        pathRegex: /api/order
      isRetryable: true

语义非常清晰：无论下游多烂，你最多额外制造 20% 的放大。minRetriesPerSecond 是关键补丁——纯比例模型在 QPS=2 的服务上会算出 0.4 次/秒，等于完全禁用重试，所以必须给一个地板值。这是"理论正确"与"工程可用"之间那道缝。

同时必须记住：只有幂等请求才可重试。给 POST /api/order 开重试前，务必确认服务端有幂等键（Idempotency-Key）。我见过的最惨事故，是一个未做幂等的支付接口被重试预算放大，产出了重复扣款——网格不会替你判断业务语义。

四、协议探测：同一个端口上的三种世界

Linkerd 的透明代理要求不改应用代码，于是它必须在不知道协议的前提下接管流量。这套机制分三步：

第一步，用 iptables 把流量劫持到代理。 linkerd-init 初始化容器写入 NAT 规则（或由 CNI 插件集中完成）：

# 出站：所有到 ClusterIP 的 TCP 重定向到 4140（出站代理）
iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-port 4140
# 入站：到 Pod 自身 80/8080 的流量重定向到 4143（入站代理）
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 4143

第二步，还原原始目的地。 REDIRECT 改写了目标地址，代理必须通过 SO_ORIGINAL_DST 把原始 dst 拿回来，否则无法做服务发现和路由：

fn original_dst(sock: &TcpStream) -> std::io::Result<SocketAddr> {
    let addr = system::orig_dst_sockaddr(&sock)?;
    Ok(addr.as_socket().expect("must be an IP address"))
}

第三步，嗅探前 8 个字节判别协议。 这是最精巧的一步：

// 0x16 0x03 0x0X → TLS ClientHello（再取 SNI 判断是否为网格内 mTLS）
// "PRI "          → HTTP/2 明文连接前导
// GET/POST/PUT... → HTTP/1.1
const BUFFER_CAPACITY: usize = 8;

探测结果决定后续栈的拼装分支：是走 linkerd-proxy-identity 终止网格 mTLS，还是透传普通 TLS，还是当作纯 TCP 只做转发。若是网格内 mTLS，代理还会注入 l5d-orig-proto 头，让下游知道原始协议——这样应用即便只监听明文 HTTP，也仍能拿到"调用方用的是 HTTP/2"这类元信息。

工程代价必须说清楚：探测需要缓冲首包，会引入一次额外的读；更麻烦的是"探测超时"——某些长连接协议首包迟迟不来，探测会卡住直到超时。生产上应显式配置 detect 超时（默认 10 秒偏长），对 gRPC 之外的自定义 TCP 协议建议直接用 opaque ports 标注跳过探测，避免把非 HTTP 流量误判。

五、生产调优清单

六、我的判断

Envoy 与 Linkerd 代表了两种工程哲学：前者是"配置驱动的可扩展性"，后者是"类型驱动的正确性"。如果你需要大量自定义协议和复杂的 L7 逻辑，Envoy 的过滤器链无可替代；但如果你要的是一个不会写错的、资源占用低的、默认就正确的代理，Tower 那条路更值得信任——背压、超时、重试预算这些"容易配错"的东西，在 Rust 的类型系统里变成了"不实现就编译不过"。

服务网格的热度已过峰值，但数据面技术的价值没有衰减：Ambient Mesh、ztunnel、eBPF 加速的透明拦截，本质上都在回答同一个问题——如何以最小侵入获得最强的流量治理能力。读懂 Linkerd2-proxy 的栈，你得到的不是某个产品的用法，而是一套可以迁移到任何代理上的设计方法论。