关键在于分层配置网络：单机用自定义bridge实现低延迟与强隔离，跨主机慎用overlay而优选host+反向代理，按业务域切分独立网络，并关闭IPv6、调小MTU优化隐性延迟。
在 Docker 编排中实现微服务低延迟与高隔离并存，关键不是“选一个最完美的网络模式”，而是根据服务拓扑、部署规模和通信特征分层配置网络——bridge 用对了不比 host 慢，overlay 用错了反而拖垮延迟。
优先用自定义 bridge 网络做单机内服务隔离
默认 bridge（docker0）所有容器混在一个子网，广播多、DNS 不通、IP 易冲突，天然不适合微服务。而自定义 bridge 网络能同时满足低延迟和强隔离：
- 容器启动时自动注册 DNS 名称，service-a 可直接 curl http://service-b:8080，无需硬编码 IP 或额外服务发现
- 通过 --subnet 172.20.0.0/16 指定独占网段，避开宿主机和其他容器网络干扰
- 不经过 NAT 转发（区别于默认 bridge 的 iptables SNAT），基础通信路径更短，实测延迟降低 30%~50%
- 配合 --internal 参数可禁止该网络对外访问，强化安全边界
跨主机场景下慎用 overlay，优先考虑 host + 反向代理或物理网络直连
Overlay 网络虽支持跨节点通信，但依赖 VXLAN 封装/解封装和键值存储同步，在边缘或资源受限节点上会引入 1–3ms 固定开销，且故障排查复杂。替代方案更务实：
- 若服务部署密度高、节点数 ≤ 5，可让关键延迟敏感服务（如实时推理模块）使用 --network host，共享宿主机协议栈，彻底绕过虚拟网桥
- 搭配 Nginx / Envoy 做本地反向代理，把 host 模式容器暴露为标准 HTTP 接口，既保低延迟又不破坏编排一致性
- 在 Kubernetes 或 Swarm 中，可通过 hostPort 或 NodePort 显式绑定物理网卡端口，再由上层负载均衡调度，避免 overlay 层转发
按业务域切分网络，避免“一张大网打天下”
不同微服务组通信特征差异大：API 网关与认证服务需高频低延迟；日志采集与监控服务可容忍抖动；AI 推理服务则要求带宽稳定。统一网络只会互相拖累：
- 为每类服务创建独立 bridge 网络，例如：api-net、data-sync-net、ml-inference-net
- 用 docker network connect 让需要互通的容器加入多个网络（如 API 容器同时连 api-net 和 auth-net），实现精准通信授权
- 禁用不必要的跨网通信：不连接的网络之间默认二层隔离，无 iptables 规则、无路由表项，零干扰
必要时关闭 IPv6 或调小 MTU 避免隐性延迟
部分边缘设备或旧版内核对 IPv6 处理低效，启用了却不用，反而增加邻居发现开销；MTU 过大在某些 SDN 环境中引发分片重传：
- 创建网络时加 --ipv6=false 明确关闭 IPv6（Docker 24.0+ 默认启用）
- 在低带宽或高丢包链路上，设 --mtu=1400 减少分片概率，尤其对 gRPC 流式调用效果明显
- 检查宿主机网卡 MTU 是否一致，避免容器内 ping 通但大包传输卡顿
