docker compose 编排多容器微服务的关键是按业务拆分独立 service，通过 docker-compose.yml 统一定义网络、依赖与配置，以服务名通信、健康检查替代 depends_on、敏感信息外置、日志与网络隔离保障稳定。
Docker Compose 编排多容器微服务，关键不是堆服务，而是让每个服务各司其职、彼此解耦、通信可控。它用一个 docker-compose.yml 文件统一描述整个应用拓扑，再通过一条命令启动全部服务，省去手动拉镜像、连网络、设环境变量的繁琐步骤。
按业务边界拆分 service
微服务不是越细越好，先梳理清楚核心模块：比如用户中心（user-service）、订单处理（order-service）、API 网关（gateway）、Redis 缓存、PostgreSQL 数据库。每个 service 对应一个独立进程、一个 Dockerfile、一套配置。
- 每个服务建议放在单独子目录（如
./user-service/），含自己的Dockerfile和application.yml - 网关暴露
80或443，其他服务默认不映射主机端口，只在内部网络互通 - 数据库、缓存这类基础设施服务不写业务代码，专注配置可靠性和资源限制
用服务名代替 IP 做服务发现
容器间通信不靠 IP 地址，而直接用 service 名作为 hostname。比如 order-service 连 PostgreSQL，只需把数据库连接 URL 写成 postgresql://user:pass@db:5432/mydb，其中 db 就是 docker-compose.yml 中定义的服务名。
- 所有 service 默认加入同一个自定义 bridge 网络，自动 DNS 解析
- 避免硬编码
172.x.x.x或localhost，否则跨环境会失效 - 网关转发请求时，也用服务名（如
http://user-service:8080）路由到后端
用健康检查替代 depends_on
depends_on 只控制启动顺序，不等容器真正就绪就往下走，容易导致服务启动失败。正确做法是配合 healthcheck，让 Compose 等某个服务“健康”后再启动依赖项。
- 在 db 服务里加 healthcheck，例如检测
pg_isready -U user - 在依赖 db 的服务中，用
depends_on: { db: { condition: service_healthy } } - 敏感配置（密码、密钥）不要写进 yml，改用
.env文件或 secrets（生产环境推荐后者）
分离日志与网络策略
多个服务共用一个 compose 文件，但运行时要避免互相干扰。日志统一收集、网络严格隔离，才能保障稳定性。
- 为每个 service 设置
logging配置，比如输出到json-file并限制大小和轮转 - 用
networks:显式定义网络，避免默认bridge下的服务被意外访问 - 数据库、Redis 等不对外提供服务的组件，可单独划入
internal网络，仅允许特定 service 接入
