docker compose 多服务网络拓扑需按需连接、分层隔离、精准通信：为前端、后端、数据、内部等逻辑层定义独立网络，服务按角色接入对应网络，支持多网接入、子网配置、dns 服务名解析及 network aliases 实现跨上下文统一入口。
用 Docker Compose 实现多服务复杂网络拓扑，核心在于“按需连接、分层隔离、精准通信”。不是所有服务都要互通，而是让每个服务只接入它真正需要的网络，靠服务名自动解析，避免硬编码 IP 或端口。
明确服务角色与网络边界
先想清楚哪些服务属于同一逻辑层（比如前端展示层、业务逻辑层、数据持久层），再为每层定义独立网络。例如：
- frontend：仅容纳 Nginx、React App 等面向用户的组件
- backend：放 API 服务、认证服务等中间层
- data：专供 PostgreSQL、Redis 等数据库/缓存服务
-
internal：用于敏感服务间通信（如支付模块与风控模块），设
internal: true阻断外部访问
在 docker-compose.yml 中声明并分配网络
networks 是根级字段，services 内通过 networks 列表指定接入关系。关键点：
- 每个自定义网络默认使用
bridge驱动，无需额外声明 - 服务可同时加入多个网络，成为“跨层桥梁”（如 API 服务连
frontend和backend） - 数据库服务通常只连
data网络，不暴露给前端层 - 可为网络指定子网或网关，增强可预测性：
ipam: { config: [{ subnet: "172.21.0.0/16" }] }
示例片段：
services:
web:
image: nginx
networks: [frontend]
api:
image: my-api
networks: [frontend, backend]
pg:
image: postgres
networks: [data]
networks:
frontend: { driver: bridge }
backend: { driver: bridge }
data: { driver: bridge, internal: true }
验证连通性与 DNS 解析是否生效
启动后别急着写代码，先确认网络行为符合预期：
- 进入容器执行
ping <service_name></service_name>—— 能通说明 DNS 和网络路由正常 - 检查容器实际 IP：
docker inspect <container> | grep IPAddress</container>，确认落在对应子网内 - 测试跨网访问：web 容器 ping api ✅，ping pg ❌；api 容器 ping pg ✅
- 若 ping 不通，优先查服务名拼写、网络拼写是否一致，而非防火墙或端口
进阶：用 network aliases 统一通信入口
当一个服务需在不同上下文中被不同名称调用（比如 API 在前端叫 api，在支付模块叫 payment-gateway），可用别名：
- 在 service 的 networks 下添加
aliases列表 - 别名仅在当前网络内生效，不影响其他网络中的解析
- 支持多个别名，便于解耦调用方对服务物理部署的认知
例如：
api:
image: my-api
networks:
frontend:
aliases: [api, gateway]
backend:
aliases: [core-api, v1]
这样 web 容器里 curl http://api 和 curl http://gateway 都能命中同一服务。
不复杂但容易忽略：网络是服务间的“逻辑门禁”，不是“通道开关”。设计时想清楚谁该见谁，比写完再调试连通性高效得多。
