2. Docker 网络基础：Bridge、Host、Overlay 网络模式原理，容器间通信对连接池的影响

2.1 Docker 网络模型概述

Docker 容器网络是连接池与分布式事务调优的底层基础设施。容器间的通信延迟、带宽、连接数限制直接影响连接池的水位计算与事务超时策略。Docker 提供三种核心网络模式：Bridge、Host、Overlay，每种模式在隔离性、性能、跨主机通信能力上存在显著差异。

调优视角：连接池的 maxActive、maxWait 参数必须与容器网络模式的吞吐能力对齐。例如，Bridge 模式下的 NAT 转发会增加连接建立延迟，Host 模式则消除该开销但牺牲端口隔离。

2.2 Bridge 网络模式

Bridge 是 Docker 默认的网络模式。每个容器通过虚拟网卡（veth pair）连接到宿主机上的 docker0 网桥，容器间通过网桥转发通信，外部访问需通过端口映射（DNAT）。

核心特性

  • 隔离性：每个容器拥有独立网络命名空间，IP 地址由 Docker 内部 DHCP 分配（通常为 172.17.0.0/16 段）。
  • 通信方式：同宿主机容器可通过 IP 直接通信；跨宿主机需借助端口映射或额外路由。
  • 性能开销：数据包经过 veth pair → docker0 网桥 → iptables NAT 规则，存在 5-10% 的吞吐损失和微秒级延迟增加。
连接池影响：Bridge 模式下，连接池每次创建新连接需经过 NAT 转换，连接建立时间（TCP 握手 + NAT 表项创建）比 Host 模式多约 0.5-2ms。对于高频短连接场景（如 HTTP 健康检查、事务补偿请求），建议适当增大 maxWait 或启用连接池的 testOnBorrow 预检机制。

2.3 Host 网络模式

Host 模式让容器直接共享宿主机的网络栈，容器不拥有独立网络命名空间，直接使用宿主机 IP 和端口。

核心特性

  • 零 NAT 开销：数据包直接通过宿主机网卡收发，无虚拟网桥和 iptables 转发。
  • 端口冲突风险：容器内应用端口直接占用宿主机端口，无法同时运行两个相同端口的容器。
  • 性能最优：网络吞吐接近原生，延迟最低，适合对网络性能敏感的场景（如数据库连接池、消息队列生产者）。
避坑提示：Host 模式下，连接池的 maxActive 受宿主机 net.ipv4.ip_local_port_range 限制（默认 32768-60999）。若连接池水位过高，可能耗尽本地端口，导致 Cannot assign requested address 错误。建议调大端口范围或使用 tcp_tw_reuse 加速 TIME_WAIT 回收。

2.4 Overlay 网络模式

Overlay 网络用于跨宿主机容器通信，是 Docker Swarm 和 Kubernetes 的默认网络方案。它通过 VXLAN 隧道封装数据包，在宿主机之间建立二层网络。

核心特性

  • 跨主机透明通信：容器无论分布在哪个宿主机，都拥有同一子网 IP，可直接通过 IP 通信。
  • 封装开销：每个数据包增加 50 字节 VXLAN 头部（UDP 封装），MTU 需调整为 1450 字节，否则触发分片。
  • 控制平面：依赖分布式键值存储（如 etcd、consul）维护网络状态，节点加入/离开时存在秒级收敛延迟。
连接池影响：Overlay 网络的额外封装导致单次 RTT 增加 0.3-1ms，且 UDP 封装可能被某些防火墙或负载均衡器丢弃。对于分布式事务场景，建议将连接池的 socketTimeout 和 connectTimeout 在 Overlay 模式下增加 20-30% 的余量，避免因网络抖动导致事务回滚。

2.5 三种网络模式对比

特性 Bridge Host Overlay
隔离性 高（独立命名空间） 低（共享宿主机） 高（独立命名空间）
跨主机通信 需端口映射或路由 需端口映射 原生支持
吞吐损失 5-10% 0-2% 10-20%
延迟增加 0.5-2ms 0-0.1ms 0.3-1ms
端口资源 独立端口空间 共享宿主机端口 独立端口空间
适用场景 单机多容器、开发环境 高性能数据库、中间件 跨主机微服务、分布式事务

2.6 容器间通信对连接池的影响分析

