优先选用自定义bridge网络以支持服务名DNS解析、避免IP硬编码；对Nginx等入口组件可谨慎启用host模式；按frontend/backend/data分层设计网络并显式桥接跨层访问；配合资源预留、健康检查与连接池实现低延迟高吞吐。
要让微服务在 Docker Compose 中实现低延迟、高吞吐，网络模式选择是关键一环。不同模式直接影响通信路径长度、NAT开销、DNS解析能力与隔离粒度——选错会引入毫秒级额外延迟，尤其在高频内部调用场景下会被显著放大。
优先用自定义 bridge 网络替代默认 bridge
默认 bridge 网络不支持服务名 DNS 解析，容器间只能靠 IP 通信，既难维护又易出错；而自定义 bridge 网络开启内建 DNS，服务可通过 服务名直接访问（如 curl http://db:5432），避免硬编码 IP 或额外配置 hosts。
- 显式声明网络，禁用默认网络：在
docker-compose.yml中定义networks:块，并为每个服务指定加入该网络 - 启用
internal: true隔离内部流量：防止服务意外暴露到外部，减少干扰包 - 避免跨网络通信：同一业务域的服务（如订单+库存+支付）应共用一个自定义网络，减少路由跳转
对核心网关或边缘服务谨慎启用 host 模式
host 模式绕过所有虚拟网络栈，直接绑定宿主机端口，适合 Nginx、Envoy 等对延迟极度敏感的入口组件。但它牺牲隔离性，且 无法与其他容器通过服务名通信，也不支持 depends_on 和健康检查联动。
- 仅用于监听固定端口的无状态前端服务，例如：
network_mode: host+ 移除ports字段 - 确保宿主机端口未被占用，否则容器启动失败
- 禁止在开发环境使用：多项目并行时极易端口冲突；Mac/Windows 上行为不一致，影响可移植性
按通信类型分层设计网络拓扑
不是所有服务都该连在同一张网。把流量按角色切分，能降低广播域压力、提升安全边界，也利于内核快速转发。
- frontend 网络：只含 API 网关、静态资源服务，对外暴露 80/443，禁止访问数据库
- backend 网络：含业务微服务（user、order、payment），彼此可互通，但不连外网
-
data 网络：仅含 DB、Redis、ES，设置
internal: true，完全封闭 - 跨层访问需显式桥接：如 backend 服务需查 Redis，就让它同时加入
backend和data网络
配合资源限制与健康检查闭环优化
网络再快，若服务启动后无法立即响应，或因资源争抢导致连接超时，低延迟就成空谈。网络策略必须和运行时保障协同。
- 为数据库等关键服务设置
reservations：保证最低 CPU / 内存，避免冷启动抖动 - 用
healthcheck替代简单depends_on：例如 Postgres 的pg_isready检测真实就绪态，而非容器进程存活 - 内部调用加连接池与重试：应用层控制最大连接数、超时时间，避免瞬时打爆网络队列
