关键在于精简网络结构、合理分配资源、可控通信路径：通过自定义bridge网络分层隔离（public_net/ backend_net/internal_net），服务按需多网接入，禁用link和硬编码IP，统一用服务名DNS解析，并为各服务显式限制CPU与内存。
高并发下提升 docker compose 多服务通信性能，关键不在“加机器”，而在于网络结构精简、资源分配合理、通信路径可控。默认单网络+全互通模式在流量激增时容易成为瓶颈，需主动设计隔离与直连并存的通信拓扑。
用自定义桥接网络替代默认网络
默认网络虽方便，但所有服务共用一个广播域，DNS 解析延迟高、ARP 请求多、容器名解析易抖动。应显式定义多个 bridge 网络，按职责划分通信平面：
- 为数据库等核心数据服务单独建 internal_net，只允许授权服务（如 app）接入
- 为业务服务间调用建 backend_net，避免前端容器（如 nginx）直接连 DB
- 对外暴露服务使用 public_net，并限制仅 gateway 类容器加入
- 同一容器可加入多个网络（如 app 同时连 backend_net 和 internal_net），实现精准通路控制
关闭冗余网络模式与发现机制
旧式 --link 或 environment + 手动 IP 注入不仅失效，还会干扰 Docker 内置 DNS。务必确保：
- 删除所有 depends_on + environment: DB_HOST=xxx 这类硬编码地址写法
- 统一使用服务名作为主机名（如 http://db:5432），依赖 Docker 自动 DNS 解析
- 禁用 network_mode: "bridge" 重复声明——它会覆盖 networks 配置，导致自定义网络失效
- 不启用 host 模式，除非压测确认网络栈是唯一瓶颈；其牺牲隔离性得不偿失
限制资源争抢，防止通信延迟被放大
CPU 或内存超卖会导致容器调度延迟，进而拖慢 HTTP/DB 连接建立速度。尤其在高并发短连接场景下，这种延迟会被成倍放大：
- 为每个 service 显式设置 mem_limit 和 cpu_quota（或 deploy.resources.limits）
- web 类服务建议限制 CPU 在 1.0–2.0 核、内存 512M–1G；DB 类服务需更高内存配额（如 2G+）但 CPU 可适度让出
- 避免使用 cpu_shares（已逐步弃用），改用 deploy.resources.limits.cpu: '1.5'（单位为核数）
- 对 I/O 密集型服务（如 PostgreSQL），可添加 read_only: true 和 tmpfs 挂载临时目录，减少磁盘争用
验证通信路径是否真正高效
配置完不能只看 up 起来没，要实测路径质量：
- 进容器执行 ping -c 3 db，确认毫秒级响应（
- 用 curl -w "@curl-format.txt" -o /dev/null -s http://api:3000/health 测端到端延迟分布
- 检查 docker network inspect [network-name] 中的 Containers 字段，确认只有预期服务在其中
- 用 docker stats 查看各容器实时 CPU/MEM 使用率，识别是否存在某服务持续占满资源