连接池的核心参数（maxActive、maxIdle、minEvictableIdleTimeMillis）需要根据容器网络模式动态调整。以下为三种模式下的调优建议：

  • Bridge 模式：由于 NAT 表项创建开销，建议将 maxIdle 设置为 maxActive 的 60-70%，减少频繁创建/销毁连接。同时启用 testWhileIdle 定期验证连接有效性。
  • Host 模式：性能最优，可适当提高 maxActive 上限，但需监控宿主机端口耗尽风险。建议设置 maxActive ≤ 宿主机可用端口数 / 2。
  • Overlay 模式：网络延迟和封装开销最大，建议将 socketTimeout 设置为 Bridge 模式的 1.3 倍，并启用 removeAbandonedOnBorrow 防止连接泄漏。
实践建议：在分布式事务场景中，建议将事务协调器（TC）与资源管理器（RM）部署在同一个 Overlay 网络或同一宿主机（Host 模式），以减少网络跳数。连接池的 validationQuery 应使用轻量查询（如 SELECT 1），避免因网络延迟导致连接池误判。

2.7 网络模式选择与连接池水位计算

连接池水位（maxActive）的计算公式需引入网络模式系数：

maxActive = (预期并发请求数 × 平均请求耗时) / (连接复用因子 × 网络效率系数)

网络效率系数：
  - Host 模式：0.95 - 1.0
  - Bridge 模式：0.85 - 0.95
  - Overlay 模式：0.70 - 0.85

例如，预期并发 500，平均请求耗时 200ms，连接复用因子 0.8，使用 Overlay 模式（系数 0.8）：

maxActive = (500 × 0.2) / (0.8 × 0.8) = 100 / 0.64 ≈ 157

相比 Host 模式（系数 1.0）的 125，Overlay 模式需要多预留约 25% 的连接数，以应对网络封装带来的延迟波动。

2.8 网络模式选择决策树

Docker 网络模式选择决策树 容器需要跨主机通信？ 是 → Overlay 模式 否 → 单机模式 连接池：socketTimeout × 1.3 启用 removeAbandonedOnBorrow 性能敏感？ 是 → Host 模式 否 → Bridge 模式 监控端口耗尽风险 maxIdle = maxActive × 0.6 调优提示 Overlay 模式建议预留 20-30% 连接余量；Host 模式注意端口范围；Bridge 模式启用连接预检

2.9 容器网络对分布式事务的影响

分布式事务（如 Seata AT、TCC）依赖多个资源管理器（RM）与事务协调器（TC）之间的可靠通信。网络模式的选择直接影响：

  • 事务超时：Overlay 模式的额外延迟可能导致全局事务超时（globalTransactionTimeout）误触发。建议将超时值设置为 Bridge 模式的 1.5 倍。
  • 分支事务注册：Bridge 模式下，NAT 转换可能导致 TC 无法正确识别 RM 的真实 IP，需配置 docker.network.bridge.host_ip 或使用 Host 模式。
  • 重试与幂等：Overlay 网络的 UDP 封装可能丢包，事务补偿（@Compensable）的重试间隔应适当增大（建议 500ms → 800ms）。
生产环境警告：切勿在 Overlay 网络中使用 hostNetwork: true 混合部署，这会导致容器 IP 与 Overlay 网络 IP 冲突，造成事务协调器路由混乱。始终为分布式事务组件（TC、RM）使用统一的网络模式。

2.10 网络模式切换对连接池的平滑迁移

当需要从 Bridge 切换到 Overlay 或 Host 模式时，连接池参数必须同步调整：

  1. 预热阶段：在新网络模式下启动少量容器，使用 SELECT 1 测试连接建立时间，记录 P99 延迟。
  2. 参数计算：根据实测延迟调整 socketTimeout 和 connectTimeout，公式：newTimeout = oldTimeout × (newLatency / oldLatency)。
  3. 灰度切换：先迁移 20% 流量，观察连接池活跃连接数曲线，确认无尖刺后全量切换。
  4. 监控指标：重点监控 numActive、numIdle、waitCount，确保新模式下连接池水位在预期范围内。
案例：某金融系统从 Bridge 迁移到 Overlay 后，连接池 maxActive 从 150 调整至 200，socketTimeout 从 5s 调整至 7s，事务超时率从 2.3% 降至 0.1%。关键步骤是提前在 Overlay 网络下进行了 48 小时的连接延迟采样。
← 上一章 📖 返回目录 下一章 →