在多容器应用中，数据库、缓存、消息队列和业务服务往往需要按依赖关系启动。然而，“容器已经启动”并不等于“容器内的服务已经就绪”。应用容器可能在数据库初始化完成前发起连接，最终出现连接拒绝、迁移失败或进程反复重启。这类问题通常具有偶发性，尤其容易在首次部署、冷启动和 CI 环境中暴露。本文将围绕启动顺序、健康检查和应用重试，给出一套可执行的排查思路。🔍
一、先理解启动顺序与服务就绪的区别
Docker Compose 可以根据 depends_on 创建服务依赖关系，但简单列表写法主要保证容器启动顺序，并不保证依赖服务已经能够处理请求。例如，数据库容器的主进程可能已经运行，但仍在恢复日志、初始化数据目录或创建系统表。此时业务服务立即连接，就会触发竞态问题。
Docker 官方文档明确说明，Compose 默认只等待容器进入运行状态，而不是等待服务真正就绪。需要等待可用状态时，应结合 healthcheck 与 condition: service_healthy。具体行为可参考 Docker Compose 启停顺序官方文档。
二、识别常见竞态现象
- 首次执行 docker compose up 失败，再次执行却能够正常启动。
- 业务日志出现 connection refused、timeout、host unreachable 等连接错误。
- 数据库或消息队列没有异常，但应用容器不断退出并被重启。
- 本地开发环境正常，CI、测试机或新服务器部署时偶发失败。
- 使用已有数据卷时正常，删除数据卷后重新初始化便出现问题。
这些现象通常说明配置只建立了“谁先启动”的关系，却没有建立“谁准备好后，另一个服务才能启动”的就绪约束。⚠️
三、按层次执行排查
1. 查看容器状态与退出码
先执行 docker compose ps，确认容器处于 running、exited、restarting 还是 unhealthy 状态。若应用已经退出，应继续使用 docker inspect 查看退出码和健康状态。退出码可以帮助区分配置错误、应用主动退出和被系统终止等情况。
2. 按时间线对照日志
执行 docker compose logs --timestamps，并重点比较依赖服务与业务服务的日志时间。若应用在数据库输出“ready to accept connections”之前已经发起连接，基本可以确认存在服务就绪竞态。必要时使用 docker compose logs -f db app 持续观察启动过程。
3. 从应用容器内验证连接
不要只在宿主机测试端口。应进入应用容器，通过实际使用的服务名、端口和协议验证连接。例如数据库地址通常应填写 Compose 服务名，而不是 localhost。容器内的 localhost 指向当前容器自身，这是另一类常见误判。
四、使用健康检查建立就绪门槛
较稳妥的做法是为依赖服务定义能够反映真实可用性的健康检查，再让业务服务等待健康状态。以 PostgreSQL 为例，可以采用以下配置思路：
services:
db:
image: postgres
healthcheck:
test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
interval: 5s
timeout: 3s
retries: 10
start_period: 20s
app:
depends_on:
db:
condition: service_healthy
其中，interval 表示检查间隔，timeout 是单次检查超时，retries 控制连续失败次数，start_period 则给慢启动服务预留初始化时间。参数应结合真实启动耗时设置，不能机械复制。
健康检查还应尽量贴近服务能力。数据库应验证是否能够接受连接，HTTP 服务可检查专用的 readiness 接口，Redis 可使用协议命令。仅检查进程存在或端口开放，可能把“正在初始化”误判为“已经可用”。✅
五、处理迁移和一次性初始化任务
如果应用启动前必须执行数据库迁移，可以将迁移拆分为独立的一次性服务：数据库达到 healthy 后启动迁移，迁移成功退出后再启动业务服务。此时可使用 condition: service_completed_successfully 表达依赖关系，避免多个应用实例同时执行迁移。
- 启动数据库并等待健康检查通过。
- 运行迁移或初始化容器。
- 确认初始化任务以退出码 0 完成。
- 最后启动 API、Web 或后台任务服务。
六、不要把固定等待时间当成最终方案
在启动命令前加入 sleep 10 看似简单，但机器负载、数据量和磁盘速度变化后，固定时间可能过短，也可能造成无意义等待。它可以作为临时诊断手段，却不适合作为稳定的就绪机制。
即使使用了 Compose 健康检查，应用自身仍应实现连接重试、指数退避和合理超时。因为运行期间数据库可能重启，网络也可能短暂中断。编排层负责降低启动竞态，应用层负责处理瞬时故障，两者不能互相替代。🛠️
七、验证修复是否真正有效
- 删除并重新创建容器，执行完整冷启动测试。
- 在测试环境重建数据卷，观察首次初始化过程。
- 人为延迟数据库启动，确认应用不会提前连接。
- 让健康检查暂时失败，确认依赖服务保持等待状态。
- 重启数据库，验证应用能否自动恢复连接。
总结
Docker 容器启动顺序问题的核心，不是单纯让某个容器先启动，而是准确判断依赖服务何时真正可用。排查时应从容器状态、时间线日志、容器内连通性和健康检查逐层定位，并使用 service_healthy 或 service_completed_successfully 描述真实依赖。同时保留应用级重试机制，才能让多容器系统在冷启动、重新部署和服务重启场景下保持稳定。🚀
