4. Envoy 连接池机制详解：HTTP/1.1 连接池、HTTP/2 连接池、连接池大小与并发控制参数

在服务目录平台冷启动削峰场景中，Envoy 作为数据面代理，其连接池机制直接决定了上游服务实例的负载压力与请求成功率。Envoy 为每个上游集群维护独立的连接池，根据协议类型（HTTP/1.1 或 HTTP/2）采用不同的复用策略。理解连接池的内部结构与关键参数，是精准控制削峰行为的前提。

4.1 HTTP/1.1 连接池：短连接复用与请求排队

HTTP/1.1 协议本身支持 Keep-Alive 长连接，但每个连接在同一时刻只能处理一个请求（串行）。Envoy 的 HTTP/1.1 连接池采用 “连接复用 + 请求排队” 模型：

• 空闲连接复用：请求到达时，优先从空闲连接列表获取可用连接。
• 连接饥饿等待：若无空闲连接且未达到最大连接数，则创建新连接。
• 请求排队：若连接数已达上限且所有连接均繁忙，请求进入等待队列。
• 连接回收：请求完成后，连接归还至空闲池，供后续请求复用。

4.2 HTTP/2 连接池：多路复用与流控

HTTP/2 引入多路复用（Multiplexing），单个连接可承载多个并发的请求流（Stream）。Envoy 的 HTTP/2 连接池模型与 HTTP/1.1 有本质区别：

• 单连接多流：默认情况下，Envoy 为每个上游主机只建立 1 个 HTTP/2 连接，所有请求通过该连接的多个 Stream 并发发送。
• 流级别并发控制：通过 max_concurrent_streams 参数限制单个连接上的最大并发 Stream 数。
• 连接级流控：HTTP/2 协议层自带流量控制（Flow Control），Envoy 可配置初始窗口大小。
• 多连接扩展：当单连接 Stream 数达到上限时，Envoy 可创建额外的 HTTP/2 连接（受 max_connections 限制）。

4.3 连接池大小与并发控制参数

Envoy 通过 Cluster 配置中的 circuit_breakers 和 max_requests_per_connection 等字段，精细控制连接池行为。以下是与冷启动削峰最相关的核心参数：

4.4 连接池参数配置实战示例

以下是一个针对服务目录平台冷启动削峰场景的 Envoy 连接池配置片段：

static_resources:
  clusters:
  - name: service_catalog_cluster
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    # HTTP/2 协议配置
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http2_protocol_options:
            max_concurrent_streams: 200
            initial_stream_window_size: 65536
            initial_connection_window_size: 1048576
    # 熔断器（连接池控制）
    circuit_breakers:
      thresholds:
      - priority: DEFAULT
        max_connections: 200
        max_pending_requests: 400
        max_requests: 1000
        max_retries: 3
      - priority: HIGH
        max_connections: 400
        max_pending_requests: 800
        max_requests: 2000
        max_retries: 5
    # 连接生命周期
    max_requests_per_connection: 500
    close_connections_on_host_health_failure: true

4.5 冷启动削峰连接池调优建议

• 优先使用 HTTP/2：利用多路复用减少连接数，降低上游连接建立开销。
• 设置合理的 max_concurrent_streams：根据上游处理能力调整，避免单连接流数过多导致上游负载不均。
• 控制排队深度：max_pending_requests 建议为 max_connections 的 1~2 倍，防止内存溢出。
• 启用优先级熔断：为 HIGH 优先级设置更大的连接池配额，保障关键请求通过。
• 监控连接池指标：关注 upstream_cx_active、upstream_rq_pending_active、upstream_cx_overflow 等指标，动态调整参数。