docker compose 编排微服务集群的核心是按职责拆分服务、定义清晰依赖与隔离边界，通过自定义网络实现服务名通信，结合健康检查、外置配置、分层组织和 profiles 控制启停。
用 Docker Compose 编排微服务集群，本质是把多个独立服务按业务逻辑组织起来，让它们在统一网络中自动发现、可靠通信、有序启停。关键不在于堆砌容器，而在于设计清晰的依赖关系和隔离边界。
按职责拆分服务，每个 service 保持单一性
先梳理业务模块，比如用户中心、订单处理、API 网关、配置中心、注册中心（如 Eureka）、数据库和缓存。每个模块对应一个 service，各自放在独立子目录里，含自己的 Dockerfile 和配置文件。
- 网关只暴露必要端口（如 80 或 443），其他服务默认不对外映射端口
- 数据库、Redis 等基础设施服务不写业务代码，专注稳定性和可配置性
- 避免在 service 中硬编码 IP，全部用服务名（如 postgres、redis）作为主机名访问
用 docker-compose.yml 定义统一网络与启动逻辑
所有 service 共享一个自定义 bridge 网络（如 micro-net），让容器间通过服务名直接通信，不用关心 IP 变化。依赖关系不靠 depends_on 保证就绪，而是配合健康检查（healthcheck）和应用层重试机制。
- 为每个 service 配置 networks: [micro-net]，显式声明网络归属
- 数据库类服务加 healthcheck，例如检测 pg_isready 或 Redis 的 PING
- 业务服务通过环境变量传入依赖地址，如 SPRING_REDIS_HOST=redis
敏感信息与配置外置，提升安全性与复用性
密码、密钥、数据库连接串等不写死在 docker-compose.yml 里，改用 .env 文件或 secrets（Docker Swarm 模式下）管理。开发、测试、生产环境共用同一份编排文件，仅切换配置源。
- 在 compose 文件中引用 ${DB_PASSWORD}，并在同级目录放 .env 文件定义变量
- 使用 volumes 挂载配置文件（如 application.yml），而不是打包进镜像
- 对 PostgreSQL 等有状态服务，固定命名卷（如 pg-data）保障数据持久
分层组织与按需启用，适应不同场景
不要把所有服务塞进一个大文件。建议按功能分组：基础层（db、redis）、核心层（gateway、user、order）、工具层（pgadmin、kafka-ui）。用 profiles 控制哪些服务启动，比如开发时启用 pgadmin，上线时禁用。
- 给 service 加 profiles: ["dev"]，启动时加 --profile dev
- 用 extends 复用通用配置（如日志驱动、重启策略），减少重复
- 日志统一输出到 stdout/stderr，便于 docker-compose logs 查看
