docker compose 本身不提供跨主机调度或集群状态管理能力，关键在于通过声明式配置精准表达分布式协作逻辑：定义统一自定义网络实现服务发现，结合 healthcheck 与 depends_on condition 控制健康驱动启动，挂载外部配置实现运行时参数解耦，并按接入层、协调层、业务层、存储层四层结构化分编排。
Docker Compose 本身不提供跨主机调度或集群状态管理能力，但它可以通过清晰的声明式配置，联合编排分布式集群中各组件的启动、网络、依赖与健康协同——关键不是让 Compose “管理集群”，而是让它“精准表达集群协作逻辑”。
定义统一自定义网络，打通服务发现基础
所有参与分布式协作的服务必须加入同一个自定义 bridge 网络（单机）或 overlay 网络（配合 Swarm），确保 DNS 可通过服务名解析：
- 在 networks 下声明网络，如
micro-net: { driver: bridge } - 每个服务显式指定
networks: [micro-net]，避免默认网络隔离 - 服务间通信直接使用
http://service-name:port，无需硬编码 IP
用 healthcheck + depends_on condition 控制启动时序
分布式系统中，“谁先就绪”决定整个链路是否可用。仅靠 depends_on 不够，必须结合健康检查：
- 为注册中心（如 Nacos、ZooKeeper）、配置中心、元数据节点等关键依赖配置
healthcheck - 微服务和服务网关使用
depends_on: [nacos] && condition: service_healthy - 例如 Nacos 健康端点：
curl -f http://localhost:8848/actuator/health，失败 3 次后重启
挂载外部配置与运行时参数解耦
分布式组件需动态获取地址、策略、密钥等，不能把配置打包进镜像：
- 通过
volumes挂载 YAML 或 properties 文件（如网关路由规则、微服务配置） - 敏感信息用
.env文件注入环境变量，如DB_URL、REDIS_HOST - 微服务启动时读取
spring.cloud.nacos.discovery.server-addr=nacos:8848实现自动注册
分层编排，明确角色边界与数据流向
真正可协同的分布式集群，依赖结构化分工：
- 接入层：Traefik 或 Spring Cloud Gateway，负责 TLS 终止、协议转换（HTTP/gRPC/WebSocket）、JWT 鉴权
- 协调层：Nacos / ZooKeeper / etcd，提供服务注册、配置推送、分布式锁
- 业务层：多个独立微服务（order、user、notify），通过 SDK 向协调层上报心跳并拉取配置
- 存储层：PostgreSQL（强一致性事务）、Redis（会话/缓存）、Kafka（事件总线），仅对内暴露，不对外网开放
