depends_on 仅控制容器启动顺序，不等待服务就绪；需结合 healthcheck 做健康判断，并用 wait-for-it.sh 或 dockerize 在应用层主动探测，实现真正的服务依赖。
直接用 docker-compose.yml 的 depends_on 不足以实现真正的“依赖就绪”控制，它只管容器启动顺序，不等服务真正可用。要支撑海量微服务的敏捷级联启停，关键在于把“容器生命周期管理”和“服务健康就绪判断”分层解耦，再通过编排工具协同调度。
依赖树 ≠ 启动顺序，得区分“容器依赖”和“服务依赖”
在 Docker Compose 中：
– depends_on 仅确保被依赖容器已 created 或进入 running 状态（即 PID 1 进程起来了），但数据库可能还在初始化、Spring Boot 应用还在加载 Bean；
– 海量微服务场景下，若上游服务（如注册中心、配置中心）未 ready 就让下游服务启动，必然触发反复重试、日志刷屏、甚至雪崩式失败。
所以必须明确：
- 容器依赖：由 Compose 的网络连通性 +
depends_on+ 自定义 healthcheck 共同保障 - 服务依赖：需应用层主动探测（如 HTTP GET /actuator/health）、或借助轻量协调机制（如 wait-for-it.sh、dockerize、或自研 readiness 探针）
用 healthcheck + restart_policy 构建弹性依赖基座
每个服务应在 docker-compose.yml 中声明可验证的健康检查，这是级联启停的锚点：
- 数据库服务（如 PostgreSQL）加 healthcheck，检测端口连通 + 简单 SQL 查询
- 注册中心（如 Nacos/Eureka）加 healthcheck，调用其健康接口（如
GET /nacos/v1/ns/operator/metrics） - 所有微服务统一暴露
/actuator/health或类似端点，并在 healthcheck 中调用
配合 restart: unless-stopped 或 on-failure，可让服务在依赖未就绪时自动重试，而非立即失败退出——这对海量服务批量启动非常关键。
用自定义启动脚本做服务级就绪编排
对强依赖链（如 Config Server → Auth Service → Order Service），光靠 Compose 原生能力不够，推荐在服务镜像内嵌入启动守卫逻辑：
- 使用
wait-for-it.sh或更现代的dockerize工具，在 CMD 前插入等待语句，例如：dockerize -wait http://config:8848/actuator/health -timeout 120s -- java -jar app.jar - 避免写死 IP 或域名，全部走 Docker 内置 DNS（服务名即主机名），确保跨环境一致
- 超时时间设为合理值（建议 60–180 秒），太短易失败，太长拖慢整体启动节奏
海量服务下的分组启停与灰度控制
当微服务数量达 50+，全量 docker-compose up 容易因资源争抢或网络抖动失败。建议按职责切分 docker-compose.*.yml 文件：
-
compose.infra.yml：注册中心、配置中心、网关、监控组件（优先启动） -
compose.core.yml：用户、订单、支付等核心域服务（依赖 infra 就绪后启动） -
compose.ext.yml：短信、邮件、AI 推荐等外围服务（可延迟或按需启动）
启停时组合使用：docker-compose -f compose.infra.yml -f compose.core.yml up -d
支持按组滚动重启、故障隔离，也便于 CI/CD 流水线分阶段验证。
